CodeGym /コース /JAVA 25 SELF /安全な実験: ブランチでの作業

安全な実験: ブランチでの作業

JAVA 25 SELF
レベル 25, レッスン 2
使用可能

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です。本の執筆を例に考えてみましょう。

  1. 完成した原稿があります(これがメインブランチ main)。
  2. 別の結末を書きたい(新しいブランチを作成します。例: feature/new-idea)。
  3. 新しい結末を書いても、原稿の本文には影響しません(新しいブランチで作業)。
  4. 新しい結末の方が良ければ、古いものを置き換えます(ブランチをマージ — merge)。
  5. いらない結末の古い草稿は削除できます(ブランチを削除)。

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)に基づいています。これはマージ時に必ずコンフリクトを引き起こします。

コンフリクトを再現してみましょう:

  1. ブランチ main にいて、未保存の変更がないことを確認します。
  2. すぐに新しいブランチ feature/new-title を作成しますが、まだ切り替えないでください。Checkout branch のチェックが外れていることを確認します。
  3. ブランチ main にいる状態で、README.md の 1 行目を「My Awesome Project」に変更し、commit します。
  4. ブランチ feature/new-title に切り替えます。ここでは README.md の 1 行目が古いままであることが分かります。これはブランチ作成時点のファイル状態です。同じ行を「My Super Project」に変更して commit します。
  5. ブランチ main に戻り、feature/new-title をマージします。

これで Git は、両方のブランチに共通の祖先から分岐したそれぞれの新しい履歴があることを検知します。どちらの履歴でも同じ 1 行が変更されているため、Git はどちらが正しいか選べず、コンフリクト解消のためのウィンドウを表示します。

Merge Revision

ここで何が見えるか:

  • 左(Your changes): 現在のブランチ(main)のファイルのバージョン。
  • 右(Changes from branch...): マージ対象のブランチからのファイルのバージョン。
  • 中央(Result): 最終的に作り上げるべきファイルのバージョン。

>> や << の矢印をクリックして、どちらかの案を丸ごと採用できます。

中央ペインの結果に満足したら、Apply をクリックします。IDE が自動でマージコミットを作成し、コンフリクトは解消されます。

なぜコンフリクトが発生しなかったのか?

すべての手順を行ってもコンフリクトが起きない場合があります。多くの場合、あるブランチの履歴がもう一方の履歴をそのまま延長しているため、Git が fast-forward merge を実行できたときです。コンフリクトを確実に起こすには、ブランチの履歴が共通の祖先から左右に分岐する必要があります。

例:

  1. main にコミットが 1 つあります(仮に C1)。
  2. main に「My Awesome Project」というメッセージの新しいコミットを作成します。ブランチ main はコミット C2 を指すようになります(main -> C1 -> C2)。
  3. main の現在位置からブランチ feature/new-title を作成します。つまり新しいブランチもコミット C2 から始まります。
  4. feature/new-title に「My Super Project」というメッセージのコミットを作成します。このブランチは「先へ進み」、コミット C3 を指すようになります(feature/new-title -> C1 -> C2 -> C3)。
  5. 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 を選択します。すべてのブランチとコミットのグラフィカルな表示が見られます。どのブランチがどこで分岐し、どこでマージされたかを視覚的に追跡できます。

任意のコミットをクリックすると、そのコミットに含まれる変更内容、作成者、日時を確認できます。まさにコードのためのタイムマシンです!

1
タスク
JAVA 25 SELF, レベル 25, レッスン 2
ロック未解除
建築事務所:図形の面積計算 🧱
建築事務所:図形の面積計算 🧱
1
タスク
JAVA 25 SELF, レベル 25, レッスン 2
ロック未解除
高度なメールクライアント: メールの作成 📦
高度なメールクライアント: メールの作成 📦
コメント
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION