【Git運用】本番公開後の修正対応で大惨事を防ぐための正しいブランチ運用とマージ手順

過去に「本番公開後の修正で内容がバッティングし、大惨事になった」という苦い経験を踏まえ、二度と同じ過ちを繰り返さないための **「正しいブランチ分け」**と 「安全なマージ手順」 をまとめました。

綺麗なGitコミットツリーを作り、外部から見ても「美しい」と言われるGit運用を徹底していきましょう！

👨‍🏫 Gitマージの基本思想：主役は「自分」、マージは「もらう」こと

まず、Gitを操作する上でのマージ（git merge）の概念を頭に叩き込んでおきましょう。

日本の商習慣にある「報告（自分の成果を相手に上げる）」という概念はGitにはありません。

Gitの世界では、常に「自分が主役」です。
「私のソースコードをあげる」のではなく、「主役である自分のブランチに、他の人の成果や最新の環境を『もらう（引き込む）』」という意識を持ってください。責任を持って自分のブランチに「もらう」判断をする、これがGitマージの本質です。

🛠️ なぜ「devに切り替えて、pullしてから新しいブランチを切る」のが良いのか？

何か新しい修正を始める際、「古い作業ブランチ（前のブランチ）のまま、最新のdevをpullして上書きして使い回す」のは絶対に避けてください 。過去の古い履歴が混ざり、バッティング（コンフリクト）や先祖返りの大惨事を引き起こす原因になります。

安全に作業を始めるための鉄則の3ステップがこちらです。

1. 主役（アクティブ）を `dev` ブランチに切り替える

まずは、開発環境のベース（主役）である dev ブランチに移動します。

git checkout dev

💡 確認ポイント

git branch コマンドを叩いた際、* dev のように星印（*）がついているブランチが、現在自分が操作している「アクティブな環境」です。

2. サーバーから最新の `dev` をpullする

自分が作業をしていない間に、他のメンバーが本番公開や修正を反映している可能性があります。必ず最新の情報をサーバーからダウンロード（同期）します。

git pull

3. 最新の `dev` から、新しい修正用ブランチを切り分ける

最新の状態になった dev から、今回専用の新しいブランチを作成して切り替えます。

# 全く違う新しいブランチ名（例：meg-002 など）を作成して切り替える
git checkout -b meg-002

これによって、過去の履歴に影響されない、安全で綺麗な「作業スペース」が手に入ります。

🤝 修正完了後：安全に開発環境（dev）へマージする手順

自分の修正（meg-002）が完了し、ローカルでのテストも問題なければ、開発環境のベースである dev に統合（合併）します。ここでも「もらう」意識が重要です。

手順（コマンドでの流れ）

# 1. 再び主役を「dev」ブランチに戻す
git checkout dev

# 2. 念のため、もう一度サーバーから最新のdevをプールする（他の人の更新漏れ対策）
git pull

# 3. 主役（dev）が、Megさんの成果（meg-002）を「もらう」！
git merge meg-002

# 4. 合併されて綺麗になった最新のdevを、サーバーに同期（プッシュ）する
git push

💡 ここがポイント 自分が dev になりきってから、「Megさんのブランチの内容をもらう（git merge meg-002）」という順番を徹底することで、間違いのない安全なマージが可能になります。

🚨 まとめ：本番公開を安全に成功させるために重要なこと

本番公開直後の修正対応において、過去の「バッティングによる大惨事」を二度と繰り返さないために最も重要なことは、「手順の自己流アレンジを絶対にしないこと」です。

今回定義した「正しいブランチ分け」と「安全なマージ手順」において、絶対に妥協してはならない重要事項は以下の2点に集約されます。

1. 【ブランチ分けの重要事項】ベースの最新化と隔離

前のブランチは絶対に使い回さない：「ちょっとした微修正だから」と、前のブランチのまま作業を継続したり、そこに直接 pull して上書きする行為が先祖返りやコンフリクトの一番の原因です。
必ず dev を最新にしてから生やす：主役である dev を一度最新状態に更新し、そこから「完全に隔離された新しいブランチ」を毎回切り出すこと。この一見遠回りに見える手順こそが、既存のコードを壊さないための絶対の防壁になります。

2. 【マージ手順の重要事項】主権を持って「もらう」

自分が主役（dev）になってから引き込む：自分の作業ブランチから dev へ成果を「押し上げる（報告する）」という意識を捨ててください。必ず自分が dev ブランチにチェックアウトし、主役の視点に立ってから「パックさんの成果（作業ブランチ）を責任を持って『もらう（merge）』」という順序を徹底すること。
マージ直前の「ダメ押しのpull」： dev に切り替えた直後、マージコマンドを打つ前には必ずもう一度 pull を挟んでください。自分が作業していたわずかな時間、他のメンバーによる更新がなかったかを確定させるこの一歩が、衝突を未然に防ぐ最後の砦となります。

この【devにする ➔ pullする ➔ 新しいブランチを切る】、そして【devに戻る ➔ pullする ➔ もらう（merge）】という鉄則をチームの共通言語として徹底していきましょう！