まず土台 / 第4章 ブランチとマージ

ページ 3 / 6

第4章Git・GitHub

約4分で読む

ブランチとマージ

何人かが同時に作業しても、混ざらないのはなぜでしょうか

同じファイルを直すとき、変更をどう合わせるかを見てみましょう。

  1. 01思い込み

    変更が消えませんか?

    同時作業が心配

    案内文を2人で直したら、片方の変更が消えてしまいませんか?

  2. 02反例

    両方を合流できた

    変更を突き合わせる

    別の枝で直した、見出しと問い合わせ先。両方の変更が入りました!

  3. 03捉え直し

    同じ箇所では停止

    衝突を知らせる

    同じ文を違う内容に直すと、Gitが判断できずに止まることがあります。

  4. 04実務

    意図を確かめて決める

    内容は人が判断する

    そのときは担当者と、どんな内容にしたいかを確認して決めます。

この章の合言葉

別々に記録し、確認してから合流する

コンフリクトはGitだけで合流を決められない状態です。自動で合流できても、動作確認は必要です。

読みはじめる

枝が分かれているから、並行しても混ざらない

ブランチは、変更の記録を別々に進めるための枝です。たとえば、案内文を直す担当者と、申込機能を作る担当者が、それぞれ別の枝で作業します。コミットした変更は、マージするまで main に入りません。作業用の枝を作るだけで、接続先のデータベースや外部サービスまで複製されるわけではありません。

2 つの枝が並行して進み、順に合流する流れ

気になる工程はクリックで説明が出ます →

枝 A(機能追加⁠)新機能を作る作業用の枝
main(本流⁠)全員が共有する基準の台帳
枝 B(不具合修正⁠)急ぎの修正を行う作業用の枝
出発点の main作業の基準
枝 A を作る機能追加の開始
枝 B を作る修正の開始
A で作業⁠・コミット変更を積み重ねる
B で作業⁠・コミット修正を完了
B を先に合流本流へ反映
main の最新を取り込む(sync⁠)最新の差分を反映
A を合流作業完了

各工程・分岐・レーンをクリックすると、その仕組みの説明がここに表示されます。

この図をテキストで読む

業務フロー図「2 つの枝が並行して進み、順に合流する流れ」。レーン3本、工程8個。 【レーン(担当)】(上から下) - 枝 A(機能追加): 新機能を作る作業用の枝 - main(本流): 全員が共有する基準の台帳 - 枝 B(不具合修正): 急ぎの修正を行う作業用の枝 【工程】(左から右へ。担当 → 工程名) 1. main(本流): 出発点の main〔開始・終了〕(作業の基準) 2. 枝 A(機能追加): 枝 A を作る(機能追加の開始) 3. 枝 B(不具合修正): 枝 B を作る(修正の開始) 4. 枝 A(機能追加): A で作業・コミット(変更を積み重ねる) 5. 枝 B(不具合修正): B で作業・コミット(修正を完了) 6. main(本流): B を先に合流(本流へ反映) 7. 枝 A(機能追加): main の最新を取り込む(sync)(最新の差分を反映) 8. main(本流): A を合流〔開始・終了〕(作業完了)

枝の中の変更は互いに干渉せず、完成したものから順に本流へ合流できます。

合流のほとんどは自動で済む

Git は、離れた箇所の変更を自動で組み合わせられます。同じ行や隣り合う行の変更、削除と修正が重なると、判断できずに止まることがあります。これがコンフリクト(衝突)です。担当者が両方の変更の意図を見て、残す内容を決めます。両方を生かして書き直す場合もあります。

自動で合流できても、組み合わせた結果が正しく動くとは限りません。レビューと動作確認は必要です。衝突が起きたと聞いたら、「どちらの仕様を残すか、業務側で決めることはありますか」と担当者に確かめましょう。

  1. 1

    枝は小さく短命にする

    作業用の枝は数日以内を目安に、確認を済ませて合流させます。作業期間を短く保つほど、他の人の変更と重なる可能性を減らせます。

  2. 2

    合流前に最新を取り込む

    合流の前に 5slab の「/git sync」を使い、本流(main)の最新の変更を自分の枝へ先に取り込みます。

  3. 3

    大きな変更は先に相談する

    同じファイルを同時に大きく変える作業があるときは、着手前に開発者同士で相談して分担を調整します。

合流のとき、1 つに束ねる

5slab では、main への合流に squash マージを使います。枝で積んだコミットを 1 つにまとめて合流させます。本流の履歴は「1 つの提案 = 1 コミット」になり、後から読みやすくなります。枝の中では小さく刻んで記録してかまいません。合流後の枝は削除して使い捨てにします。

合流と本番公開は別です

5slab では、main への合流だけでは本番は変わりません。検証環境(stg)を更新して動作を確認し、本番へ出す版を承認します。stg 更新を始めるタイミングは、プロジェクトの設定によって異なります。

押さえておきたい用語

ブランチ
本流から分けて並行して作業を進めるための枝。作業中の変更は合流するまで他に影響しません。
マージ
作業用の枝で行った変更を、本流(main)などの別の枝へ突き合わせて合流させること。
コンフリクト(衝突)
同じ行や隣り合う行の変更、削除と修正の衝突など、両方の枝の変更が重なって Git が自動で判断できずに停止する状態。
squash マージ
枝で積み重ねた複数の変更記録を 1 つに束ねて本流へ合流させる方法。履歴をきれいに保てます。
main(本流)
全員が共有する基準の台帳。5slab では永続する唯一のブランチとして運用します。
この用語の解説を読む
次に読むGitHub の画面の見方本物そっくりの画面を安全にたどって、見る場所と英語に慣れます。
ページ 3 / 6