1. ブランチとは何か、なぜ必要か?
Git での branches の操作 はバージョン管理の重要な側面の一つで、1 つのリポジトリ内で複数の開発ラインを並行して進められるようにします。ブランチングにより、Git はコラボレーション、実験、そしてプロジェクトのさまざまなバージョンの管理において強力なツールとなります。
gitGraph
commit id: "Initial setup"
commit id: "Add base features"
branch feature/new-idea
checkout feature/new-idea
commit id: "Implement new logic"
commit id: "Refactor the logic"
checkout main
commit id: "Urgent bugfix on main"
merge feature/new-idea
commit id: "Prepare for release"
main から新しいブランチ
feature/new-idea が分岐し、安全に開発します。作業完了後は
main にマージします。
プロジェクトで大幅な作り替えやリスクの高い実験をしたいとします。Git がなければどうするでしょうか。おそらくプロジェクト全体を新しいフォルダーにコピーしてそこで作業します。結果が良ければメインのフォルダーに移し、そうでなければコピーを削除します。
Git のブランチは同じ発想ですが、もっとエlegantです。本の執筆を例に考えてみましょう。
- 完成した原稿があります(これがメインブランチ
main)。 - 別の結末を書きたい(新しいブランチを作成します。例:
feature/new-idea)。 - 新しい結末を書いても、原稿の本文には影響しません(新しいブランチで作業)。
- 新しい結末の方が良ければ、古いものを置き換えます(ブランチをマージ —
merge)。 - いらない結末の古い草稿は削除できます(ブランチを削除)。
2. 新しいブランチの作成とその中での作業
手順 1. ブランチ管理メニューを開く。
IDE の上部パネルには現在のブランチ名(既定では main)を表示するウィジェットがあります。それをクリックし、+ New Branch を選択します。
手順 2. 新しいブランチ名。
良いプラクティスは、取り組んでいるタスクに合わせてブランチに名前を付けることです。例えば、feature/add-usage-examples。
ブランチを作成すると、IDE は自動的にそのブランチに切り替わります。同じウィジェットに新しい名前が表示されます。
手順 3. 変更を加えてコミットする。
今は自分の「サンドボックス」にいます。ファイル README.md に使用例の新しいセクションを追加しましょう。変更を加え、前回の講義で学んだとおりに commit してください。
3. ブランチ間の切り替え
使用例に関するあなたの変更は、ブランチ feature/add-usage-examples に安全に保存されています。メインブランチ main に戻って、状態を確認してみましょう。
手順 1. 現在のブランチ名のウィジェットをもう一度クリックします。
手順 2. Local または Recent の一覧からブランチ main を選び、表示されたサブメニューで Checkout を押します。
手順 3. 結果を確認。
切り替えたら、ファイル README.md を開きます。使用例セクションが見当たらないはずです! そのセクションは別のブランチに残っています。このように、新機能の作業を、ブランチ main の安定版に影響させずに進められます。
4. ブランチのマージ (Merge)
merge コマンドは、ブランチ feature/add-examples のすべてのコミット(この例ではコミット C3)を取り込み、現在のブランチ main と統合して新しいマージコミットを作成します。
gitGraph
commit id: "C1"
commit id: "C2"
branch feature/add-examples
checkout feature/add-examples
commit id: "C3: Add new section"
checkout main
merge feature/add-examples
さて、ブランチ feature/add-usage-examples での作業が完了し、その変更をメインプロジェクトに取り込みたいとします。
手順 1. 目的のブランチに切り替える。
変更を取り込みたい側、つまり どこに 追加するのかを確認してください。この場合は main です。
手順 2. マージを実行する。
もう一度ブランチ管理ウィジェットをクリックします。一覧で、変更を取り出したいブランチ(どこから 取得するか、feature/add-usage-examples)を選び、サブメニューで Merge feature/add-usage-examples を main に。
手順 3. 結果を確認。
これでブランチ main のファイル README.md に、新しい使用例セクションが現れます。あなたの作業は、プロジェクトのメイン版に正常に統合されました!
5. マージ時のコンフリクト: 心配無用、普通に起こります!
ブランチをマージするときに コンフリクト が発生することがあります。これは、両方のブランチで同じファイルの同じ行が変更されている場合に起こります。Git はどちらが正しいかを自動で判断できず、あなたの助けを求めます。
gitGraph
commit id: "C1: 共通のベース"
branch feature/new-title
checkout main
commit id: "C2: main の変更"
checkout feature/new-title
commit id: "C3: feature の変更"
main と
feature/new-title に新しいコミット(C2 と C3)があり、いずれも共通の祖先(C1)に基づいています。これはマージ時に必ずコンフリクトを引き起こします。
コンフリクトを再現してみましょう:
- ブランチ
mainにいて、未保存の変更がないことを確認します。 - すぐに新しいブランチ
feature/new-titleを作成しますが、まだ切り替えないでください。Checkout branch のチェックが外れていることを確認します。 - ブランチ
mainにいる状態で、README.mdの 1 行目を「My Awesome Project」に変更し、commitします。 - ブランチ
feature/new-titleに切り替えます。ここではREADME.mdの 1 行目が古いままであることが分かります。これはブランチ作成時点のファイル状態です。同じ行を「My Super Project」に変更してcommitします。 - ブランチ
mainに戻り、feature/new-titleをマージします。
これで Git は、両方のブランチに共通の祖先から分岐したそれぞれの新しい履歴があることを検知します。どちらの履歴でも同じ 1 行が変更されているため、Git はどちらが正しいか選べず、コンフリクト解消のためのウィンドウを表示します。
Merge Revision
ここで何が見えるか:
- 左(Your changes): 現在のブランチ(
main)のファイルのバージョン。 - 右(Changes from branch...): マージ対象のブランチからのファイルのバージョン。
- 中央(Result): 最終的に作り上げるべきファイルのバージョン。
>> や << の矢印をクリックして、どちらかの案を丸ごと採用できます。
中央ペインの結果に満足したら、Apply をクリックします。IDE が自動でマージコミットを作成し、コンフリクトは解消されます。
なぜコンフリクトが発生しなかったのか?
すべての手順を行ってもコンフリクトが起きない場合があります。多くの場合、あるブランチの履歴がもう一方の履歴をそのまま延長しているため、Git が fast-forward merge を実行できたときです。コンフリクトを確実に起こすには、ブランチの履歴が共通の祖先から左右に分岐する必要があります。
例:
mainにコミットが 1 つあります(仮に C1)。mainに「My Awesome Project」というメッセージの新しいコミットを作成します。ブランチmainはコミット C2 を指すようになります(main -> C1 -> C2)。mainの現在位置からブランチfeature/new-titleを作成します。つまり新しいブランチもコミット C2 から始まります。feature/new-titleに「My Super Project」というメッセージのコミットを作成します。このブランチは「先へ進み」、コミット C3 を指すようになります(feature/new-title -> C1 -> C2 -> C3)。main(依然としてコミット C2)に戻り、feature/new-title をマージするよう指示します。
Git は状況を見て、ブランチ main がブランチ feature/new-title の直接の祖先であることを把握します。あなたが別ブランチで作業している間、main の履歴には新しいコミットがありませんでした。Git は「なるほど、main を C3 まで早送りすればいい。矛盾はない」と判断し、単に main のポインタをコミット C3 に移動させます。
gitGraph
commit id: "C1"
commit id: "C2"
branch feature/new-title
checkout feature/new-title
commit id: "C3"
checkout main
merge feature/new-title
6. 変更履歴の確認
プロジェクトで何が起きているかをよりよく理解するには、その履歴を見るのが有効です。
IDE 下部の Git タブを開き、Log を選択します。すべてのブランチとコミットのグラフィカルな表示が見られます。どのブランチがどこで分岐し、どこでマージされたかを視覚的に追跡できます。
任意のコミットをクリックすると、そのコミットに含まれる変更内容、作成者、日時を確認できます。まさにコードのためのタイムマシンです!
GO TO FULL VERSION