Gitの基本操作からブランチ戦略まで

1. Gitの基本操作

1-1. リポジトリ作成

• 初期化（git init）
  • 新しいプロジェクトでGitを使う場合、ローカルディレクトリで git init を実行し、リポジトリを初期化
  • 既存のリポジトリをクローン（git clone）して始めるケースも多い
• リモートリポジトリとの連携
  • GitHubやGitLabなどのリモートを登録し、プッシュやプルを行う
  • git remote add origin <URL> でリモート設定

1-2. コミット、プッシュ、プル

• コミット（git commit）
  • 変更内容をステージングエリアに追加（git add .など）
  • 変更内容にメッセージを付けて確定（git commit -m "Commit message"）
  • 小まめなコミットで、変更履歴が追いやすくなる
• プッシュ（git push）
  • ローカルのコミットをリモートに送信
  • git push origin <branch> の形式で、特定のブランチをリモートに反映
• プル（git pull）
  • リモートリポジトリの最新変更をローカルに取り込み
  • git pull origin <branch> でマージまたはリベースが実行される

2. ブランチ作成とマージ、コンフリクト解消の手順

2-1. ブランチ作成

• 新規ブランチを作る（git checkout -b）
  • git checkout -b feature/new-function で、”feature/new-function” ブランチを作成し切り替え
  • 作業内容を独立したブランチで進めることで、本流（main/master）を安定させる
• ブランチの命名規則
  • feature/, bugfix/, hotfix/ など、用途に応じたプレフィックスをつける
  • チーム内で命名ルールを統一すると管理が楽になる

2-2. マージ（git merge、Pull Request）

• ローカルマージ
  • 作業が完了したブランチを main/master に統合
  • git checkout main → git merge feature/new-function
  • コンフリクトがなければそのままマージ完了
• Pull Request（PR）を用いたマージ
  • GitHubやGitLabの機能を利用し、他メンバーのレビューを経てブランチを統合
  • コードレビューやCIテストを通過した後にマージする運用が一般的

2-3. コンフリクト解消

• コンフリクト発生の原因
  • 同じファイルの同じ行を複数人が変更した場合などに発生
  • git merge 実行時にコンフリクト箇所が示される
• 解消手順
  1. 対象ファイルを開き、<<<<<<< HEAD と >>>>>>> branch_name の両方を比較
  2. 正しい変更内容を残して不要な記述を削除
  3. 再度 git add してコミット
• コンフリクトを減らすための運用
  • こまめにリモートの最新を git pull して作業ブランチを更新
  • 大きな変更を行う前に、メンバー間でファイル担当をすり合わせる

3. ブランチ戦略（Git Flow、GitHub Flow）とチーム運用上のルール

3-1. Git Flow

• 概要
  • Vincent Driessenが提唱した、開発フローを整理するためのブランチ運用モデル
  • main（master）、develop、feature、release、hotfixなど、役割別にブランチを切る
• 特徴
  • 安定版（main/master）と開発中（develop）を明確に区別
  • 新機能は feature ブランチで作業、リリース前に release ブランチで最終調整
  • 緊急修正は hotfix ブランチで行い、リリース後すぐに反映可能

3-2. GitHub Flow

• 概要
  • GitHubが推奨するシンプルなブランチ運用モデル
  • main（master）ブランチを常にデプロイ可能な状態に保ち、機能追加や修正はすべて独立したブランチで作業
• 特徴
  • 作業ブランチでコミット→PR作成→レビュー・テスト→mainへマージ→デプロイ
  • releaseやhotfixブランチは特に設けず、運用がシンプルになる

3-3. チーム運用ルール

• ブランチ命名規則
  • feature/xxxx, bugfix/xxxx, release/xxxx など、用途を先頭に付ける
  • 一貫性のある命名で管理しやすくする
• Pull Requestレビュー手順
  • 1人以上の承認を必須にする、CIテストをパスするまでマージ不可にするなど、チームで合意したルールを設定
  • レビュワーの割り当てやレビュー期限を明確化する
• コミットメッセージの書き方
  • 短い要約 + 詳細説明（必要に応じてIssue番号を関連付け）
  • バージョン管理の履歴を見やすくし、後からの追跡を容易にする

4. まとめ

1. Gitの基本操作
   • リポジトリ作成、コミット、プッシュ、プルの流れを理解することで、個人開発からチーム開発まで対応可能
2. ブランチ作成とマージ、コンフリクト解消
   • 作業単位でブランチを切り、Pull Requestを通じたレビューやテストを徹底
   • コンフリクト解消手順を把握し、頻繁にリモートと同期を取ることで衝突を最小化
3. ブランチ戦略（Git Flow、GitHub Flow）
   • チームやプロジェクトの規模に合わせたフローを選択
   • 共通ルール（命名規則、レビュー手順）を設定し、チーム開発を円滑化