Git Advanced Workflows

高度な Git テクニックをマスターして、クリーンな履歴を保つ、効果的に協業する、そして自信を持ってどんな状況からでも回復できるようになります。

このスキルを使用しないケース

• タスクが Git 高度なワークフローに関連していない場合
• このスコープ外の異なるドメインやツールが必要な場合

指示

• 目標、制約条件、必要な入力を明確にする
• 関連するベストプラクティスを適用し、結果を検証する
• 実行可能なステップと検証方法を提供する
• 詳細な例が必要な場合は、resources/implementation-playbook.md を開く

このスキルを使用するケース

• マージ前のコミット履歴のクリーンアップ
• ブランチ間での特定のコミットの適用
• バグを引き入れたコミットの検出
• 複数の機能に同時に取り組む
• Git ミスまたは失われたコミットからの回復
• 複雑なブランチワークフローの管理
• レビュー用のクリーンな PR の準備
• 分岐したブランチの同期

コアコンセプト

1. Interactive Rebase

Interactive rebase は Git 履歴編集のマルチツールです。

一般的な操作:

• pick: コミットをそのまま保持
• reword: コミットメッセージを変更
• edit: コミット内容を修正
• squash: 前のコミットと結合
• fixup: squash に似ているがメッセージは破棄
• drop: コミット全体を削除

基本的な使い方:

# 最後の5つのコミットをリベース
git rebase -i HEAD~5

# 現在のブランチ上のすべてのコミットをリベース
git rebase -i $(git merge-base HEAD main)

# 特定のコミットへリベース
git rebase -i abc123

2. Cherry-Picking

ブランチ全体をマージせずに、1つのブランチから別のブランチに特定のコミットを適用します。

# 単一のコミットを cherry-pick
git cherry-pick abc123

# コミットの範囲を cherry-pick (開始は除外)
git cherry-pick abc123..def456

# コミットせずに cherry-pick (変更のみをステージ)
git cherry-pick -n abc123

# cherry-pick してコミットメッセージを編集
git cherry-pick -e abc123

3. Git Bisect

コミット履歴をバイナリサーチしてバグを引き入れたコミットを見つけます。

# bisect を開始
git bisect start

# 現在のコミットを悪いものとしてマーク
git bisect bad

# 既知の良いコミットをマーク
git bisect good v1.0.0

# Git は中央のコミットをチェックアウト - テスト
# その後、良い、または悪いとマーク
git bisect good  # または: git bisect bad

# バグが見つかるまで継続
# 完了したら
git bisect reset

自動化された Bisect:

# スクリプトを使用して自動的にテスト
git bisect start HEAD v1.0.0
git bisect run ./test.sh

# test.sh は良い場合は 0 を、悪い場合は 1-127 (125 除く) を返す必要がある

4. Worktrees

stash またはスイッチなしで複数のブランチで同時に作業します。

# 既存の worktree をリスト表示
git worktree list

# フィーチャーブランチ用に新しい worktree を追加
git worktree add ../project-feature feature/new-feature

# worktree を追加して新しいブランチを作成
git worktree add -b bugfix/urgent ../project-hotfix main

# worktree を削除
git worktree remove ../project-feature

# 古い worktree をクリーンアップ
git worktree prune

5. Reflog

あなたの安全ネット - すべての ref の移動を追跡します。削除されたコミットも含みます。

# reflog を表示
git reflog

# 特定のブランチの reflog を表示
git reflog show feature/branch

# 削除されたコミットを復元
git reflog
# コミット hash を探す
git checkout abc123
git branch recovered-branch

# 削除されたブランチを復元
git reflog
git branch deleted-branch abc123

実践的なワークフロー

ワークフロー1: PR 前にフィーチャーブランチをクリーンアップ

# フィーチャーブランチで開始
git checkout feature/user-auth

# Interactive rebase でクリーンアップ
git rebase -i main

# Rebase 操作の例:
# - 「typo を修正」コミットを squash
# - 明確さのためにコミットメッセージを reword
# - コミットを論理的に並び替え
# - 不要なコミットを削除

# クリーンなブランチを強制プッシュ (他の人が使用していない場合は安全)
git push --force-with-lease origin feature/user-auth

ワークフロー2: ホットフィックスを複数のリリースに適用

# main 上でフィックスを作成
git checkout main
git commit -m "fix: critical security patch"

# リリースブランチに適用
git checkout release/2.0
git cherry-pick abc123

git checkout release/1.9
git cherry-pick abc123

# コンフリクトが発生した場合は対処
git cherry-pick --continue
# または
git cherry-pick --abort

ワークフロー3: バグ導入の検出

# bisect を開始
git bisect start
git bisect bad HEAD
git bisect good v2.1.0

# Git は中央のコミットをチェックアウト - テストを実行
npm test

# テストが失敗した場合
git bisect bad

# テストが成功した場合
git bisect good

# Git は自動的に次のコミットをチェックアウトしてテスト
# バグが見つかるまで繰り返す

# 自動化版
git bisect start HEAD v2.1.0
git bisect run npm test

ワークフロー4: マルチブランチ開発

# メインプロジェクトディレクトリ
cd ~/projects/myapp

# 緊急なバグフィックス用に worktree を作成
git worktree add ../myapp-hotfix hotfix/critical-bug

# 別のディレクトリでホットフィックスに取り組む
cd ../myapp-hotfix
# 変更を行い、コミット
git commit -m "fix: resolve critical bug"
git push origin hotfix/critical-bug

# 中断なしにメインの作業に戻す
cd ~/projects/myapp
git fetch origin
git cherry-pick hotfix/critical-bug

# 完了したらクリーンアップ
git worktree remove ../myapp-hotfix

ワークフロー5: ミスから回復

# 間違ったコミットにリセット
git reset --hard HEAD~5  # しまった!

# reflog を使って失われたコミットを見つける
git reflog
# 出力:
# abc123 HEAD@{0}: reset: moving to HEAD~5
# def456 HEAD@{1}: commit: my important changes

# 失われたコミットを復元
git reset --hard def456

# または失われたコミットからブランチを作成
git branch recovery def456

高度なテクニック

Rebase vs Merge 戦略

Rebase を使用する場合:

• プッシュ前にローカルコミットをクリーンアップ
• フィーチャーブランチを main の最新に保つ
• レビューを簡単にするための直線的な履歴を作成

Merge を使用する場合:

• 完成したフィーチャーを main に統合
• 協業の正確な履歴を保持
• 他の人が使用する公開ブランチ

# フィーチャーブランチを main の変更で更新 (rebase)
git checkout feature/my-feature
git fetch origin
git rebase origin/main

# コンフリクトを処理
git status
# ファイルのコンフリクトを解決
git add .
git rebase --continue

# または merge を使用
git merge origin/main

Autosquash ワークフロー

Rebase 中に自動的に fixup コミットを squash します。

# 初期コミットを作成
git commit -m "feat: add user authentication"

# その後、そのコミットの何かを修正
# 変更をステージ
git commit --fixup HEAD  # または特定のコミット hash を指定

# さらに変更を加える
git commit --fixup abc123

# autosquash で rebase
git rebase -i --autosquash main

# Git は自動的に fixup コミットをマーク

コミット分割

1つのコミットを複数の論理的なコミットに分割します。

# interactive rebase を開始
git rebase -i HEAD~3

# 分割するコミットを 'edit' でマーク
# Git はそのコミットで停止

# コミットをリセットするが変更は保持
git reset HEAD^

# 論理的なチャンクでステージしてコミット
git add file1.py
git commit -m "feat: add validation"

git add file2.py
git commit -m "feat: add error handling"

# rebase を継続
git rebase --continue

部分的な Cherry-Pick

コミットから特定のファイルだけを cherry-pick します。

# コミット内のファイルを表示
git show --name-only abc123

# コミットから特定のファイルをチェックアウト
git checkout abc123 -- path/to/file1.py path/to/file2.py

# ステージしてコミット
git commit -m "cherry-pick: apply specific changes from abc123"

ベストプラクティス

1. 常に --force-with-lease を使用: --force より安全で、他の人の作業を上書きするのを防ぎます
2. ローカルコミットのみをリベース: プッシュして共有されたコミットをリベースしないでください
3. 説明的なコミットメッセージ: 未来のあなたは現在のあなたに感謝するでしょう
4. アトミックコミット: 各コミットは単一の論理的な変更であるべきです
5. 強制プッシュ前にテスト: 履歴の再書き込みが何も壊していないことを確認します
6. Reflog を意識: Reflog はあなたの安全ネットで 90 日間有効です
7. リスキーな操作前にブランチを作成: 複雑な rebase 前にバックアップブランチを作成します

# 安全な強制プッシュ
git push --force-with-lease origin feature/branch

# リスキーな操作前にバックアップを作成
git branch backup-branch
git rebase -i main
# 何か問題が発生した場合
git reset --hard backup-branch

よくある落とし穴

• 公開ブランチをリベース: 協業者のための履歴コンフリクトの原因
• Lease なしで強制プッシュ: チームメイトの作業を上書きする可能性
• Rebase で作業を失う: コンフリクトを注意深く解決し、rebase 後にテスト
• Worktree クリーンアップを忘れる: 孤立した worktree はディスク容量を消費
• 実験前にバックアップを取らない: 常に安全ブランチを作成
• ダーティなワーキングディレクトリで Bisect: Bisect 前にコミットまたは stash

復旧コマンド

# 進行中の操作を中止
git rebase --abort
git merge --abort
git cherry-pick --abort
git bisect reset

# 特定のコミットのバージョンにファイルを復元
git restore --source=abc123 path/to/file

# 最後のコミットを取り消すが変更は保持
git reset --soft HEAD^

# 最後のコミットを取り消して変更を破棄
git reset --hard HEAD^

# 削除されたブランチを復元 (90日以内)
git reflog
git branch recovered-branch abc123

リソース

• references/git-rebase-guide.md: Interactive rebase の深い理解
• references/git-conflict-resolution.md: 高度なコンフリクト解決戦略
• references/git-history-rewriting.md: Git 履歴の安全な再書き込み
• assets/git-workflow-checklist.md: PR 前クリーンアップチェックリスト
• assets/git-aliases.md: 高度なワークフロー用の便利な Git エイリアス
• scripts/git-clean-branches.sh: マージ済みおよび古いブランチのクリーンアップ

制限事項

• このスキルは、タスクが上記で説明されたスコープと明確に一致する場合にのみ使用してください。
• 出力を環境固有の検証、テスト、または専門家による審査の代わりとして扱わないでください。
• 必要な入力、権限、安全上の境界、または成功基準が不明な場合は、停止して明確化を求めてください。