📈

Git履歴をきれいに整理する3つの方法 - 実践的比較ガイド

2025/05/31に公開

はじめに

機能開発を終えた後、コミット履歴が混沌としていることはありませんか？WIPコミット、修正コミット、試行錯誤の跡が散乱し、PRレビューが困難になることも多々あります。PRレビューで見落としがあると後工程でバグが発覚し、工数は想定以上に膨れ上がって、納期に間に合わせるためにさらに試行錯誤を繰り返し、そのままコミットしてPRレビューでさらに見落とし...(以下繰り返し)

この記事では、実際のサンプルリポジトリを使って、Git履歴を整理する3つの方法を比較します。

サンプルリポジトリの作成

サンプルとして「Todoアプリ」の開発過程を再現してみましょう。

初期セットアップ

# プロジェクトディレクトリの作成
mkdir todo-app-demo
cd todo-app-demo
git init

# 初期コミット
echo "# Todo App" > README.md
git add README.md
git commit -m "Initial commit"

混沌とした開発履歴の再現

実際の開発では、以下のような流れでコミットが積み重なります。

# 1. HTMLファイルを作成（でも不完全）
echo "<h1>Todo</h1>" > index.html
git add index.html
git commit -m "WIP: add html"

# 2. CSS追加
echo "body { margin: 0; }" > style.css
git add style.css
git commit -m "add css"

# 3. あ、HTMLでCSS読み込み忘れた
echo '<link rel="stylesheet" href="style.css">' >> index.html
git add index.html
git commit -m "fix: add css link"

# 4. JavaScript開始
echo "console.log('start');" > app.js
git add app.js
git commit -m "add js"

# 5. HTMLでJS読み込み
echo '<script src="app.js"></script>' >> index.html
git add index.html
git commit -m "oops forgot script tag"

# 6. Todo機能実装
cat > app.js << 'EOF'
let todos = [];
function addTodo(text) {
  todos.push(text);
}
EOF
git add app.js
git commit -m "implement todo logic"

# 7. タイポ修正
cat > app.js << 'EOF'
let todos = [];
function addTodo(text) {
  todos.push({ text: text, done: false });
}
EOF
git add app.js
git commit -m "fix todo structure"

# 8. UI追加
cat > index.html << 'EOF'
<!DOCTYPE html>
<html>
<head>
  <link rel="stylesheet" href="style.css">
</head>
<body>
  <h1>My Todo App</h1>
  <input id="todoInput" type="text">
  <button onclick="addTodo()">Add</button>
  <ul id="todoList"></ul>
  <script src="app.js"></script>
</body>
</html>
EOF
git add index.html
git commit -m "update UI"

# 9. スタイル改善
cat > style.css << 'EOF'
body {
  font-family: Arial, sans-serif;
  max-width: 600px;
  margin: 0 auto;
  padding: 20px;
}
h1 { color: #333; }
button { 
  background: #007bff;
  color: white;
  border: none;
  padding: 5px 10px;
}
EOF
git add style.css
git commit -m "improve styles"

# 10. JavaScript完成
cat > app.js << 'EOF'
let todos = [];

function addTodo() {
  const input = document.getElementById('todoInput');
  const text = input.value.trim();
  if (text) {
    todos.push({ text: text, done: false });
    input.value = '';
    renderTodos();
  }
}

function renderTodos() {
  const list = document.getElementById('todoList');
  list.innerHTML = todos.map((todo, i) => 
    `<li>${todo.text}</li>`
  ).join('');
}
EOF
git add app.js
git commit -m "complete todo functionality"

# 11. READMEを更新
cat > README.md << 'EOF'
# Todo App

A simple todo application built with vanilla JavaScript.

## Usage
Open index.html in your browser.
EOF
git add README.md
git commit -m "update readme"

# 12. あ、削除機能忘れてた
cat >> app.js << 'EOF'

function deleteTodo(index) {
  todos.splice(index, 1);
  renderTodos();
}
EOF
git add app.js
git commit -m "add delete feature"

現在の履歴を確認

git log --oneline

出力例

f8a9b2c add delete feature
e7d6c5b update readme
d4a3b2c complete todo functionality
c3b2a1d improve styles
b2a1d9e update UI
a1d9e8f fix todo structure
d9e8f7g implement todo logic
e8f7g6h oops forgot script tag
f7g6h5i add js
g6h5i4j fix: add css link
h5i4j3k add css
i4j3k2l WIP: add html
j3k2l1m Initial commit

これは典型的な「実際の開発履歴」ですね。試行錯誤やうっかりミスが混在しています。
こういった作業そのままをレビュー対象にするのではなく、わかりやすい開発履歴を作成する方法を考えましょう。

方法1 Interactive Rebase (Squash)

最も一般的な方法から始めます。

作業用ブランチの作成

# 現在の状態を保存
git tag backup-original

# 方法1用のブランチ作成
git checkout -b method1-squash

Interactive Rebaseの実行

# 初期コミットを除く全てを対象に
git rebase -i j3k2l1m

エディタが開いたら、以下のように編集します。

pick i4j3k2l WIP: add html
squash h5i4j3k add css
squash g6h5i4j fix: add css link
squash f7g6h5i add js
squash e8f7g6h oops forgot script tag
squash b2a1d9e update UI
pick d9e8f7g implement todo logic
squash a1d9e8f fix todo structure
squash d4a3b2c complete todo functionality
squash f8a9b2c add delete feature
pick c3b2a1d improve styles
pick e7d6c5b update readme

保存して閉じると、コミットメッセージの編集画面が表示されます。

# 最初のsquashグループ
feat: Initial UI setup with HTML, CSS, and JavaScript

# 2番目のsquashグループ  
feat: Implement todo functionality with add and delete features

# 残りはそのまま

メリット ✅

標準的で簡単
- SourceTree, GitKraken, VS Codetといったほとんどのツールでサポートしています。
部分的な履歴保持
- 重要な変更は独立したコミットとして残る
- 元のタイムスタンプが保持される
チームでの受け入れやすさ
- 誰でも知っている方法(ですよね？)
- 特別な説明不要

デメリット ❌

コミット順序の制約

# エラー例 依存関係のあるコミットの順序を変更
error: could not apply d9e8f7g... implement todo logic
hint: Resolve all conflicts manually

メッセージの整理が面倒
- squash時に全メッセージが連結してしまいます
- 手動での大幅な編集が必要です
理想的でない構造
- 「fix」「oops」などの痕跡が見える
- 論理的な開発フローにならない

結果確認

git log --oneline
# 出力例：
# a5b6c7d update readme
# b6c7d8e improve styles  
# c7d8e9f feat: Implement todo functionality with add and delete features
# d8e9f0g feat: Initial UI setup with HTML, CSS, and JavaScript
# j3k2l1m Initial commit

方法2 ソフトリセット + 再構築

完全にクリーンな履歴を作る方法です。

準備

# 元のブランチに戻る
git checkout main

# 方法2用のブランチ作成
git checkout -b method2-soft-reset

# 現在の完全な状態をタグで保存（重要！）
git tag working-state

ソフトリセットの実行

# 初期コミットまでリセット（ファイルは一切変更されません）
git reset --soft j3k2l1m

# 状態確認 - 全ファイルがステージングされている
git status

理想的な履歴の再構築

開発の論理的な流れに沿って、コミットを再作成します。

# ステージングをクリア
git reset

# Step 1: プロジェクト構造とHTML
git add index.html
git commit -m "feat: Create basic HTML structure

- Add semantic HTML5 structure
- Include input field and todo list container
- Set up script and style references"

# Step 2: スタイリング
git add style.css  
git commit -m "feat: Add responsive styling

- Modern, clean design with max-width container
- Button styling with hover states
- Typography and spacing improvements"

# Step 3: Core機能実装
git add app.js
git commit -m "feat: Implement todo functionality

- Add todo items with text input
- Delete todos by index
- Dynamic rendering of todo list
- Clear input after adding"

# Step 4: ドキュメント
git add README.md
git commit -m "docs: Add project documentation

- Basic usage instructions
- Project description"

メリット ✅

完璧な履歴構造

# 論理的な開発フローになります
HTML構造 → スタイル → 機能実装 → ドキュメント

プロフェッショナルな印象
- 新規開発者が理解しやすい
- ベストプラクティスの見本

100%安全

# tagをつけたので、いつでも元に戻れる
git checkout working-state
# または
git reset --hard working-state

理想的なコミットメッセージ
- Conventional Commitsに準拠できます
- 何をしたか明確です

デメリット ❌

時間がかかる
- 各コミットを手動作成する必要があります
- ファイルの関係性を理解する必要があります
履歴の改変
- 実際の開発過程とは異なります
- 「歴史の書き換え」を行うことになります
チームの理解が必要
- おそらく一般的ではない方法です
- チームへの説明とトレーニングが必要になります

結果確認

git log --oneline --graph
# 出力例：
# * d9e8f7g docs: Add project documentation
# * e8f7g6h feat: Implement todo functionality
# * f7g6h5i feat: Add responsive styling
# * g6h5i4j feat: Create basic HTML structure
# * j3k2l1m Initial commit

方法3 チェリーピック

既存のコミットから必要なものだけを選んで新しい履歴を作ります。

準備

# 元のブランチに戻る
git checkout main

# 方法3用の新しいブランチを初期コミットから作成
git checkout j3k2l1m
git checkout -b method3-cherry-pick

戦略的なチェリーピック

# 1. 最終的なHTMLを取得
git cherry-pick b2a1d9e  # update UI

# 2. 最終的なCSSを取得
git cherry-pick c3b2a1d  # improve styles

# 3. 完成したJavaScriptを取得
git cherry-pick d4a3b2c  # complete todo functionality

# コンフリクトが発生した場合の対処
# （app.jsが存在しないため）
git add app.js
git cherry-pick --continue

# 4. 削除機能を追加
git cherry-pick f8a9b2c  # add delete feature

# 5. READMEを取得
git cherry-pick e7d6c5b  # update readme

メリット ✅

選択的な取り込み
- 不要な中間コミットを除外します
- クリーンな履歴を保ちます
既存コミットの活用
- コミットメッセージを再利用できます
- 作者情報が保持されます
柔軟性
- 順序を自由に変更可能です
- 複数ブランチからも選択可能です

デメリット ❌

コンフリクトの管理

# ファイルが存在しない場合のエラー
error: could not apply d4a3b2c...
hint: after resolving the conflicts, mark the corrected paths

依存関係の考慮
- どのコミットが他に依存するかの把握が必要です
- 試行錯誤が発生しがちです
中途半端な結果
- 元のメッセージが適切でない場合もありえます
- 追加の編集が必要になりがちです

結果確認

git log --oneline
# 出力例：
# a9b8c7d update readme
# b8c7d6e add delete feature  
# c7d6e5f complete todo functionality
# d6e5f4g improve styles
# e5f4g3h update UI
# j3k2l1m Initial commit

3つの方法の実践的比較

作業時間の比較

大規模ではない場合での推定作業時間です

方法	時間	作業内容
Squash	5-10分	rebase実行 + メッセージ編集
ソフトリセット	15-30分	全コミット再作成 + メッセージ作成
チェリーピック	10-20分	選択 + コンフリクト解決

結果の品質比較

観点	Squash	ソフトリセット	チェリーピック
履歴の論理性	⭐⭐	⭐⭐⭐	⭐⭐
メッセージ品質	⭐⭐	⭐⭐⭐	⭐⭐
作業の安全性	⭐⭐	⭐⭐⭐	⭐
学習コスト	⭐	⭐⭐⭐	⭐⭐

コマンド数の比較

# Squash: 3-4コマンド
git checkout -b cleanup
git rebase -i HEAD~10
# (エディタで編集)
git push --force-with-lease

# ソフトリセット: 8-10コマンド  
git checkout -b cleanup
git tag backup
git reset --soft <commit>
git reset
git add <files>
git commit -m "..."
# (繰り返し)

# チェリーピック: 6-8コマンド
git checkout -b cleanup  
git checkout <base>
git cherry-pick <commit1>
git cherry-pick <commit2>
# (コンフリクト解決含む)

実際のプロジェクトでの使い分け

個人プロジェクト/小規模修正

# Squashが最適
git rebase -i main
# 2-3個のコミットをまとめる

理由
- 素早く完了します
- 十分にクリーンです
- 追加の説明が不要です

チーム開発・機能ブランチ

# Squash + メッセージ整理
git rebase -i origin/main
# 機能単位でまとめる

理由
- チーム全員が理解できます
- レビューしやすい粒度になります
- 履歴の追跡が可能です

オープンソース貢献・重要な機能

# ソフトリセット + 再構築
git reset --soft origin/main  
# 理想的な履歴を構築

理由
- 最高品質の履歴になります
- 教育的価値があります
- プロジェクトの資産になります

複数ブランチの統合

# チェリーピック
git cherry-pick feature-a~2..feature-a
git cherry-pick hotfix-b

理由
- 選択的な取り込みができます
- 異なるソースから収集できます
- 不要な変更を除外します

ベストプラクティス

1. 必ずバックアップを作成

# 複数の方法でバックアップ
git branch backup-$(date +%Y%m%d-%H%M%S)
git tag backup-before-cleanup
git stash  # 未コミットの変更がある場合

2. コミットメッセージの規約

# .gitmessageテンプレート作成
cat > .gitmessage << 'EOF'
# <type>: <subject> (50文字以内)
#
# <body> (なぜこの変更が必要か)
#
# Type:
#   feat:     新機能
#   fix:      バグ修正
#   docs:     ドキュメントのみ
#   style:    フォーマット変更
#   refactor: リファクタリング
#   test:     テスト追加・修正
#   chore:    ビルドプロセスや補助ツール
EOF

git config commit.template .gitmessage

3. 履歴整理のタイミング

# PR作成前
git checkout feature-branch
git rebase -i main
# 整理してからPR

# マージ前
git checkout feature-branch  
git rebase main  # 最新を取り込み
git rebase -i main  # 履歴整理

4. Force Pushの安全な使い方

# 通常のforce pushは危険
git push --force  # ❌

# より安全な方法
git push --force-with-lease  # ✅
# 他の人の変更を上書きしない

トラブルシューティング

rebase中のコンフリクト

# 状況確認
git status
git diff

# 解決方法1: 手動で解決
# ファイルを編集してコンフリクトマーカーを除去
git add <resolved-files>
git rebase --continue

# 解決方法2: 特定のコミットをスキップ
git rebase --skip

# 解決方法3: 中止して最初からやり直し
git rebase --abort

間違えた時の復旧

# reflogで履歴を確認
git reflog

# 特定の状態に戻る
git reset --hard HEAD@{2}

# バックアップタグから復元
git reset --hard backup-original

まとめ

Git履歴の整理は、コードレビューの効率化とプロジェクトの保守性向上に重要です。

推奨アプローチ

日常的には Interactive Rebase
- 簡単で十分な品質
- チーム全員が使える
重要な機能ではソフトリセット
- 完璧な履歴を作成
- 将来の参考資料として価値
特殊なケースでチェリーピック
- 複雑な統合作業
- 選択的な変更の取り込み

最も重要なのは、チームで合意したルールに従うことです。完璧な履歴も大切ですが、チームの生産性とのバランスを考えましょう。

おまけ便利なGitエイリアス集

# ~/.gitconfig に追加

[alias]
    # 見やすいログ表示
    lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset'
    
    # 最近のコミットを簡潔に
    recent = log --oneline -10
    
    # インタラクティブrebaseのショートカット
    rbi = rebase -i
    
    # 現在のブランチの履歴整理
    cleanup = !git rebase -i $(git merge-base main HEAD)
    
    # 安全なforce push
    pushf = push --force-with-lease
    
    # バックアップブランチ作成
    backup = !git branch backup-$(git symbolic-ref --short HEAD)-$(date +%Y%m%d-%H%M%S)

これらのエイリアスを使えば、履歴整理がより効率的になります！

質問やフィードバックがあれば、コメント欄でお待ちしています。Happy Git life! 🎉

はじめに

サンプルリポジトリの作成

初期セットアップ

混沌とした開発履歴の再現

現在の履歴を確認

方法1 Interactive Rebase (Squash)

作業用ブランチの作成

Interactive Rebaseの実行

メリット ✅

デメリット ❌

結果確認

方法2 ソフトリセット + 再構築

準備

ソフトリセットの実行

理想的な履歴の再構築

メリット ✅

デメリット ❌

結果確認

方法3 チェリーピック

準備

戦略的なチェリーピック

メリット ✅

デメリット ❌

結果確認

3つの方法の実践的比較

作業時間の比較

結果の品質比較

コマンド数の比較

実際のプロジェクトでの使い分け

個人プロジェクト/小規模修正

チーム開発・機能ブランチ

オープンソース貢献・重要な機能

複数ブランチの統合

ベストプラクティス

1. 必ずバックアップを作成

2. コミットメッセージの規約

3. 履歴整理のタイミング

4. Force Pushの安全な使い方

トラブルシューティング

rebase中のコンフリクト

間違えた時の復旧

まとめ

推奨アプローチ

おまけ 便利なGitエイリアス集

Discussion

おまけ便利なGitエイリアス集