Version Control on kenji.blog

【Gitコマンド】rebaseとmergeの違いと、実務での正しい使い分け

Sun, 13 Sep 2026 09:00:00 +0900

1. はじめに：なぜ「mergeかrebaseか」は永遠の課題なのか

Gitは現代のソフトウェア開発において不可欠なバージョン管理システムです。複数人の開発者が同時にコードベースを変更する際、Gitの強力なブランチモデルが威力を発揮します。しかし、チーム開発において「merge と rebase のどちらを使うべきか」という議論は、初心者から熟練者まで常に開発者を悩ませるトピックの一つです。

この記事では、Gitの内部構造であるDAG（有向非巡回グラフ）やコミットハッシュの数学的性質から紐解き、git merge と git rebase のメカニズムの違いを深く掘り下げます。そして、実務においてどのようにこれらを使い分けるべきか、具体的なワークフローを交えて徹底的に解説します。単なるコマンドの紹介にとどまらず、裏側でGitがどのような計算を行っているのかまで理解することで、コンフリクトへの恐怖をなくし、クリーンで追跡可能な履歴を構築できるようになります。

2. Gitの内部構造：コミットハッシュとオブジェクトモデル

Gitが履歴をどのように統合するかを理解するためには、まずGitがデータをどのように保存しているかを知る必要があります。Gitは単なるファイル変更の差分（パッチ）を保存しているわけではなく、ある時点のファイルシステム全体のスナップショットを保存しています。

2.1 コミットハッシュの暗号学的性質

Gitの各コミットは、その内容を元に計算されたSHA-1（Secure Hash Algorithm 1）ハッシュ関数による40桁の16進数で一意に識別されます。コミットオブジェクトは以下の要素から構成されます：

Treeオブジェクトへのポインタ: その時点のディレクトリ構造とファイル（Blob）のスナップショット
親コミットへのポインタ: 1つ以上の親コミットのハッシュ値（初回コミットは親を持たず、マージコミットは2つ以上の親を持ちます）
作成者情報（Author）: コードを書いた人と日時
コミッター情報（Committer）: コミットを作成・適用した人と日時
コミットメッセージ: 変更の意図を説明するテキスト

数学的に表現すると、コミットオブジェクト $C$ に対するハッシュ値 $H(C)$ は次のように定義されます：

$$ H(C) = \text{SHA-1}( \text{tree} \parallel \text{parent} \parallel \text{author} \parallel \text{committer} \parallel \text{message} ) $$

ここで、$\parallel$ はデータの結合を表します。ハッシュ関数の特性により、コミットメッセージを1文字変えただけでも、あるいは親コミットが異なるだけでも、全く異なるハッシュ値が生成されます。つまり、コミットは不変（Immutable） です。後述する rebase が「履歴を書き換える」と表現されるのは、実際には「内容が似ているが異なるハッシュ値を持つ新しいコミットを作成している」ためです。

ハッシュ空間の大きさは $2^{160}$ であり、衝突（異なるコミットが同じハッシュ値を持つこと）が発生する確率 $P$ は、誕生日攻撃（Birthday Paradox）の理論を用いると次のように近似できます（$n$ はコミット数）：

$$ P(\text{collision}) \approx 1 - \exp\left(-\frac{n^2}{2 \times 2^{160}}\right) $$

この確率は極めて低く、実用上Gitのコミットハッシュが衝突することはほぼあり得ません。

3. グラフ理論とDAG：Git履歴の数学的モデル

Gitのコミット履歴は、グラフ理論における「有向非巡回グラフ（Directed Acyclic Graph, DAG）」としてモデル化されます。

3.1 DAG（有向非巡回グラフ）とは

グラフ $G = (V, E)$ において、$V$ はコミットの集合（頂点）、$E$ はコミット間の親子関係を示す有向エッジの集合です。Gitにおいては、エッジの向きは「子コミットから親コミット」へと向かいます。新しいコミットは過去のコミットへのポインタを保持しているためです。

graph BT
A["Commit A (Initial)"]
B["Commit B"]
C["Commit C (Main)"]
D["Commit D (Feature)"]
E["Commit E (Merge)"]
B --> A
C --> B
D --> B
E --> C
E --> D

DAGの最大の特徴は「サイクル（循環）が存在しない」ことです。これにより、コミット履歴を遡るアルゴリズムは無限ループに陥ることがなく、確実に終端（初期コミット）に到達できます。

3.2 トポロジカルソートと履歴の順序

Gitの git log コマンドなどで履歴を表示する際、DAGはトポロジカルソート（Topological Sort）アルゴリズムによって1次元のリストとして順序付けされます。DAGにおける任意の有向エッジ $u \to v$ （$u$ は $v$ の子）について、リスト内で $u$ が $v$ よりも前に来るように並べ替えます。

4. git merge のメカニズムと種類

ブランチの変更を統合する最も基本的なコマンドが git merge です。しかし、現在の状態に応じてGitは異なるマージ戦略を自動的に選択します。

4.1 Fast-Forward マージ（–ff）

統合先（例：main）のブランチが、統合元（例：feature）のブランチの直接の祖先である場合、Gitは「Fast-Forward（早送り）」マージを実行します。これは、新しいコミットを作成せず、単にブランチのポインタを前に進めるだけの操作です。

gitGraph
commit id: "A"
commit id: "B"
branch feature
checkout feature
commit id: "C"
commit id: "D"
checkout main
merge feature

Fast-Forwardマージは履歴を一直線に保ちますが、「どのコミット群が一つの機能開発（feature）としてまとまっていたのか」というコンテキストが失われる欠点があります。

4.2 Non-Fast-Forward マージ（–no-ff）

git merge --no-ff を明示的に指定すると、たとえFast-Forward可能な状況であっても、必ず新しい「マージコミット」を作成します。マージコミットは2つの親を持つ特別なコミットです。

gitGraph
commit id: "A"
commit id: "B"
branch feature
checkout feature
commit id: "C"
commit id: "D"
checkout main
commit id: "Main Work 1"
merge feature type: NORMAL

この方法の利点は、機能ブランチの存在と歴史がDAG上に明確に残ることです。問題が発生した際、git revert -m 1 <マージコミットのハッシュ> を実行することで、機能全体を一度に安全に取り消す（リバートする）ことが可能です。

4.3 3ウェイマージ（3-Way Merge）アルゴリズム

統合先と統合元のブランチがそれぞれ独自のコミットを持っている場合、Gitは3ウェイマージを実行します。この際、GitはDAGを探索し、2つのブランチの「共通の祖先（Lowest Common Ancestor, LCA）」を見つけ出します。

LCAを見つけるためのアルゴリズムの計算量 $T_{\text{LCA}}$ は、頂点数 $|V|$ とエッジ数 $|E|$ に対して線形時間で実行可能です：

$$ T_{\text{LCA}} = \mathcal{O}(|V| + |E|) $$

Gitは「LCAの状態」「現在のブランチの状態」「相手のブランチの状態」の3つを比較し、変更が衝突していなければ自動的にマージコミットを生成します。

5. git rebase のメカニズムと履歴の再構築

git merge が履歴を「統合」するのに対し、git rebase は履歴を「再構築（付け替え）」します。

5.1 Rebaseの背後にある動き

feature ブランチを main ブランチにリベースする（git rebase main）際の内部動作は以下の通りです：

feature ブランチと main ブランチの共通祖先（LCA）を見つける。
LCAから feature ブランチの先端までのコミットの差分を一時領域に保存する。
feature ブランチのポインタを main ブランチの先端に移動させる。
保存しておいた差分を、新しいベース（mainの先端）の上へ1つずつ順に適用（Cherry-Pick）し、新しいコミットを生成する。

graph TD
A["Commit A"] --> B["Commit B"]
B --> C["Commit C (Main)"]
B --> D["Commit D (Old Feature)"]
D -.-> E["Commit D' (New Feature)"]
C --> E
style D stroke-dasharray: 5 5, fill: #f9f9f9, color: #999

ここで重要なのは、リベースによって生成されたコミット $D'$ は、元のコミット $D$ とは親コミットが異なるため、全く異なるハッシュ値を持つということです（前述のハッシュ関数の定義 $H(C)$ を参照）。

5.2 インタラクティブリベース（Interactive Rebase）

git rebase -i（または --interactive）を使用すると、コミット履歴を思いのままに操作できます。これはローカルの履歴を整理するための最強のツールです。

pick : コミットをそのまま採用する
reword : コミットメッセージのみを修正する
edit : コミットの内容を修正するために一時停止する
squash : このコミットを前のコミットに融合し、メッセージも結合する
fixup : squash と同じだが、このコミットのメッセージは破棄する
drop : コミットを完全に削除する

数学的に見れば、あるブランチに $N$ 個のコミットがある場合、リベースの順序入れ替えによって生成可能な線形履歴のバリエーション（順列） $P$ は以下のようになります。

$$ P = N! $$

Gitは開発者に $N!$ 通りの自由を与え、履歴を論理的で美しい状態に保つことを可能にしています。

6. リベースの黄金則（The Golden Rule of Rebase）

rebase は非常に強力ですが、一つの絶対的なルールが存在します。

「公開されたパブリックな履歴に対して絶対にリベースを行ってはならない」 (Never rebase public history)

6.1 なぜパブリックな履歴をリベースしてはいけないのか？

Gitは分散型です。あなたが origin/main にプッシュしたコミットは、他の開発者のローカルリポジトリにもクローン（複製）されています。もしあなたが既にプッシュ済みのコミットをリベースして履歴を書き換え、git push --force で強制上書きした場合、何が起きるでしょうか？

他の開発者のローカルにあるDAGと、リモートのDAGが根本的に分岐してしまいます。他の開発者が git pull を実行すると、Gitは異なる歴史を持つコミット群を無理やりマージしようとし、大量のコンフリクトや重複コミット（同じ変更内容だがハッシュが異なるコミット）が発生し、リポジトリがパニック状態に陥ります。

リベースは**「まだ誰とも共有していない、ローカルのブランチ」**に対してのみ行うのが鉄則です。

7. コンフリクト（競合）の解決と git rebase –continue

複数人が同じファイルの同じ箇所を変更した場合、コンフリクトが発生します。merge と rebase ではコンフリクトの解決プロセスが異なります。

7.1 Mergeにおけるコンフリクト解決

git merge の場合、コンフリクトの解決は1回だけ発生します。最終的なマージコミットを作成する直前に、すべての競合箇所を一度に修正します。

7.2 Rebaseにおけるコンフリクト解決

git rebase の場合、コミットを1つずつ再適用していく性質上、各コミットごとにコンフリクトが発生する可能性があります。

リベース中にコンフリクトが発生すると、Gitは処理を一時停止します。解決の流れは以下の通りです：

エディタやIDE（VS Codeなど）を開き、コンフリクトマーカー（<<<<<<< や ======、>>>>>>>）を手動で修正する。
修正したファイルをインデックスに追加する：
1

git add <修正したファイル>
コミットは作成せず、リベース処理を再開する：
1

git rebase --continue

もしリベース自体を取りやめて元の状態に戻したい場合は、以下のコマンドを実行します：

1

git rebase --abort

（※コンフリクトの解決が不要で、そのコミットごとスキップしたい場合は git rebase --skip を使用します）

8. 実務での正しい使い分け（ワークフロー実践）

では、実際の開発現場では merge と rebase をどのように使い分けるべきでしょうか。ここでは最もスタンダードで安全なアプローチを紹介します。

8.1 【シナリオ1】ローカルでの作業履歴の整理（Rebaseの利用）

機能ブランチで開発中、細かなコミット（「タイポ修正」「一時保存」など）がたくさん積み重なってしまったとします。プルリクエスト（PR）を出す前に、これらを意味のある単位に整理するためにインタラクティブリベースを使用します。

1
2
3


# featureブランチにいる状態で実行
git rebase -i HEAD~5
# （エディタが開き、squashやfixupを使って履歴を綺麗にする）

これにより、レビュアーにとって意図が伝わりやすい、美しいコミット履歴を作ることができます。

8.2 【シナリオ2】最新のmainブランチへの追従（Rebaseの利用）

開発が長引き、main ブランチに他の人の変更がどんどんマージされていく場合、自分の feature ブランチが古くなってしまいます。この場合、feature ブランチを最新の main にリベースして追従します。

1
2
3
4
5


# mainの最新情報を取得
git fetch origin

# featureブランチを最新のmainの上に付け替える
git rebase origin/main

これにより、履歴が一直線になり、後続のマージ時のコンフリクトを防ぐことができます。また、余計なマージコミット（“Merge branch ‘main’ into feature”）が生成されるのを防ぐことができます。

8.3 【シナリオ3】完成した機能の統合（Mergeの利用）

feature ブランチでの開発が完了し、いよいよ main ブランチに統合するフェーズです。ここでは git merge --no-ff を使用します（GitHubなどのPull Requestで「Create a merge commit」を選ぶのと同じです）。

1
2
3


git checkout main
git merge --no-ff feature -m "Merge feature: ユーザーログイン機能の実装"
git push origin main

これにより、main ブランチのDAG上に「ここで一つの機能がマージされた」という歴史の結節点（マージコミット）が残ります。後から履歴を見たときに、機能単位でコードを追いやすくなります。

9. 結論（まとめ）

Gitの操作において「すべてをMergeで済ませる」または「すべてをRebaseで一直線にする」といった極端なアプローチは、それぞれ長所と短所があります。

実務におけるベストプラクティスは、**「ローカルのプライベートな履歴は rebase で美しく整理し、パブリックな統合履歴は merge –no-ff で文脈を残す」**というハイブリッドなアプローチです。

ローカル（個人の作業スペース）: rebase を使って、無駄なコミットを排除し、最新のメインラインに追従して一直線の履歴を維持する。
グローバル（共有の作業スペース）: merge --no-ff を使って、機能ブランチの存在をマージコミットとしてDAGに記録し、リバートやトラッキングを容易にする。

DAGの構造やハッシュ関数の仕組みといった数学的・アーキテクチャ的な背景を理解することで、Gitコマンドは単なる暗記から「意図を持った履歴の設計」へと昇華します。リベースの黄金則を守りながら、状況に応じた最適なコマンドを選択し、チーム全体にとって読みやすく保守しやすいクリーンなコミット履歴を構築していきましょう。

Git初心者が陥りやすいミスと解決コマンド集（コンフリクト解消など）

Sat, 12 Sep 2026 17:00:00 +0900

Git初心者が陥りやすいミスと解決コマンド集（コンフリクト解消など）

1. はじめに：なぜGitでミスをしてしまうのか？

ソフトウェア開発において、Gitは空気や水のように不可欠な存在となっています。しかし、多くの初心者（そして時として熟練者でさえ）にとって、Gitは「恐ろしい魔法のブラックボックス」のように感じられることがあります。コミットが消えたり、意図しないブランチに大量の変更を押し込んでしまったり、見たこともないコンフリクトのエラーメッセージが画面を埋め尽くしたり……。こうした「Gitの罠」にハマると、作業の進行が完全にストップしてしまい、最悪の場合はソースコードを破壊してしまうのではないかという恐怖に駆られます。

なぜGitはこれほどまでに難しく、ミスを誘発しやすいのでしょうか？その最大の理由は、「Gitの内部で何が起こっているのかを理解せずに、表面的なコマンドだけを暗記して使っているから」です。Gitは、分散型バージョン管理システム（DVCS）としての堅牢な設計思想に基づいていますが、そのインターフェース（CLI）は必ずしも直感的ではありません。

この記事では、Git初心者が現場で頻繁に遭遇する「やらかし（よくあるミス）」を多数のケースに分類し、それぞれの具体的な解決策となるコマンドを提示します。しかし、単なるコマンドの羅列（チートシート）にはしません。「なぜそのミスが起きるのか」「そのコマンドを実行するとGitの内部でデータがどのように動くのか」を、.git ディレクトリの構造や、背後で動いているDiffアルゴリズムの数学的背景、Mermaidによる図解を交えて、10,000文字を超えるボリュームで徹底的に深掘りします。

この記事を最後まで読み終えたとき、あなたは「Gitが怖い」という感情から解放され、むしろ「Gitほど信頼できる相棒はいない」と確信できるようになるはずです。それでは、Gitの深淵なる世界へ飛び込んでいきましょう。

2. Gitの深淵：`.git` ディレクトリの内部構造を理解する

多くのトラブルシューティングを容易にするための第一歩は、Gitがデータをどのように保存しているかを知ることです。あなたのプロジェクトのルートディレクトリに存在する隠しフォルダ .git、これこそがGitの心臓部です。Gitは、単なるファイルの差分（パッチ）を順に記録していくシステムではなく、スナップショットのストリームとしてデータを管理しています。

2.1 オブジェクトモデル：Blob, Tree, Commit

Gitは主に3つのオブジェクトを使用してリポジトリの状態を表現します。これらのオブジェクトは .git/objects に保存されます。

Blob (Binary Large Object) ファイルの内容そのものを保存するオブジェクトです。ファイル名や権限の情報はここには含まれません。純粋なバイト列がzlibで圧縮され、SHA-1ハッシュ値（40文字の16進数）によって識別されます。
Tree ディレクトリの構造を表すオブジェクトです。Treeオブジェクトは、他のTreeオブジェクト（サブディレクトリ）やBlobオブジェクト（ファイル）へのポインタ（SHA-1ハッシュ値）、およびそれらのファイル名、アクセス権限を含みます。UNIXのディレクトリのような役割を果たします。
Commit ある時点でのリポジトリ全体のトップレベルのTreeオブジェクトへのポインタと、メタデータ（作成者、コミット日時、コミットメッセージ）、そして直前のコミット（親コミット）へのポインタを保持します。

graph TD
Commit1["Commit (Hash: 9f8a)"] --> Tree1["Tree (Hash: 4b82)"]
Tree1 --> Blob1["Blob (Hash: 8d7e) : index.js"]
Tree1 --> Tree2["Tree (Hash: 3a2c) : src/"]
Tree2 --> Blob2["Blob (Hash: 5f1b) : app.js"]

2.2 HEADと参照（Refs）の正体

Gitで作業していると頻繁に目にする HEAD という単語。これは現在チェックアウトしているブランチ（またはコミット）を指し示す**シンボリック参照（Symbolic Reference）**です。 .git/HEAD というファイルをテキストエディタで開いてみると、次のような文字列が書かれています。

1

ref: refs/heads/main

これは、「現在の状態は main ブランチの先端にある」ということを意味します。そして、.git/refs/heads/main を開くと、そこに40文字のSHA-1ハッシュが書かれており、これが最新のCommitオブジェクトを指し示しているのです。 Gitのブランチとは、単に特定のコミットを指し示す軽量なポインタ（ファイル）に過ぎません。この事実を知っているだけで、「ブランチを削除したらファイルが全部消えるのでは？」という恐怖がなくなります。

3. 数学で読み解くGit：Diffアルゴリズムとハッシュ関数

Gitがコンフリクトを検知したり、ファイルの差分を表示したりする際、内部では高度なアルゴリズムが動作しています。

3.1 MyersのDiffアルゴリズム

Gitのデフォルトの差分検出アルゴリズムは、Eugene W. Myersによって考案されたアルゴリズムです。2つのテキストファイル $A$ と $B$ があるとき、$A$ を $B$ に変換するための「最小の編集手順（挿入と削除）」を見つける問題は、グラフ理論における最短経路問題としてモデル化できます。

文字列の長さをそれぞれ $N, M$ とし、合計を $V = N + M$ とします。Myersのアルゴリズムでは、編集距離（Edit Distance） $D$ を探索します。このアルゴリズムの時間計算量は以下の式で表されます。

$$ \mathcal{O}(V \cdot D) $$

ここで、ファイル間の差分が小さい（つまり $D$ が小さい）場合、アルゴリズムは非常に高速 $\mathcal{O}(V)$ で動作します。しかし、ファイルが全く異なる場合、$D \approx V$ となり、最悪計算量は $\mathcal{O}(V^2)$ となります。

3.2 Patience Diff と Histogram Diff

Myersのアルゴリズムは優秀ですが、関数やクラスの順序を大きく入れ替えた場合などに、人間にとって直感的ではない（意味の通らない）差分を生成することがあります。これを解決するためにGitは Patience Diff と Histogram Diff を実装しています。

Patience Diffは、「両方のファイルに1度だけ登場するユニークな行」に着目し、それらの最長共通部分列（Longest Common Subsequence: LCS）を見つけます。ユニークな要素の数を $U$ とすると、LCSの計算は以下の計算量で解くことができます。

$$ \mathcal{O}(U \log U) $$

コンフリクト解消が難しいと感じた時は、git diff --histogram や、マージ戦略にこのアルゴリズムを指定する（git merge -s recursive -X histogram）のが一つの手です。

3.3 SHA-1と衝突確率

Gitは全てのオブジェクトをSHA-1ハッシュ値で管理します。ハッシュ空間の大きさは $2^{160}$ です。ハッシュの衝突（異なるコンテンツが同じハッシュ値を持つこと）が起きる確率について、誕生日のパラドックス（Birthday Paradox）を用いて近似すると、衝突確率 $p$ が50%になるために必要なオブジェクト数 $k$ は以下のようになります。

$$ k \approx \sqrt{2 \ln(2)} \cdot 2^{80} \approx 1.2 \times 2^{80} $$

これは天文学的な数字であり、通常のソフトウェア開発において意図せず衝突が発生する確率は実質的にゼロです。そのため、Gitはハッシュ値を「絶対的な一意のID」として信頼して動作しています。

4. ケーススタディ1：間違ったブランチにコミットしてしまった！

【状況】 main ブランチで作業していることに気づかず、新機能のコードをバリバリ書いてしまい、あろうことか git commit までしてしまった。本来は feature/login というブランチを作ってそこで作業するはずだったのに！

解決方法：`git reset` とブランチの作成

Gitでは、コミットは独立したオブジェクトであり、ブランチはただのポインタです。したがって、「新しいブランチを作ってから、現在のブランチのポインタを巻き戻す」という操作で瞬時に解決できます。

1
2
3
4
5
6
7
8
9


# 1. 現在のコミット（間違えて作ったコミット）を指す新しいブランチを作成する
$ git branch feature/login

# 2. mainブランチのポインタを1つ前のコミット（HEAD~1）に巻き戻す
# --keep を使うと、作業ディレクトリの未コミットの変更を維持しつつ安全にリセットできます。
$ git reset --keep HEAD~1

# 3. 正しいブランチに切り替える
$ git checkout feature/login

図解：内部で何が起きたのか？

Mermaidの gitGraph を用いて、この時のブランチポインタの移動を可視化してみましょう。

gitGraph
commit id: "Initial commit"
commit id: "Bugfix"
commit id: "Mistaken Commit" type: HIGHLIGHT
branch feature/login
checkout feature/login
checkout main

最初は main と HEAD が “Mistaken Commit” を指していましたが、git branch feature/login により、そこに新しいポインタが作られます。その後 git reset によって main ポインタだけが “Bugfix” の位置に戻るのです。オブジェクト自体は何も削除されていません。

5. ケーススタディ2：プッシュ済みのコミットを取り消したい！

【状況】 深夜のテンションで書いたバグだらけのコードをコミットし、さらに git push origin main でリモートリポジトリに公開してしまった。重大なバグに気づき青ざめる。

解決策1：歴史を打ち消す `git revert` （推奨・安全）

チーム開発において、すでにプッシュされたコミットの履歴を git reset などで改ざんすることは厳禁です。他の開発者のローカルリポジトリと整合性が取れなくなります。正しいアプローチは、**「間違えたコミットの変更を完全に打ち消す、逆のコミットを新しく作る」**ことです。これが git revert です。

1
2
3
4
5
6
7


# 最新のコミットを打ち消すコミットを作成
$ git revert HEAD
[main 7f3a8b2] Revert "間違えたコミットのメッセージ"
 1 file changed, 1 insertion(+), 10 deletions(-)

# リモートへプッシュ
$ git push origin main

gitGraph
commit id: "Commit A"
commit id: "Commit B (Mistake)"
commit id: "Revert Commit B" type: REVERSE

歴史は進み続け、コードの状態だけが元に戻ります。

解決策2：歴史を改ざんする `git push --force-with-lease`

もしあなたが自分一人しか使っていないブランチにプッシュした直後であれば、歴史を書き換えることも容認されます。

1
2
3
4
5
6
7


# 手元でコミットをリセットして修正
$ git reset --hard HEAD~1
$ git add .
$ git commit -m "Correct implementation"

# リモートの歴史を強制上書き
$ git push origin feature/login --force-with-lease

--force-with-lease は、他人の作業を誤って上書きしてしまう事故を防ぐための安全な強制プッシュです。

6. ケーススタディ3：作業途中で別のブランチに切り替えたい（Stashの魔法）

【状況】 feature/A ブランチで新機能の実装中、ソースコードはまだコンパイルも通らない中途半端な状態。突然、上司から「main ブランチの本番環境に緊急のバグがあるから、今すぐ直してくれ！」と指示が飛んできた。

解決方法：`git stash` による退避

git stash は、未コミットの変更を一時的な領域に退避させるコマンドです。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 1. 作業中の変更を退避
$ git stash push -m "WIP: feature A partially implemented"

# 2. mainブランチに切り替え可能に
$ git checkout main
# ...（緊急バグ修正作業を行い、コミット・プッシュ）...

# 3. 作業が終わったら元のブランチに戻る
$ git checkout feature/A

# 4. 退避していた変更を復元
$ git stash pop

git stash を実行すると、Gitは内部的に2つの特殊なコミットオブジェクトを生成し、refs/stash という参照に保存します。つまり、Stashも結局のところ「名前のつかない一時的なコミット」なのです。

7. ケーススタディ4：恐怖の “Detached HEAD” 状態

【状況】 過去の特定の時点のコードを確認したくて git checkout 9f8a7b6 と実行した。すると You are in 'detached HEAD' state. と表示された。そのままコミットしたが、ブランチを切り替えたらコミットが消えてしまった！

Detached HEADのメカニズム

通常 HEAD は refs/heads/main などのブランチを指し示しています。しかし、特定のコミットを直接チェックアウトすると、HEAD が直接コミットオブジェクトを指すようになります。これを Detached HEAD（分離したHEAD） と呼びます。

graph TD
A["Commit A"] --> B["Commit B"]
B --> C["Commit C"]
C --> D["Commit D"]
BranchMain["Branch: main"] --> D
HEAD["HEAD"] --> B
style HEAD fill:#f9f,stroke:#333,stroke-width:4px

この状態でコミットを重ねても、どのブランチもその新しいコミットを追跡してくれません。他のブランチに切り替えた瞬間、新しいコミットは迷子になります。

解決策：新しいブランチとして保存する

現在いる場所に新しいブランチを作成すれば解決します。

1
2


# 現在のHEADの位置に新しいブランチを作り、そこに切り替える
$ git checkout -b feature/recovered-work

8. ケーススタディ5：マージとリベースでのコンフリクト解消

【状況】 git merge や git rebase を実行したところ、CONFLICT (content) と表示され、プロセスが中断された。

マージ（Merge）とリベース（Rebase）の違い

Merge（マージ） 2つのブランチの最新コミットと共通の祖先を用いた3-way mergeを行い、マージコミットを作成します。
Rebase（リベース） 現在のブランチのコミットを一時保存し、ターゲットの先端に適用し直します。歴史が一直線になります。

gitGraph
commit id: "M1"
commit id: "M2"
branch feature
checkout feature
commit id: "F1"
commit id: "F2"
checkout main
commit id: "M3"
merge feature

コンフリクトの解消法

コンフリクトが発生したファイルには、以下のようなマーカーが挿入されています。

1
2
3
4
5


<<<<<<< HEAD
const apiUrl = "https://api.production.example.com";
=======
const apiUrl = "https://api.staging.example.com";
>>>>>>> feature/new-api

解決手順は極めてシンプルです。

マーカーを削除し、正しいコードに修正する。

1
2
3


const apiUrl = process.env.NODE_ENV === 'production'
 ? "https://api.production.example.com"
 : "https://api.staging.example.com";

解決したファイルをステージングに追加する。 git add は「コンフリクトを解決したことをGitに伝える」役割を持っています。
1

$ git add index.js

プロセスを完了させる。

1
2
3
4
5


# マージの場合
$ git commit -m "Resolve merge conflict in index.js"

# リベースの場合
$ git rebase --continue

パニックになったら $ git merge --abort または $ git rebase --abort でいつでも中止できます。

9. ケーススタディ6：コミット履歴がぐちゃぐちゃ！ `git rebase -i`

【状況】 「タイポ修正」「やっぱり修正」「テスト追加」など、細かいコミットが大量に発生してしまった。このまま main にマージすると履歴が汚くなる。

解決策：インタラクティブリベース

git rebase -i（interactive）を使うと、過去のコミットの順番を入れ替えたり、複数のコミットを1つにまとめたり（squash）、コミットメッセージを修正したりできます。

1
2


# 直近3つのコミットを整理する
$ git rebase -i HEAD~3

エディタが開き、以下のように表示されます。

1
2
3


pick 1a2b3c4 タイポ修正
pick 2b3c4d5 やっぱり修正
pick 3c4d5e6 テスト追加

これを以下のように書き換えます。

1
2
3


pick 1a2b3c4 機能Xの実装
squash 2b3c4d5 やっぱり修正
squash 3c4d5e6 テスト追加

保存して閉じると、これら3つのコミットが1つに美しく統合されます。

10. ケーススタディ7：バグがいつ混入したかわからない！ `git bisect`

【状況】 現在の main ブランチにはバグがあるが、1ヶ月前のリリース時は正常だった。どのコミットでバグが混入したのか特定したいが、コミットが100個以上あって手作業では無理！

解決策：二分探索によるバグ特定

Gitには、バグが混入したコミットを数学的な二分探索（Binary Search）で見つけ出すツールが組み込まれています。計算量は $\mathcal{O}(\log N)$ なので、1000個のコミットがあっても約10回のテストで特定できます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 探索を開始
$ git bisect start

# 現在のコミットにはバグがある（bad）
$ git bisect bad

# 1ヶ月前（例えばハッシュが a1b2c3d）は正常だった（good）
$ git bisect good a1b2c3d

# Gitが自動的に中間のコミットをチェックアウトするので、テストを実行する
# テストが成功したら：
$ git bisect good
# テストが失敗したら：
$ git bisect bad

これを繰り返すだけで、Gitが「このコミットが最初のBadコミットです」と正確に教えてくれます。終わったら $ git bisect reset で元の状態に戻ります。

11. 究極のセーフティネット：`git reflog`

Gitでのあらゆる「やらかし」に対する最終奥義が git reflog です。Gitはローカルでの操作履歴（HEADの移動履歴）を一定期間すべて記録しています。ブランチを削除してしまったり、誤ったリセットをしてしまったりしても、git reflog で過去のハッシュを見つけ出し、そこに git reset --hard するだけで復旧可能です。

1
2
3


$ git reflog
9f8a7b6 (HEAD -> main) HEAD@{0}: commit: Add new feature
1a2b3c4 HEAD@{1}: reset: moving to HEAD~1

12. おわりに

Git初心者が陥りやすいミスと、その背後にあるGitの仕組み、そして解決方法について非常に詳細に解説してきました。間違ったブランチへのコミット、プッシュ済みコミットの打ち消し、Stashの活用、Detached HEADからの生還、そしてコンフリクトの解消。これらすべてにおいて重要なのは、「Gitが背後でどのようなオブジェクトとポインタを操作しているのか」をイメージすることです。

数式で表されるような厳格なDiffアルゴリズムによってファイルの差分が計算され、暗号学的なハッシュ関数によって歴史の整合性が担保されている。この美しい設計思想を理解すれば、Gitは決して「得体の知れないブラックボックス」ではなく、あなたのソースコードを強固に守る最強の盾であることがわかるはずです。

次回「やっちまった！」と思ったときは、慌ててターミナルを閉じるのではなく、深呼吸して git status を打ち込んでみてください。Gitは必ず、復旧のためのヒントをあなたに提示してくれます。

Version Control on kenji.blog

【Gitコマンド】rebaseとmergeの違いと、実務での正しい使い分け

1. はじめに：なぜ「mergeかrebaseか」は永遠の課題なのか

2. Gitの内部構造：コミットハッシュとオブジェクトモデル

2.1 コミットハッシュの暗号学的性質

3. グラフ理論とDAG：Git履歴の数学的モデル

3.1 DAG（有向非巡回グラフ）とは

3.2 トポロジカルソートと履歴の順序

4. git merge のメカニズムと種類

4.1 Fast-Forward マージ（–ff）

4.2 Non-Fast-Forward マージ（–no-ff）

4.3 3ウェイマージ（3-Way Merge）アルゴリズム

5. git rebase のメカニズムと履歴の再構築

5.1 Rebaseの背後にある動き

5.2 インタラクティブリベース（Interactive Rebase）

6. リベースの黄金則（The Golden Rule of Rebase）

6.1 なぜパブリックな履歴をリベースしてはいけないのか？

7. コンフリクト（競合）の解決と git rebase –continue

7.1 Mergeにおけるコンフリクト解決

7.2 Rebaseにおけるコンフリクト解決

8. 実務での正しい使い分け（ワークフロー実践）

8.1 【シナリオ1】ローカルでの作業履歴の整理（Rebaseの利用）

8.2 【シナリオ2】最新のmainブランチへの追従（Rebaseの利用）

8.3 【シナリオ3】完成した機能の統合（Mergeの利用）

9. 結論（まとめ）

Git初心者が陥りやすいミスと解決コマンド集（コンフリクト解消など）

Git初心者が陥りやすいミスと解決コマンド集（コンフリクト解消など）

1. はじめに：なぜGitでミスをしてしまうのか？

2. Gitの深淵：.git ディレクトリの内部構造を理解する

2.1 オブジェクトモデル：Blob, Tree, Commit

2.2 HEADと参照（Refs）の正体

3. 数学で読み解くGit：Diffアルゴリズムとハッシュ関数

3.1 MyersのDiffアルゴリズム

3.2 Patience Diff と Histogram Diff

3.3 SHA-1と衝突確率

4. ケーススタディ1：間違ったブランチにコミットしてしまった！

解決方法：git reset とブランチの作成

図解：内部で何が起きたのか？

5. ケーススタディ2：プッシュ済みのコミットを取り消したい！

解決策1：歴史を打ち消す git revert （推奨・安全）

解決策2：歴史を改ざんする git push --force-with-lease

6. ケーススタディ3：作業途中で別のブランチに切り替えたい（Stashの魔法）

解決方法：git stash による退避

7. ケーススタディ4：恐怖の “Detached HEAD” 状態

Detached HEADのメカニズム

解決策：新しいブランチとして保存する

8. ケーススタディ5：マージとリベースでのコンフリクト解消

マージ（Merge）とリベース（Rebase）の違い

コンフリクトの解消法

9. ケーススタディ6：コミット履歴がぐちゃぐちゃ！ git rebase -i

解決策：インタラクティブリベース

10. ケーススタディ7：バグがいつ混入したかわからない！ git bisect

解決策：二分探索によるバグ特定

11. 究極のセーフティネット：git reflog

12. おわりに

2. Gitの深淵：`.git` ディレクトリの内部構造を理解する

解決方法：`git reset` とブランチの作成

解決策1：歴史を打ち消す `git revert` （推奨・安全）

解決策2：歴史を改ざんする `git push --force-with-lease`

解決方法：`git stash` による退避

9. ケーススタディ6：コミット履歴がぐちゃぐちゃ！ `git rebase -i`

10. ケーススタディ7：バグがいつ混入したかわからない！ `git bisect`

11. 究極のセーフティネット：`git reflog`