コンフリクトの解消とレビュー手法

1. コンフリクト（競合）とは

Gitにおけるコンフリクト（conflict）とは、複数人が同一ファイルの同じ行や隣接する行に対して異なる変更を行い、それをマージやリベースの際に統合しようとしたときに、Gitが自動的に解決できない状態を指します。

例

  • 開発者Aがmain.cの10行目を「バージョンA」に変更。

  • 開発者Bが同じ10行目を「バージョンB」に変更。

  • AまたはBがマージしようとするとコンフリクトが発生。

2. コンフリクトの解消手順

ステップ1：コンフリクトの確認

マージやリベース実行後に、以下のようなメッセージが表示されます。

pgsql
Auto-merging main.c
CONFLICT (content): Merge conflict in main.c
Automatic merge failed; fix conflicts and then commit the result.

ステップ2：該当ファイルの確認と編集

ファイルには以下のようなマークが挿入されます：

c
<<<<<<< HEAD
これは自分の変更
=======
これは他のブランチの変更
>>>>>>> feature-branch

この部分を手動で編集し、正しい内容に修正して保存します。

ステップ3：コンフリクト解消後のマーク

bash
git add main.c

でステージに追加し、

bash
git commit

でマージコミットを完了させます。

3. コンフリクトを防ぐベストプラクティス

  • 小さな単位でのコミット・マージ：変更点をこまめに共有する。

  • 定期的にリモートの変更を取り込む：git pull origin mainなどで最新の変更を取得。

  • 機能ごとにブランチを分離：機能単位で分離した開発により干渉を避ける。

  • CIツールによる自動テスト導入：コンフリクトによる不整合を早期に検知。

4. コードレビューの手法

GitHubには**Pull Request（PR）**を中心としたレビュー文化があります。以下が主な流れです。

ステップ1：Pull Requestの作成

開発者が機能ブランチからmainなどの対象ブランチへマージするPRを作成。

ステップ2：レビューアのアサイン

レビュワー（チームメンバー）を指定してレビューを依頼。

ステップ3：レビューコメントと対応

レビュワーはGitHub上で以下のようなアクションを取ります：

  • コメント（コードに対する指摘）

  • approve（承認）

  • request changes（修正要求）

ステップ4：マージ前のチェック

  • 自動テストの通過

  • レビューの承認

  • コンフリクトの解消済み確認

を経て、Merge pull requestによりマージされます。

5. レビュー文化のベストプラクティス

  • 指摘は具体的に・建設的に：指摘内容に理由と改善案を添える。

  • 小さなPRを心がける：大規模なPRはレビューの質を下げる。

  • テンプレートの活用：PRの説明文にテンプレートを設けると伝達がスムーズ。

  • レビューの自動化：GitHub Actions等を用いて静的解析やフォーマットチェックを自動化。

補足：GUIツールの活用

  • GitHub DesktopやVSCodeのGit機能などを利用すれば、コンフリクト解消やレビューも視覚的に分かりやすく操作できます。

生成日：2025/06/09