Git怖くないシリーズその2(全5回)：マージとの向き合い方

おさらい

• Gitはマージが頻繁に起こる
• 自動マージが優秀
• コンフリクト（衝突）は手動で解消する必要がある

---

マージが正しいのか？

• 自動マージも、コンフリクト時も、結果が正しいかどうかを確認する必要がある
• 正直、特効薬はないと感じる

---

考え方

• 競合を起きにくくする
  機能単位でモジュールを分割、担当は機能単位にアサイン
  CVS/SVNでもやっていること！
• 「正しさを確認する方法」を確立

---

正しさを確認する方法

• テストコード：これが理想
  Gitはテストコード文化と共に浸透したように思う
• 実際の動作を見る機会・時間を増やす
  メインブランチの状態を常にどこかにデプロイして触れるようにしておき、デグレなどに気づけるようにしておく
  CI/CDは価値が高い
• 開発者に動作確認を依頼する：正直、現実的でないかな・・・
• (番外)コードをシンプルに保つ

---

(寄り道)マージ作業者にとっての利点

• 良い副作用：マージ作業者は様々なコードを目にすることになる
• マージ作業を通してソースコードへの理解が深まる

---

マージをしやすくする配慮

• スカッシュ操作：連続する複数のコミットを１つにまとめる
  差分が見やすくなるため、マージ作業がしやすくなる
  大きなマージはコミットも多くなる傾向があるため、スカッシュされていないとほんっとーに地獄です。
• 差分を確認しやすいコーディングルール
  １行に詰め込みすぎない

public void Do(string userName, int level, string authName)
{
    ...
}

public void Do(
    string userName,
    int level,
    string authName
)
{
    ...
}

---

最後に

• テストコードは銀の弾丸に近い
  重要なロジックだけでもテストコードを書いておくと心理的安全性が飛躍的に高まる
• 動作を見る機会を増やすのも有効
• 各開発者もマージしやすさに貢献できる
• マージ作業は絶好の成長機会