Claude Code、Codex、GitHub Copilotといった生成AIの登場で、開発のスタイルは大きく変わりました。エンジニア以外の人が開発に関わる場面も増え、それに伴ってGitを使う人の裾野も広がっています。

AIにコマンドを聞けばすぐに答えが返ってくるようにもなり、Git操作のハードルは一見、下がったように思えます。しかし、その便利さの裏側で「AIの指示通りにコマンドを打っているけど、正直、何をやっているのか分かってない」という人も多いようです。

「特にGitでは、AIの提案どおりに打ったらコンフリクトが起きた、よく分からない状態になった、とパニックになる話をよく耳にします」

そう話すのは、書籍『開発系エンジニアのためのGit/GitHub絵とき入門』（秀和システム新社）の著者であり、LINEヤフーでAI駆動開発を推進する山岡滉治さん。

本記事では、山岡さんの解説を通じて、開発現場で遭遇しがちな五つのGitトラブルへの対処法と、その背後にある仕組みを紐解きます。

AIの回答例を示しながら、Gitが内部で何をしているのかを追い、なぜそうなるのかを理解できるところまで踏み込んで解説していただきました。ツールに使われるのではなく、ツールの挙動の裏を理解するためのガイドとしても、ぜひ本稿を役立ててください。

Gitの基礎については、拙著や他の入門記事を参照してみてください。ここではある程度Gitに慣れてきた人が直面しがちな場面に絞っています！

【この記事の執筆者】
山岡滉治（やまおか こうじ）

LINEヤフー株式会社でAI駆動開発推進を担当。メール、カレンダーサービスのデータAI活用推進、社内生成AIコミュニティ運営、社内研修ギルドOrchestration Development Workshopの運営など、組織全体のAI活用文化醸成に取り組む。『開発系エンジニアのためのGit/GitHub絵とき入門』著者
X) https://x.com/kozzy0919

●目次
【1】事例1：コミットメッセージを間違えた！ 直前のコミットを修正したい
【2】事例2：コンフリクトが発生！ AIに聞いて解決したけれど、内部では何が起きているのか？
【3】事例3：コミット履歴が煩雑に……整理して見やすくしたい
【4】事例4：誤ってコミットを削除してしまった！ 復元できるか？
【5】事例5：複数のブランチで同時に作業したい！ worktreeで並行開発を効率化する
【6】まとめ
【7】AIの提案を鵜呑みにしない
【8】さらに学ぶために

※各事例は、状況説明、AIへの質問例、AIの回答例、内部動作の解説、実践ステップの順で進めます。

事例1：コミットメッセージを間違えた！ 直前のコミットを修正したい

状況説明

急いでコミットしたらメッセージに誤字が入っていた。あるいは、コミットした直後にファイルの入れ忘れに気付いた。どちらもよくある話です。

# 例：こんなコミットをしてしまった
git commit -m “ログイン機能のたいぽを修正”  # 誤字入り

まだリモートにpushしていなければ、安全に修正できます。

AIへの質問例

ざっくり聞く場合

詳細に聞く場合

AIの回答例

たいていは次のコマンドが返ってきます。

git commit –amend -m “ログイン機能のタイポを修正”

忘れていたファイルも含めたい場合は、こう案内されます。

# 忘れていたファイルを追加
git add forgotten_file.js
# 直前のコミットに含める
git commit –amend –no-edit

内部動作の解説

 git commit –amend は直前のコミットを修正するコマンドですが、内部的には上書きではありません。新しいコミットを作成して、現在のブランチの参照先をそちらに切り替えています。

Gitのコミットの仕組み

Gitのコミットは、SHA-1ハッシュによる一意のIDで管理されています。各コミットが保持する情報は次の通りです。

 –amend を実行すると、これらの情報をもとに新しいコミットオブジェクトが生成されます。古いコミットは履歴から外れますが、すぐに消えるわけではなく、 git reflog で参照できます。

図解：amendの動作

新しいコミットID（def456）が生成され、HEADの参照先が切り替わります。

実践ステップ

ステップ1：コミットメッセージのみを修正する

git commit –amend -m “正しいメッセージ”

ステップ2：ファイルを追加してからamendする

git add 追加したいファイル
git commit –amend –no-edit  # メッセージは変更しない

ステップ3：エディタで詳細に編集する

git commit –amend
# デフォルトエディタが開き、メッセージを編集できます

注意点

すでにpushしたコミットにamendをかけると履歴が書き換わり、チームメンバーとの同期が崩れます。push済みの場合は git revert で打ち消しコミットを作る方が安全です。

# pushした後は、revertで取り消す
git revert HEAD

現場における判断基準

コミットメッセージは、将来の自分やチームが変更意図を理解するための重要なドキュメントです。丁寧なメッセージは、バグ調査やレビューの効率を大きく左右します。

事例2：コンフリクトが発生！ AIに聞いて解決したけれど、内部では何が起きているのか？

状況説明

チーム開発では、複数人が同じファイルを触ることは珍しくありません。mainに最新の変更が取り込まれた後、自分のfeatureブランチをマージしようとしたら、コンフリクトが起きた——という場面です。

git merge main
# Auto-merging src/app.js
# CONFLICT (content): Merge conflict in src/app.js
# Automatic merge failed; fix conflicts and then commit the result.

AIへの質問例

ざっくり聞く場合

詳細に聞く場合

AIの回答例

おおむね次の手順が返ってきます。

1.コンフリクトが発生したファイルを確認する

git status

2.ファイルを開いて、コンフリクトマーカーを確認する

<<<<<<< HEAD
function login(user) {
  console.log("ログイン処理");
}
=======
function login(user, password) {
  console.log("ログイン認証");
}
>>>>>>> main

3.手動で修正する

// 両方の変更を統合
function login(user, password) {
  console.log(“ログイン認証処理”);
}

4.解決したことをGitに伝える

git add src/app.js
git commit -m “mainブランチをマージ、ログイン処理のコンフリクトを解決”

内部動作の解説

コンフリクトが発生する理由

Gitのマージは、3-way merge（3方向マージ）で行われます。比較対象は三つです。

　1.共通の祖先コミット（base）
　2.現在のブランチ（HEAD、ours）
　3.マージ対象のブランチ（theirs）

Gitはこの三つを突き合わせて自動で統合しますが、同じ箇所に異なる変更が入っていると、どちらを採用すべきか判断できません。ここでコンフリクトが発生します。

図解：3-way mergeの仕組み

共通祖先（base）:
function login(user) {
  console.log(“ログイン”);
}

現在のブランチ（ours / HEAD）:
function login(user) {
  console.log(“ログイン処理”);  // “処理”を追加
}

マージ先（theirs / main）:
function login(user, password) {  // 引数を追加
  console.log(“ログイン認証”);    // “認証”を追加
}

この場合、Gitは自動マージできず、ファイル内にコンフリクトマーカーを挿入します。

コンフリクトマーカーの読み方

・  <<<<<<< HEAD  から   =======  までが、自分のブランチの変更
・   =======  から >>>>>>> main   までが、マージ先ブランチの変更

実践ステップ

ステップ1：コンフリクトしたファイルを確認する

git status
# On branch feature/login
# You have unmerged paths.
#   (fix conflicts and run “git commit”)
#
# Unmerged paths:
#   (use “git add <file>…” to mark resolution)
#         both modified:   src/app.js

ステップ2：ファイルを開いて手動で修正する

VSCodeなどのエディタには、コンフリクト解決を支援するUIがあります。

・Accept Current Change ── 自分の変更を採用
・Accept Incoming Change ── 相手の変更を採用
・Accept Both Changes ── 両方を残す
・Compare Changes ── 差分を比較

これらを使えばコンフリクトマーカーを手で消す手間が省けます。

ステップ3：解決をGitに伝える

git add src/app.js
git commit  # エディタが開き、マージコミットメッセージを編集できます

ステップ4：マージの完了を確認する

# マージコミットが作成され、ブランチが統合されます
git log –oneline –graph

よくある失敗と対処法

失敗1：マージを途中でやめたい

git merge –abort
# マージを中止し、マージ前の状態に戻ります

失敗2：どちらの変更を採用すべきか判断できない

チームメンバーに相談するのが一番確実です。GitHubのプルリクエスト上でコメントをやり取りするのもよいでしょう。

失敗3：マーカーを残したままコミットしてしまった

コードレビューやCI/CDで検出されることが多いですが、気付いた時点で git commit –amend で直せばよいでしょう。

現場における判断基準

コンフリクトは複数の開発者の意図が衝突している状態です。機械的に片方を選ぶのではなく、両方の意図を理解して統合することが重要です。繰り返しになりますが、判断に迷ったときはチームメンバーに相談することを優先しましょう。

執筆／山岡滉治（@kozzy0919）
協力／LINEヤフー