Gitのブランチ

docs.scrimba.com

weather-appの構築が途中で、5日間の予報機能を追加しようと考えています。完成させるまでに数回のコミットが必要かもしれず、完成するまでの間、半完成のコードを既に機能しているアプリケーションの隣に置きたくありません。ブランチはGitがこれを解決する方法です。実験が行われる別の作業行であり、mainは開始前と全く同じように機能し続けます。

ブランチとは何か

実際の動作を見てみましょう:

$ git branch forecast
$ git switch forecast
Switched to branch 'forecast'

2つのコマンド: 最初のコマンドはforecastという新しいブランチを作成し、2番目のコマンドはそのブランチに移動します。ここからは、forecastで行うすべてのコミットがforecastに着地し、mainは元の場所にとどまります。

**ブランチ**は、コミットを指すラベルです。現在、mainとforecastは同じコミットを指しており、それはgit branch forecastを実行したときに立っていたコミットです。forecastにいる間に再度コミットすると、そのラベルは新しいコミットに進みます。mainは、あなたがそこに切り替えて自分でコミットするまで、元の場所にとどまります。

git branchで両方のラベルを見ることができます:

$ git branch
  forecast
* main

アスタリスクは現在いるブランチを示しています。ブランチはコミットを指すただの名前です。これが全体的なメカニズムです。この章の他のすべてはこれらのラベルを周りで動かすことのバリエーションです。

実際のプロジェクトでは、ブランチ名は情報を持ちます。一般的な慣例は、変更の種類を説明する短いプレフィックスの後に説明が続くことです: feature/five-day-forecast、fix/broken-date-picker、chore/upgrade-eslint。チケット番号を追加するチームもあります(feature/wa-142-forecast)。どの慣例を選んでも、プロジェクト全体で一貫性を保つので、誰でもブランチを開かずにそれが何であるかを判断できます。

それらの名前がサポートするワークフローは、短命な機能ブランチです: 1つの作業のためのブランチを作成し、コミットして、変更をレビューしてマージされてから、ブランチを削除します。数週間生存しているブランチはmainから大きく離れ、その後のマージはドリフトが続く限り難しくなります。最も健全なブランチは数日で完了します。

ブランチはGitの記録簿の中に隠された小さなファイルにコミットハッシュを1つ保持しているだけです。1つを作成することはその単一の行を書くことを意味し、そのためgit branchは何年の履歴がある後ろにあるリポジトリでも瞬間的に終了します。同じ安さが、なぜ命名規則と短命なブランチが実際に重要なのかです: 古いブランチを削除することはGitにも何も費用がかかりません。そのため、放棄されたものが積み重なるのを止めるのはチームの規律以外の何もありません。

Junoブランチとは何かgit branch forecastは現在のコミットを指す新しいラベルを作成し、git switch forecastはあなたをそこに移動させます。実際にそこでコミットするまで、ファイルについては何も変わりません。ブランチを付箋としてコミットを考えることが好きです: 追加するのは安く、移動させるのは安く、完了したら剥がすのは安いです。

Junoブランチとは何か ブランチ名はポインタなので、1つを作成するのは何もかかりません。その間の切り替えは瞬間的です。feature/five-day-forecastなどの作業を説明する名前を与えます。短命なものを保つ: 作成、コミット、マージ、削除。長命なブランチは、日常的なマージを本当の頭痛に変えるものです。

Junoブランチとは何か ブランチは本当にコミットハッシュを保持する小さなファイルであり、そのためGitでは1つを作成することは最も安い操作の1つです。命名規則と短命なブランチは、チームがその並列作業を読みやすく保つ方法です。Gitはそのどれも強制しません。6ヶ月前から放棄されたブランチをクリーンアップするのに十分な経験があるので、これについて強い意見があります。

ブランチの作成と切り替え

git branch forecastは単独では、あなたをそこに移動させずにラベルを作成します。ほとんどの場合、あなたは両方を一度に望むので、git switchはショートカットを持っています:

$ git switch -c forecast
Switched to a new branch 'forecast'

-cは「create」を意味します。git switch -cはブランチを両方作成して、あなたをそこに移動させます。その単一のコマンドは、新しい作業を始めるたびにほぼ常に手に取るものです。

ブランチを切り替えると、ファイルが表示するスナップショットが変わります。試してみてください: 下のecho行は、src/forecast.jsという新しいファイルを1行で作成する1ステップの方法です。他のすべては既に知っているコマンドです:

$ git switch forecast
$ echo "// 5日間予報ロジック" > src/forecast.js
$ git add src/forecast.js
$ git commit -m "Start forecast module"
$ ls src
forecast.js  index.js
$ git switch main
Switched to branch 'main'
$ ls src
index.js

ファイルは消えていません。それはforecastブランチに存在し、mainブランチのスナップショットはそれを含みませんでした。forecastに戻すと、それはあなたが残したちょうどその通りに再表示されます。

既存のコードとチュートリアルで古い動詞を見るでしょう: git checkout forecastはgit switch forecastと同じ仕事をします。checkoutは古く、1つ以上のことを行います: あなたが与えるものに応じて、ブランチを切り替えるか、ファイルを以前のバージョンに復元できます。コマンド名だけではどちらが起ろうとしているのかは言いません。switchとrestoreはこれら2つの仕事を別々のコマンドに分割し、名前があなたに先制的に伝えます: switchはブランチ間で移動し、restoreはファイルを与えられたコミットで見えた方法に戻します。新しい動詞に手を伸ばしてください。野生でcheckoutを見つけたときに認識してください。

checkoutはあなたが渡すものに基づいて何をするかを決定します: ブランチ名がブランチを切り替え、ファイルパスがそのファイルを復元し、名前が両方に一致する場合、Gitはあなたが何を意図したかを推測する必要があります。その推測がまさに2つのコマンドに分割された理由です。switchはブランチを変更するだけであり、restoreはファイルを変更するだけであり、誤入力されたパスはもはやあなたを誤ってブランチに切り替えることができません。古いスクリプトとチュートリアルでcheckoutを数年間期待してください。新しいものにswitchとrestoreを書いてください。

Junoブランチの作成と切り替えgit switch -c forecastはブランチを作成し、1ステップであなたをそこに移動させます。それはほぼ毎回あなたが使うものです。ブランチを切り替えると、あなたが見るファイルのバージョンが交換されます。1つのブランチで追加されたファイルは、あなたが戻ってくるまで別のブランチで不在です。何も失われていません、それは他のブランチに駐車されています。

Junoブランチの作成と切り替えgit switch -c nameは1ステップで作成して移動します。古いチュートリアルとコードベースで同じ仕事をしているgit checkout nameに会うでしょう。それは古く、より過負荷なコマンドの下で同じ考え方です。毎日switchに手を伸ばし、それを見るときに躊躇なくcheckoutを読んでください。

Junoブランチの作成と切り替えcheckoutはその引数に応じてブランチ切り替えとファイル復元の両方を処理し、これは正確にswitchとrestoreが削除するために分割された曖昧性です。古いスクリプトとチュートリアルでcheckoutを読むことを数年間期待してください。それでも機能しますが、デフォルトで書くコマンドではなくなります。

HEADとデタッチドHEAD

Gitは**HEAD**と呼ばれるマーカーを使用して現在地を追跡します。通常HEADは現在のブランチを指し、そのブランチはコミットを指すので、切り替えるたびにHEADは自動的に進みます。ブランチ名の代わりにハッシュによる特定のコミットまたはタグ(リリースを示すことが多い1つのコミットに固定された固定ラベル)をチェックアウトすると、HEADはブランチラベルではなくそのコミットに直接付着します。この状態をデタッチドHEADと呼ばれています。

あなたはそこで自由に見回ることができ、さらにコミットすることもできますが、何もそれらの新しいコミットを名前で指していません。最初にブランチを作成せずにブランチに切り替えると、それらは再度見つけるのが難しくなります。

$ git switch a1b2c3d
HEAD is now at a1b2c3d Add password strength meter

そのメッセージ「HEAD is now at」は、Gitがあなたにブランチ領域を離れた、単一のコミットにHEADを付着させたことを伝えています。

日常的な作業では、あなたが偶然ここに着地することはめったにありません。これは最も多くの場合、古いタグまたは特定のコミットをチェックアウトして、そのポイントでコードがどのように動作したかを確認するとき、またはビルドツールが作業する1つの正確なコミットをチェックアウトするときに発生します。見たいだけの場合、それは問題ありません: ファイルを参照し、アプリを実行し、完了したときにブランチに戻す。デタッチされている間に変更する価値がある場合、切り替わる前にブランチを作成してください: その分離状態からgit switch -c fix/old-bugは、コミットに実名ラベルを与えるので、切り替わるときに残ります。

デタッチドHEADで残されたコミットは、切り替わる瞬間に削除されません。それは到達不可能になります: まだ保存されていますが、ブランチ、タグ、またはそれを指すHEADはありません。Gitはそれらもすぐにクリーンアップしません。到達不可能なコミットは通常、Git実際にそれをクリーンアップするまで数週間生き残るreflogを保持します。

それはあなたに回復する本当の時間を与えます。ただし、それは永遠に続きません。切り替わる前にブランチを作成することで、デタッチされた作業を安全に保ちます。reflogからコミットを掘り返すことは今日機能しますが、エントリは最終的に期限切れになり、コミットハッシュはそれが起こるずっと前に心から滑ります。その習慣をブランチする習慣を作り、あなたが忘れた珍しい時間のためにreflogを保存します。事を元に戻すで説明しています。

JunoHEADとデタッチドHEAD HEADはあなたが現在立っているコミットを示しています。通常、あなたがいるブランチと一緒に乗ります。ブランチの代わりに特定のコミットをチェックアウトする場合、デタッチドHEADを取得し、そこで行う新しいコミットにはそれを指すブランチ名がありません。それが発生し、作業を維持したい場合は、別の場所に切り替える前に、その場でブランチを作成してください。

JunoHEADとデタッチドHEAD デタッチドHEADに最初に会う可能性が高いのは、タグまたは古いコミットをチェックアウトして見回るときであり、あなたが読むだけの場合は無害です。あなたがコミットする価値のあるものについてコミットする瞬間、あなたがどこかに行く前にそこでgit switch -cを実行してそれにブランチを与えてください。

JunoHEADとデタッチドHEAD 通常HEADはブランチを指し、これはコミットを指します。デタッチされているHEADはコミットを直接指すので、そこで追加するものには、切り替わるたびにそれを保持するブランチ名がありません。それはreflogが痕跡を保つので、それはめったに完全になくなることはありませんが、3週間後にコミットハッシュを覚えることを頼りにしないでください。切り替わる前に必ずブランチを作成してください。

ここから先

あなたはブランチを作成し、それらの間を移動し、mainが実験している間あなたが試している間、どのようにmainが手つかずのままであるかを見てきました。次の質問は、ブランチの作業がmainに戻る方法であり、これはまさにマージと競合がカバーしているものです。進む前にコミット履歴を読むための復習が必要な場合は、履歴がgit log、git show、およびgit diffを説明します。