はじめに
GitHubでブランチを使って開発していると
「複数の作業を別のブランチを切って作業したい！」
という場面がでてきますよね。
私は最初、何も考えずにメインから複数のブランチを切って作業していました。
ですが、片方をマージした際に気づきました。
「作業したファイルがごちゃまぜになった！？」
「さっきマージした作業はどこいった？」
ごちゃごちゃな状況になってしまいました。
その後から、複雑なことをせずに安定して作業するために、ブランチは1つずつ切るようにして、プルリク後にマージしてもらうまで待つようにしていました。
が、それじゃ全然作業が進まないのです。
今回はそれについて勉強したことを解説していこうと思います。
結論から言うと、
ということです。
実際にあった状況の整理
こんなケースがありました。
どちらもdevelop（またはmain）ブランチから切っています。
↓
#577の作業が先に終わったので、developにマージしました。
この時点で #590 にはまだ #577 の変更が入っていません。
↓
developに #577 の内容が入っている状態で #590 をマージしたら、
#577 の変更が上書きされて消える？のではないかという心配が生じました。
ですが実際は消えません！
なぜ変更は消えないのか
Gitのマージは「差分（diff）」で動いています。
#577がすでにdevelopにマージされた状態で、
#590をdevelopにマージする時、Gitは以下のように判断します。
今回のケースだと、
ブランチ#577（マイページの作業） と #590（トップページの作業） はそれぞれ別のファイルで作業しています。
2つのブランチで異なるファイルを触っている場合、
→ 577の変更も590の変更も両方入っている状態になる！
つまり、#577で変えたファイルを590が触っていなければ、#577の変更は完全にそのまま残ります。
注意が必要なケース：コンフリクト（競合）
↑のケースは2つのブランチが別のファイルを触っている場合の話です。
ただし、#577と#590で同じファイルの同じ箇所を編集した場合は「コンフリクト」が発生します。
Gitから
「どちらの変更を採用するか、自分で選んでね」
というメッセージが届きます。
577の変更が勝手に消されるのではなく、両方の変更を見比べて、正しい形に統合することができます。
おすすめの作業フロー
安全に並行作業するために、以下のフローをおすすめします。
1. ブランチを切る
# 577を切る↓
git checkout develop
git checkout -b 577-guide-page# 590を切る（577と並行してOK）↓
git checkout develop
git checkout -b 590-new-feature2. それぞれ作業する
各ブランチで普通に作業・コミットします。
3. 577が完了 → developにマージ
577のPRを作成してdevelopにマージします。
4. 590のマージ前にdevelopの最新を取り込む
ここがポイントです。
590をマージする前に、577の変更が入った最新のdevelopを590に取り込みます。
//# 590ブランチにいる状態で
git checkout 590-new-feature
git merge developもしコンフリクトがあれば、この時点で解消できます。事前に解消しておくことで、PRのマージがスムーズになります。
5. 590をdevelopにマージ
コンフリクトも解消済みなので、安心してマージできます。
まとめ
ブランチは「安全に並行作業するための仕組み」です。
怖がらずにどんどん活用しましょう！
大事なのは、後からマージするブランチで
マージ前にdevelopの最新を取り込む
こと。
これだけ意識すれば、安心して複数の作業を同時に進められます。
