Gitのバージョン管理をうまく行う方法

1. 1つのブランチ戦略を策定する

   • 多様な専門分野の知識を持つチームメンバーが一緒に働くと、ワークフローへのアプローチが衝突することがある
   • これを防ぐために、リーダーは1つのブランチ戦略を立て、全員に共有すべき
   • ブランチワークフローの決定は、チーム規模、経験レベル、拡張要件、業務上の制約など、さまざまな要素によって変わりうる
   • 開発チームは既に定められたワークフローに従うこともできるが、チームの要件に合わせてワークフローを作ることもできる
   • ワークフローに含まれる内容
     • 集中型ワークフロー: 1つのリポジトリと1つのマスターブランチがある。変更が上書きされるリスクがある
     • 機能ブランチ: 新しい機能を追加するたびに新しいブランチを作る。該当する feature ブランチに機能関連のコミットを行う
     • Git Flow: 機能ブランチの極端な形。Git Flow を使った開発では、マスターとは別に開発ブランチがある。機能、リリース、ホットフィックスブランチをサポートする。開発は開発ブランチで行い、リリースブランチへ移し、その後マスターブランチに merge される
     • タスクブランチ開発: GitLab Flow はその一例。機能中心の開発で、feature ブランチをイシュー追跡と組み合わせた形。GitLab Flow は専用ブランチを使って、ステージング、本番テスト、本番といった複数環境を維持管理する。コミットされた変更がすべての環境でテストされるようにする
   • コラボレーションへの効果:
     • 全員が同じワークフローで調和して動けば、コードを上書きしたり、マスターブランチを壊したりすることが減る
     • すべての作業者が開発・デプロイプロセスに慣れることで、チームメンバー同士がお互いの作業に容易に貢献できる
     • 明確で簡潔なブランチ戦略は、新しいコードの merge とプロジェクト発展の好循環につながる
     • このような環境は、チームメンバーが会議を調整し、締め切りや作業量を管理する助けになる
     • 各ワークフローがコラボレーションに与える影響
       • 集中型ワークフロー: 2人の開発者が同じコードを同時に重複して作業しないよう、十分にコミュニケーションを取れる小規模チーム（開発者5人未満）に効果的
       • 機能ブランチと GitFlow: より多くのコードレビュー、push ルール、コード承認者、より広範なテストが必要となり、多様なチームを結びつける
       • タスクブランチ開発: チームメンバーが要件を、タスクブランチに反映される小さな機能の塊へと分解できるようにする。このワークフローには、コードスニペット、コードレビュー、単体テストのような協業の実践が含まれる。テストが失敗した場合は、チームメンバーが協力して何が問題だったのかを確認する

2. 小さな単位で頻繁にコミットする

   • 完成度を優先すると、プロジェクトがほぼ完成した時点でしか大規模なコミットをしなくなることがある
   • 簡単な機能検証や小さなステップを飛ばすと、誤った機能を開発したり、見当違いの方向に時間を費やしたりする可能性がある
   • 動作するテストとコードがあるたびにコミットする
   • プロジェクトを小さな段階に単純化し、頻繁なコミットで大きな目標を達成する方法を見つけるべき
   • コラボレーションへの影響:
     • 頻繁にコミットする文化が根づくと、全員がコードリポジトリの可視性を持ち、他のチームメンバーが何をしているかを把握しやすくなる
     • 機能ブランチまたは merge request で成果物を共有すれば、他のチームメンバーによる重複作業を防げる
     • まだレビューの準備ができていなくても、機能ブランチには頻繁に push すべき
     • 完了前に作業を共有すると、議論やフィードバックが活性化し、コードレビュー前でも品質を改善できる
     • 作業を複数のコミットに分けると、開発者や他チームが今後コードをレビューする際に有用な情報として活用できる
     • 機能がどのように開発されたかをコミットごとに明確に識別できる
     • 関係のない変更履歴はそのままにして、望む特定時点へロールバックしたり、特定のコード変更だけを選択的に取り消したりできる

3. 詳細なコミットメッセージを書く

   • コミットメッセージは、コミット内容だけでなく、開発者の意図も反映すべき
   • コミットメッセージで、なぜ変更が発生したのかを説明すべき
   • 良いコミットメッセージの例: 「ユーザー画面の重複コードを減らすためにテンプレートを統合」
   • コミットメッセージに含まれる「変更」「改善」「修正」「再構成」といった言葉は、有用な情報ではない
   • コラボレーションへの影響:
     • 詳細なコミットメッセージは透明性を高め、進捗の可視性を提供し、チームメンバー、顧客、将来の貢献者が開発プロセスを理解するのに役立つ
     • コードレビューを行う際、コミットメッセージは反復された手順をたどり、リリース、協議、要件変更後に現れた変化を確認する助けになる
     • 詳しいコミットメッセージは、QA やセキュリティチームがコードを検査する際に問題領域を特定し、特定の変更を元に戻すのに役立つ
     • コミットメッセージを詳しく書けば、他のチームメンバーの重複作業を防ぎ、作業遅延を最小化して、プロジェクトの進捗を安定して進められる

4. ブランチを使って開発する

   • ブランチで開発することは、特定ブランチの現時点の状態を複製して作業するのと同じ
   • ブランチを使えば、メインコードベースに影響を与えずにコード変更できる
   • 変更履歴はブランチ内で管理される
   • コードの準備ができたら、そのコードをマスターブランチに merge できる
   • ブランチでコーディングすれば、より体系的な方法で開発に取り組める
   • 開発中のドラフトを、安定したテストを経たマスターコードと分離して個別に管理できる
   • コラボレーションへの影響:
     • メンバーが複雑な問題解決のための革新的な解決策や実験を試せるようにする
     • 開発チームは、マスターブランチに影響を与えるのではないかという不安から離れ、創造的な挑戦ができる
     • マスターブランチに merge する前に、ソリューションが正常に動くことを検証するため協力できる
     • 運用、QA、セキュリティチームは、デプロイ前にコードをレビューし、すべてのメンバーがリリース前にアイデアを出し、潜在的な問題を議論する機会を確保できる

5. 定期的なコードレビューを行う

   • 継続的改善を保証し、不安定なコードを防ぐ
   • レビューすべきコードができたら、プロジェクトをよく理解している同僚、チームメンバー、業務領域の専門家にコードレビューを依頼すべき
   • コードレビューを行う際の注意点:
     • どのような変更が必要かを説明する
     • 代案を提示しつつも、開発者がそれをすでに検討したと想定すべき
     • 問題解決の過程でも、コードを単純化する方法を探すべき
   • コラボレーションへの効果:
     • コードレビューは、問題解決や実装に関して別の意見を提示する
     • バグ、ロジック上の問題、または潜在的なコーナーケースを見つける別の目になる
     • 難しい課題を乗り越え、リリースに向かって進む中で発生しうる問題を緩和する
     • 問題解決策の検討、意見提示、チームメンバーの協力を通じたレビューが可能になる
     • 多様なコーディング手法、ワークフローのノウハウ、新しい問題解決方法を学べる