Git Mastery - 完全なGit専門知識

🚨 重要ガイドライン

Windowsファイルパスの必須要件

必須: Windowsでファイルパスを使用する場合は常にバックスラッシュを使用

Windowsで編集または書き込みツールを使用する場合、ファイルパスでバックスラッシュ(\)を使用する必要があり、フォワードスラッシュ(/)は使用しません。

例:

• ❌ 間違い: D:/repos/project/file.tsx
• ✅ 正解: D:\repos\project\file.tsx

以下に適用されます:

• 編集ツールの file_path パラメータ
• 書き込みツールの file_path パラメータ
• Windowsシステムのすべてのファイル操作

ドキュメンテーションガイドライン

ユーザーが明示的に要求しない限り、新しいドキュメンテーションファイルを作成しないでください。

• 優先度: 新しいドキュメントを作成するのではなく、既存のREADME.mdファイルを更新
• リポジトリの清潔さ: リポジトリルートをきれいに保つ - ユーザーが別途要求しない限りREADME.mdのみ
• スタイル: ドキュメントは簡潔、直接的、専門的で、AI生成的なトーンを避ける
• ユーザー希望: ユーザーがドキュメント追加を明確に要求した場合のみ追加の.mdファイルを作成

---

基本から高度な操作まで、危険な操作を含むあらゆるGit操作のための包括的ガイド。

---

TL;DR クイックリファレンス

安全第一 - 破壊的操作の前に:

# 常にステータスを確認
git status
git log --oneline -10

# リスキーな操作については安全ブランチを作成
git branch backup-$(date +%Y%m%d-%H%M%S)

# 覚えておくこと: git reflogはあなたのセーフティネット(デフォルト90日)
git reflog

ユーザー希望の確認:

• 必ず確認: 「コミットを自動的に作成したいですか、それとも手動でコミットを処理したいですか?」
• ユーザーの選択をセッション全体で尊重

---

概要

このスキルは、どれほど高度で、ニッチで、リスキーであっても、あらゆるGit操作に対する完全なGit専門知識を提供します。対象範囲:

このスキルを使用する必要があります:

• ✅ あらゆるGitコマンドまたは操作
• ✅ リポジトリの初期化、クローン、設定
• ✅ ブランチ管理と戦略
• ✅ コミットワークフローとベストプラクティス
• ✅ マージ戦略とコンフリクト解決
• ✅ リベース操作(対話型および非対話型)
• ✅ 履歴の書き換え(filter-repo、reset、revert)
• ✅ リカバリ操作(reflog、fsck)
• ✅ 危険な操作(フォースプッシュ、ハードリセット)
• ✅ プラットフォーム固有のワークフロー(GitHub、Azure DevOps、Bitbucket)
• ✅ 高度な機能(サブモジュール、ワークツリー、フック)
• ✅ パフォーマンス最適化
• ✅ クロスプラットフォーム互換性(Windows/Linux/macOS)

---

コア原則

1. 破壊的操作のための安全ガード

重要: 破壊的操作(reset --hard、フォースプッシュ、filter-repoなど)の前に:

1. ユーザーに明示的に警告
2. リスクを明確に説明
3. 確認を要求
4. 事前に安全ブランチを作成することを提案
5. リカバリ手順を提供

# 危険な操作のための例の安全パターン
echo "⚠️  警告: この操作は破壊的で次のようになります:"
echo "   - コミットされていない変更を永続的に削除"
echo "   - Gitの履歴を書き換え"
echo "   - [操作の具体的なリスク]"
echo ""
echo "安全な推奨: まず安全ブランチを作成..."
git branch backup-before-reset-$(date +%Y%m%d-%H%M%S)
echo ""
echo "必要な場合の復旧: git reset --hard backup-before-reset-XXXXXXXX"
echo ""
read -p "本当に続行しますか? (yes/NO): " confirm
if [[ "$confirm" != "yes" ]]; then
    echo "操作がキャンセルされました。"
    exit 1
fi

2. コミット作成ポリシー

Gitタスクの開始時に必ず確認: 「次のどれを希望されますか:

1. 適切なメッセージで自動的にコミットを作成
2. 変更のステージングのみ(手動でコミットを処理)
3. ガイダンスのみ(自動操作なし)」

このセッション全体でこの選択を尊重してください。

3. プラットフォーム認識

Gitの動作とワークフローはプラットフォームとホスティングプロバイダによって異なります:

Windows (Git Bash/PowerShell):

• 行末処理(core.autocrlf)
• パスセパレーターとケース感度
• 資格情報管理(Windows Credential Manager)

Linux/macOS:

• ケース感度ファイルシステム
• SSHキー管理
• パーミッション処理

ホスティングプラットフォーム:

• GitHub: プルリクエスト、GitHub Actions、GitHub CLI
• Azure DevOps: プルリクエスト、Azure Pipelines、ポリシー
• Bitbucket: プルリクエスト、Bitbucket Pipelines、Jira統合
• GitLab: マージリクエスト、GitLab CI/CD

---

基本的なGit操作

リポジトリの初期化とクローン

# 新しいリポジトリを初期化
git init
git init --initial-branch=main  # デフォルトブランチ名を指定

# リポジトリをクローン
git clone <url>
git clone <url> <directory>
git clone --depth 1 <url>  # シャロークローン(高速、履歴が少ない)
git clone --branch <branch> <url>  # 特定のブランチをクローン
git clone --recurse-submodules <url>  # サブモジュールを含める

設定

# ユーザー識別(コミットに必須)
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

# デフォルトブランチ名
git config --global init.defaultBranch main

# 行末処理(Windows)
git config --global core.autocrlf true  # Windows
git config --global core.autocrlf input  # macOS/Linux

# エディタ
git config --global core.editor "code --wait"  # VS Code
git config --global core.editor "vim"

# Diffツール
git config --global diff.tool vscode
git config --global difftool.vscode.cmd 'code --wait --diff $LOCAL $REMOTE'

# マージツール
git config --global merge.tool vscode
git config --global mergetool.vscode.cmd 'code --wait $MERGED'

# エイリアス
git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.unstage 'reset HEAD --'
git config --global alias.last 'log -1 HEAD'
git config --global alias.visual '!gitk'

# 設定を表示
git config --list
git config --global --list
git config --local --list
git config user.name  # 特定の値を取得

基本的なワークフロー

# ステータスを確認
git status
git status -s  # 短いフォーマット
git status -sb  # ブランチ情報付きの短いフォーマット

# ファイルを追加
git add <file>
git add .  # 現在のディレクトリのすべての変更を追加
git add -A  # リポジトリのすべての変更を追加
git add -p  # 対話型ステージング(パッチモード)

# ファイルを削除
git rm <file>
git rm --cached <file>  # インデックスから削除、作業ディレクトリに保持
git rm -r <directory>

# ファイルを移動/名前変更
git mv <old> <new>

# コミット
git commit -m "message"
git commit -am "message"  # 追跡ファイルを追加してコミット
git commit --amend  # 最後のコミットを修正
git commit --amend --no-edit  # メッセージを変更せずに修正
git commit --allow-empty -m "message"  # 空のコミット(トリガーに便利)

# 履歴を表示
git log
git log --oneline
git log --graph --oneline --all --decorate
git log --stat  # ファイル統計を表示
git log --patch  # diffを表示
git log -p -2  # 最後の2コミットをdiff付きで表示
git log --since="2 weeks ago"
git log --until="2025-01-01"
git log --author="Name"
git log --grep="pattern"
git log -- <file>  # 特定ファイルの履歴
git log --follow <file>  # 名前変更を追跡

# 変更を表示
git diff  # ステージングされていない変更
git diff --staged  # ステージングされた変更
git diff HEAD  # 最後のコミット以降のすべての変更
git diff <branch>  # 別のブランチと比較
git diff <commit1> <commit2>
git diff <commit>  # 特定のコミット以降の変更
git diff <branch1>...<branch2>  # ブランチ間の変更

# コミット詳細を表示
git show <commit>
git show <commit>:<file>  # 特定のコミットのファイルを表示

---

ブランチ管理

ブランチの作成と切り替え

# ブランチを一覧表示
git branch  # ローカルブランチ
git branch -r  # リモートブランチ
git branch -a  # すべてのブランチ
git branch -v  # 最後のコミット情報付き
git branch -vv  # トラッキング情報付き

# ブランチを作成
git branch <branch-name>
git branch <branch-name> <start-point>  # 特定のコミット/タグから

# ブランチを切り替え
git switch <branch-name>
git checkout <branch-name>  # 古いシンタックス、まだ動作

# 作成して切り替え
git switch -c <branch-name>
git checkout -b <branch-name>
git switch -c <branch-name> <start-point>

# ブランチを削除
git branch -d <branch-name>  # 安全な削除(マージされた場合のみ)
git branch -D <branch-name>  # 強制削除(マージされていなくても)

# ブランチを名前変更
git branch -m <old-name> <new-name>
git branch -m <new-name>  # 現在のブランチを名前変更

# アップストリームトラッキングを設定
git branch --set-upstream-to=origin/<branch>
git branch -u origin/<branch>

ブランチ戦略

Git Flow:

• main/master: 本番環境対応コード
• develop: フィーチャー統合ブランチ
• feature/*: 新機能
• release/*: リリース準備
• hotfix/*: 本番環境修正

GitHub Flow:

• main: 常にデプロイ可能
• feature/*: 短期間の機能ブランチ
• PR作成、レビュー、マージ

Trunk-Based Development:

• main: 単一ブランチ
• 短期間の機能ブランチ(< 1日)
• 不完全な機能にはフィーチャーフラグを使用

GitLab Flow:

• 環境ブランチ: production、staging、main
• フィーチャーブランチはmainにマージ
• 環境ブランチからデプロイ

---

マージとリベース

マージ戦略

# フォワードフォワードマージ(可能な場合、デフォルト)
git merge <branch>

# マージコミットを強制(フォワードフォワード可能でも)
git merge --no-ff <branch>

# スカッシュマージ(すべてのコミットを1つに)
git merge --squash <branch>
# その後手動でコミット: git commit -m "Merged feature X"

# 特定の戦略でマージ
git merge -s recursive <branch>  # デフォルト戦略
git merge -s ours <branch>  # 常に「我々」のバージョンを使用
git merge -s theirs <branch>  # 常に「彼ら」のバージョンを使用(merge-theirsが必須)
git merge -s octopus <branch1> <branch2> <branch3>  # 複数ブランチをマージ

# 戦略オプション付きでマージ
git merge -X ours <branch>  # コンフリクトで「我々」を優先
git merge -X theirs <branch>  # コンフリクトで「彼ら」を優先
git merge -X ignore-all-space <branch>
git merge -X ignore-space-change <branch>

# マージを中止
git merge --abort

# コンフリクト解決後に続行
git merge --continue

コンフリクト解決

# マージコンフリクトが発生した場合
git status  # コンフリクトファイルを確認

# ファイル内のコンフリクトマーカー:
# <<<<<<< HEAD
# あなたの変更
# =======
# 彼らの変更
# >>>>>>> branch-name

# コンフリクトを手動で解決、その後:
git add <resolved-file>
git commit  # マージを完了

# mergetoolを使用
git mergetool

# 一方を完全に受け入れ
git checkout --ours <file>  # 我々のバージョンを保持
git checkout --theirs <file>  # 彼らのバージョンを保持
git add <file>

# コンフリクトdiffを表示
git diff  # コンフリクトを表示
git diff --ours  # 我々のバージョンと比較
git diff --theirs  # 彼らのバージョンと比較
git diff --base  # ベースバージョンと比較

# コンフリクトを一覧表示
git diff --name-only --diff-filter=U

リベース操作

⚠️ 警告: リベースは履歴を書き換えます。共有ブランチにプッシュされたコミットをリベースしないでください!

# 基本的なリベース
git rebase <base-branch>
git rebase origin/main

# 対話型リベース(強力)
git rebase -i <base-commit>
git rebase -i HEAD~5  # 最後の5コミット

# 対話型リベースコマンド:
# p, pick = コミットを使用
# r, reword = コミットを使用、ただしメッセージを編集
# e, edit = コミットを使用、ただし修正のために停止
# s, squash = コミットを使用、ただし前のコミットにマージ
# f, fixup = squashのような、ただしコミットメッセージを破棄
# x, exec = シェルを使用してコマンドを実行(残りの行)
# b, break = ここで停止('git rebase --continue'でリベース継続)
# d, drop = コミットを削除
# l, label = 現在のHEADに名前でラベル付け
# t, reset = HEADをラベルにリセット

# 異なるベースにリベース
git rebase --onto <new-base> <old-base> <branch>

# コンフリクト解決後に続行
git rebase --continue

# 現在のコミットをスキップ
git rebase --skip

# リベースを中止
git rebase --abort

# マージコミットを保持
git rebase --preserve-merges <base>  # 非推奨
git rebase --rebase-merges <base>  # モダンアプローチ

# 自動スカッシュ(fixupコミット付き)
git commit --fixup <commit>
git rebase -i --autosquash <base>

Cherry-Pick

# 特定のコミットを現在のブランチに適用
git cherry-pick <commit>

# 複数のコミットをcherry-pick
git cherry-pick <commit1> <commit2>
git cherry-pick <commit1>..<commit5>

# コミットなしでcherry-pick
git cherry-pick -n <commit>
git cherry-pick --no-commit <commit>

# コンフリクト解決後に続行
git cherry-pick --continue

# cherry-pickを中止
git cherry-pick --abort

---

リモート操作

リモート管理

# リモートを一覧表示
git remote
git remote -v  # URLを含む

# リモートを追加
git remote add <name> <url>
git remote add origin https://github.com/user/repo.git

# リモートURLを変更
git remote set-url <name> <new-url>

# リモートを削除
git remote remove <name>
git remote rm <name>

# リモートを名前変更
git remote rename <old> <new>

# リモート情報を表示
git remote show <name>
git remote show origin

# 古いリモートブランチを削除
git remote prune origin
git fetch --prune

フェッチとプル

# リモートからフェッチ(マージしない)
git fetch
git fetch origin
git fetch --all  # すべてのリモート
git fetch --prune  # 古いリモートトラッキングブランチを削除

# プル(フェッチ + マージ)
git pull
git pull origin <branch>
git pull --rebase  # フェッチ + マージの代わりにリベース
git pull --no-ff  # 常にマージコミットを作成
git pull --ff-only  # フォワードフォワード可能な場合のみ

# デフォルトプル動作を設定
git config --global pull.rebase true  # 常にリベース
git config --global pull.ff only  # フォワードフォワードのみ

プッシュ

# リモートにプッシュ
git push
git push origin <branch>
git push origin <local-branch>:<remote-branch>

# 新しいブランチをプッシュしてアップストリームを設定
git push -u origin <branch>
git push --set-upstream origin <branch>

# すべてのブランチをプッシュ
git push --all

# タグをプッシュ
git push --tags
git push origin <tag-name>

# リモートブランチを削除
git push origin --delete <branch>
git push origin :<branch>  # 古いシンタックス

# リモートタグを削除
git push origin --delete <tag>
git push origin :refs/tags/<tag>

# ⚠️ 危険: フォースプッシュ(リモート履歴を上書き)
# 常にユーザーに確認してください
git push --force
git push -f

# ⚠️ より安全: リースでフォースプッシュ(リモートが更新された場合は失敗)
git push --force-with-lease
git push --force-with-lease=<ref>:<expected-value>

フォースプッシュの安全プロトコル:

フォースプッシュの前に、この安全チェックを実行:

echo "⚠️  危険: フォースプッシュはリモート履歴を上書きします!"
echo ""
echo "リモートブランチの状態:"
git fetch origin
git log --oneline origin/<branch> ^<branch> --decorate

if [ -z "$(git log --oneline origin/<branch> ^<branch>)" ]; then
    echo "✓ コミットは失われません(リモートはローカルより遅れている)"
else
    echo "❌ 警告: リモートに失われるコミットがあります:"
    git log --oneline --decorate origin/<branch> ^<branch>
    echo ""
    echo "他の開発者のこれらのコミットが削除されます!"
fi

echo ""
echo "--force の代わりに --force-with-lease を使用することを検討してください"
echo ""
read -p "'force push' と入力して確認: " confirm
if [[ "$confirm" != "force push" ]]; then
    echo "キャンセルされました。"
    exit 1
fi

---

高度なコマンド

スタッシュ

# 変更をスタッシュ
git stash
git stash save "message"
git stash push -m "message"

# トラッキングされていないファイルを含める
git stash -u
git stash --include-untracked

# 無視されたファイルを含める
git stash -a
git stash --all

# スタッシュを一覧表示
git stash list

# スタッシュの内容を表示
git stash show
git stash show -p  # diffを含む
git stash show stash@{2}

# スタッシュを適用(スタッシュリストに保持)
git stash apply
git stash apply stash@{2}

# スタッシュをポップ(適用して削除)
git stash pop
git stash pop stash@{2}

# スタッシュを削除
git stash drop
git stash drop stash@{2}

# すべてのスタッシュをクリア
git stash clear

# スタッシュからブランチを作成
git stash branch <branch-name>
git stash branch <branch-name> stash@{1}

# Git 2.51+: スタッシュのインポート/エクスポート(マシン間でスタッシュを共有)
# スタッシュをファイルにエクスポート
git stash store --file=stash.patch stash@{0}

# ファイルからスタッシュをインポート
git stash import --file=stash.patch

# ブランチ/タグのようにスタッシュを共有
git stash export > my-stash.patch
git stash import < my-stash.patch

リセット

⚠️ 警告: リセットは変更を永続的に削除できます!

# ソフトリセット(変更をステージングしたまま)
git reset --soft <commit>
git reset --soft HEAD~1  # 最後のコミットを取り消し、変更をステージングしたまま

# ミックスドリセット(デフォルト - 変更をステージング前に)
git reset <commit>
git reset HEAD~1  # 最後のコミットを取り消し、変更をステージング前に

# ⚠️ ハードリセット(すべての変更を削除 - 危険!)
# 常に最初に安全ブランチを作成してください!
git branch backup-$(date +%Y%m%d-%H%M%S)
git reset --hard <commit>
git reset --hard HEAD~1  # 最後のコミットを取り消しすべての変更を削除
git reset --hard origin/<branch>  # リモート状態にリセット

# ファイルをステージング前に戻す
git reset HEAD <file>
git reset -- <file>

# 特定ファイルをコミットにリセット
git checkout <commit> -- <file>

リバート

# コミットをリバート(変更を取り消す新しいコミットを作成)
# 共有ブランチでリセットするより安全
git revert <commit>

# コミットなしでリバート
git revert -n <commit>
git revert --no-commit <commit>

# マージコミットをリバート
git revert -m 1 <merge-commit>  # 最初の親を保持
git revert -m 2 <merge-commit>  # 2番目の親を保持

# 複数のコミットをリバート
git revert <commit1> <commit2>
git revert <commit1>..<commit5>

# コンフリクト解決後に続行
git revert --continue

# リバートを中止
git revert --abort

Reflog(リカバリ)

reflogはセーフティネット - すべてのHEAD移動を90日間(デフォルト)追跡

# reflogを表示
git reflog
git reflog show
git reflog show <branch>

# より詳細なreflog
git log -g  # reflogをログとして
git log -g --all

# 失われたコミットを検索
git reflog --all
git fsck --lost-found

# 削除されたブランチを復旧
git reflog  # ブランチが存在したコミットを検索
git branch <branch-name> <commit-hash>

# ハードリセット後に復旧
git reflog  # リセット前のコミットを検索
git reset --hard <commit-hash>

# 削除されたコミットを復旧
git cherry-pick <commit-hash>

# Reflog有効期限(保持期間を変更)
git config gc.reflogExpire "90 days"
git config gc.reflogExpireUnreachable "30 days"

Bisect(不良コミットを検索)

# bisectを開始
git bisect start

# 現在のコミットを不良と指定
git bisect bad

# 既知の良いコミットを指定
git bisect good <commit>

# 各コミットをテスト、その後良いか悪いと指定
git bisect good  # 現在のコミットは良い
git bisect bad   # 現在のコミットは悪い

# テストスクリプトで自動化
git bisect run <test-script>

# Bisectが最初の不良コミットを表示

# bisectを終了
git bisect reset

# テストできないコミットをスキップ
git bisect skip

クリーン

⚠️ 警告: クリーンはトラッキングされていないファイルを永続的に削除します!

# 削除されるファイルを表示(ドライラン - 常にこれを最初に行う!)
git clean -n
git clean --dry-run

# トラッキングされていないファイルを削除
git clean -f

# トラッキングされていないファイルとディレクトリを削除
git clean -fd

# トラッキングされていないファイルと無視されたファイルを削除
git clean -fdx

# 対話型クリーン
git clean -i

ワークツリー

# ワークツリーを一覧表示
git worktree list

# 新しいワークツリーを追加
git worktree add <path> <branch>
git worktree add ../project-feature feature-branch

# 新しいブランチ用ワークツリーを追加
git worktree add -b <new-branch> <path>

# ワークツリーを削除
git worktree remove <path>

# 古いワークツリーを削除
git worktree prune

サブモジュール

# サブモジュールを追加
git submodule add <url> <path>

# サブモジュールを初期化(クローン後)
git submodule init
git submodule update

# サブモジュール付きでクローン
git clone --recurse-submodules <url>

# サブモジュールを更新
git submodule update --remote
git submodule update --init --recursive

# すべてのサブモジュールでコマンドを実行
git submodule foreach <command>
git submodule foreach git pull origin main

# サブモジュールを削除
git submodule deinit <path>
git rm <path>
rm -rf .git/modules/<path>

---

危険な操作(高リスク)

Filter-Repo(履歴の書き換え)

⚠️ 非常に危険: リポジトリ全体の履歴を書き換え!

# git-filter-repoをインストール(組み込みではない)
# pip install git-filter-repo

# すべての履歴からファイルを削除
git filter-repo --path <file> --invert-paths

# すべての履歴からディレクトリを削除
git filter-repo --path <directory> --invert-paths

# 作者情報を変更
git filter-repo --name-callback 'return name.replace(b"Old Name", b"New Name")'
git filter-repo --email-callback 'return email.replace(b"old@email.com", b"new@email.com")'

# 大きいファイルを削除
git filter-repo --strip-blobs-bigger-than 10M

# ⚠️ filter-repo後、フォースプッシュが必須
git push --force --all
git push --force --tags

filter-repoの安全プロトコル:

echo "⚠️⚠️⚠️  極端な危険  ⚠️⚠️⚠️"
echo "この操作は:"
echo "  - リポジトリ全体の履歴を書き換え"
echo "  - すべてのコミットハッシュを変更"
echo "  - すべての既存クローンを破壊"
echo "  - すべてのチームメンバーに再クローンを強要"
echo "  - フォースプッシュ後は取り消せない"
echo ""
echo "必須: 完全バックアップを作成:"
git clone --mirror <repo-url> backup-$(date +%Y%m%d-%H%M%S)
echo ""
echo "進行前にすべてのチームメンバーに通知してください!"
echo ""
read -p "「リスクを理解しました」と入力して続行: " confirm
if [[ "$confirm" != "I UNDERSTAND THE RISKS" ]]; then
    echo "キャンセルされました。"
    exit 1
fi

プッシュされたコミットを修正

⚠️ 危険: プッシュされたコミットを変更するにはフォースプッシュが必須!

# 最後のコミットを修正
git commit --amend

# メッセージを変更せずに修正
git commit --amend --no-edit

# 最後のコミットの作者を変更
git commit --amend --author="Name <email>"

# ⚠️ すでにプッシュされている場合フォースプッシュが必須
git push --force-with-lease

複数のコミットを書き換え

⚠️ 危険: プッシュされたコミットの対話型リベース!

# 対話型リベース
git rebase -i HEAD~5

# 古いコミットの作者を変更
git rebase -i <commit>^
# コミットを「edit」と指定
# 停止したら:
git commit --amend --author="Name <email>" --no-edit
git rebase --continue

# ⚠️ フォースプッシュが必須
git push --force-with-lease

---

プラットフォーム固有のワークフロー

GitHub

プルリクエスト:

# GitHub CLIをインストール
# https://cli.github.com/

# PRを作成
gh pr create
gh pr create --title "Title" --body "Description"
gh pr create --base main --head feature-branch

# PRを一覧表示
gh pr list

# PRを表示
gh pr view
gh pr view <number>

# PRをローカルでチェックアウト
gh pr checkout <number>

# PRをレビュー
gh pr review
gh pr review --approve
gh pr review --request-changes
gh pr review --comment

# PRをマージ
gh pr merge
gh pr merge --squash
gh pr merge --rebase
gh pr merge --merge

# PRをクローズ
gh pr close <number>

GitHub Actions:

# .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: npm test

Azure DevOps

プルリクエスト:

# Azure DevOps CLIをインストール
# https://docs.microsoft.com/en-us/cli/azure/install-azure-cli

# PRを作成
az repos pr create --title "Title" --description "Description"
az repos pr create --source-branch feature --target-branch main

# PRを一覧表示
az repos pr list

# PRを表示
az repos pr show --id <id>

# PRを完了
az repos pr update --id <id> --status completed

# ブランチポリシー
az repos policy list
az repos policy create --config policy.json

Azure Pipelines:

# azure-pipelines.yml
trigger:
  - main
pool:
  vmImage: 'ubuntu-latest'
steps:
  - script: npm test
    displayName: 'Run tests'

Bitbucket

プルリクエスト:

# PRを作成(WebまたはBitbucket CLIで)
bb pr create

# PRをレビュー
bb pr list
bb pr view <id>

# PRをマージ
bb pr merge <id>

Bitbucket Pipelines:

# bitbucket-pipelines.yml
pipelines:
  default:
    - step:
        script:
          - npm test

GitLab

マージリクエスト:

# GitLab CLI(glab)をインストール
# https://gitlab.com/gitlab-org/cli

# MRを作成
glab mr create
glab mr create --title "Title" --description "Description"

# MRを一覧表示
glab mr list

# MRを表示
glab mr view <id>

# MRをマージ
glab mr merge <id>

# MRをクローズ
glab mr close <id>

GitLab CI:

# .gitlab-ci.yml
stages:
  - test
test:
  stage: test
  script:
    - npm test

---

パフォーマンス最適化

リポジトリメンテナンス

# ガベージコレクション
git gc
git gc --aggressive  # より徹底的、遅い

# 到達不可能なオブジェクトを削除
git prune

# リポジトリを検証
git fsck
git fsck --full

# リポジトリを最適化
git repack -a -d --depth=250 --window=250

# Git 2.51+: パスウォークのリパック(より小さいパックを生成)
# パスウォークによるより効率的なデルタ圧縮
git repack --path-walk -a -d

# オブジェクト数をカウント
git count-objects -v

# リポジトリサイズ
du -sh .git

大きいファイル

# 履歴内の大きいファイルを検索
git rev-list --objects --all |
  git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' |
  sed -n 's/^blob //p' |
  sort --numeric-sort --key=2 |
  tail -n 10

# Git LFS(Large File Storage)
git lfs install
git lfs track "*.psd"
git lfs track "*.zip"
git add .gitattributes
git add file.psd
git commit -m "Add large file"

# LFSファイルを一覧表示
git lfs ls-files

# LFSファイルをフェッチ
git lfs fetch
git lfs pull

シャロークローン

# シャロークローン(高速、ディスク容量が少ない)
git clone --depth 1 <url>

# シャロー解除(フルクローンに変換)
git fetch --unshallow

# より多くの履歴をフェッチ
git fetch --depth=100

---

タグとリリース

タグを作成

# ライトウェイトタグ
git tag <tag-name>
git tag v1.0.0

# 注釈付きタグ(推奨 - メタデータを含む)
git tag -a <tag-name> -m "message"
git tag -a v1.0.0 -m "Release version 1.0.0"

# 特定のコミットにタグ付け
git tag -a <tag-name> <commit>

# 署名付きタグ(GPG署名)
git tag -s <tag-name> -m "message"

タグを管理

# タグを一覧表示
git tag
git tag -l "v1.*"  # パターンマッチング

# タグ情報を表示
git show <tag-name>

# ローカルタグを削除
git tag -d <tag-name>

# リモートタグを削除
git push origin --delete <tag-name>
git push origin :refs/tags/<tag-name>

# タグをプッシュ
git push origin <tag-name>
git push --tags  # すべてのタグ
git push --follow-tags  # 注釈付きタグのみ

---

Gitフック

クライアント側フック

# フック場所: .git/hooks/

# pre-commit: コミット前に実行
# 例: .git/hooks/pre-commit
#!/bin/bash
npm run lint || exit 1

# prepare-commit-msg: エディタを開く前にコミットメッセージを編集
# commit-msg: コミットメッセージを検証
#!/bin/bash
msg=$(cat "$1")
if ! echo "$msg" | grep -qE "^(feat|fix|docs|style|refactor|test|chore):"; then
    echo "エラー: コミットメッセージはタイプで始まる必要があります(feat|fix|docs|...):"
    exit 1
fi

# post-commit: コミット後に実行
# pre-push: プッシュ前に実行
# post-checkout: チェックアウト後に実行
# post-merge: マージ後に実行

# フックを実行可能にする
chmod +x .git/hooks/pre-commit

サーバー側フック

# pre-receive: refが更新される前に実行
# update: 更新される各ブランチに対して実行
# post-receive: refが更新された後に実行

# 例: フォースプッシュを拒否
#!/bin/bash
while read oldrev newrev refname; do
    if [ "$oldrev" != "0000000000000000000000000000000000000000" ]; then
        if ! git merge-base --is-ancestor "$oldrev" "$newrev"; then
            echo "エラー: フォースプッシュが拒否されました"
            exit 1
        fi
    fi
done

---

トラブルシューティングとリカバリ

一般的な問題

デタッチされたHEAD:

# デタッチされたHEAD状態にいます
git branch temp  # 現在のコミットにブランチを作成
git switch main
git merge temp
git branch -d temp

マージコンフリクト:

# マージ/リベース中
git status  # コンフリクトファイルを確認
# ファイルを編集してコンフリクトを解決
git add <resolved-files>
git merge --continue  # または git rebase --continue

# 中止して最初からやり直す
git merge --abort
git rebase --abort

誤ってブランチを削除:

# reflogでブランチを検索
git reflog
# コミットでブランチを作成
git branch <branch-name> <commit-hash>

コミットを間違ったブランチに:

# コミットを正しいブランチに移動
git switch correct-branch
git cherry-pick <commit>
git switch wrong-branch
git reset --hard HEAD~1  # 間違ったブランチから削除

機密データをプッシュ:

# ⚠️ 緊急: 直ちに履歴から削除
git filter-repo --path <sensitive-file> --invert-paths
git push --force --all
# その後: 侵害された認証情報を直ちにローテーション!

誤って大きなコミット:

# プッシュ前
git reset --soft HEAD~1
git reset HEAD <large-file>
git commit -m "message"

# プッシュ後 - filter-repoまたはBFGを使用

リカバリシナリオ

ハードリセット後に復旧:

git reflog
git reset --hard <reset前のコミット>

削除されたファイルを復旧:

git log --all --full-history -- <file>
git checkout <commit>^ -- <file>

削除されたコミットを復旧:

git reflog  # コミットハッシュを検索
git cherry-pick <commit>
# または
git merge <commit>
# または
git reset --hard <commit>

リポジトリの破損から復旧:

# 破損を検証
git fsck --full

# リペアを試行
git gc --aggressive

# 最後の手段: リモートからクローン

---

ベストプラクティス

コミットメッセージ

Conventional Commits形式:

<type>(<scope>): <subject>

<body>

<footer>

タイプ:

• feat: 新機能
• fix: バグ修正
• docs: ドキュメント
• style: フォーマット(コード変更なし)
• refactor: コード再構成
• test: テスト追加
• chore: メンテナンス

例:

feat(auth): OAuth2認証を追加

GoogleおよびGitHubプロバイダ用にOAuth2フローを実装。
トークン更新と取り消しを含む。

Closes #123

ブランチングのベストプラクティス

1. ブランチは短期間に(< 2日が理想的)
2. 説明的な名前を使用: feature/user-auth、fix/header-crash
3. 各ブランチは1つの目的
4. マージ前にリベースして履歴をきれいに
5. マージされたブランチを削除

ワークフローのベストプラクティス

1. 頻繁にコミット(小さく、論理的なチャンク)
2. プッシュ前にプル(最新に保つ)
3. コミット前にレビュー(git diff --staged)
4. 意味のあるメッセージを書く
5. コミット前にテスト
6. 秘密情報をコミットしない(.gitignore、環境変数を使用)

.gitignoreのベストプラクティス

# 環境ファイル
.env
.env.local
*.env

# 依存性
node_modules/
vendor/
venv/

# ビルド出力
dist/
build/
*.exe
*.dll
*.so

# IDE
.vscode/
.idea/
*.swp
*.swo

# OSファイル
.DS_Store
Thumbs.db

# ログ
*.log
logs/

# 一時ファイル
tmp/
temp/
*.tmp

---

セキュリティベストプラクティス

認証情報管理

# 認証情報を保存(1時間キャッシュ)
git config --global credential.helper cache
git config --global credential.helper 'cache --timeout=3600'

# 認証情報を永続的に保存 - 慎重に使用
git config --global credential.helper store

# Windows: Credential Managerを使用
git config --global credential.helper wincred

# macOS: キーチェーンを使用
git config --global credential.helper osxkeychain

# Linux: libsecretを使用
git config --global credential.helper /usr/share/doc/git/contrib/credential/libsecret/git-credential-libsecret

SSHキー

# SSHキーを生成
ssh-keygen -t ed25519 -C "your_email@example.com"
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"  # ed25519が非対応の場合

# ssh-agentを開始
eval "$(ssh-agent -s)"

# キーをssh-agentに追加
ssh-add ~/.ssh/id_ed25519

# 接続をテスト
ssh -T git@github.com
ssh -T git@ssh.dev.azure.com

GPG署名

# GPGキーを生成
gpg --full-generate-key

# キーを一覧表示
gpg --list-secret-keys --keyid-format LONG

# Gitを署名するように設定
git config --global user.signingkey <key-id>
git config --global commit.gpgsign true

# コミットに署名
git commit -S -m "message"

# 署名を検証
git log --show-signature

秘密情報を防止

# Git-secrets(AWSツール)
git secrets --install
git secrets --register-aws

# Gitleaks
gitleaks detect

# Pre-commitフック
#!/bin/bash
if git diff --cached | grep -E "(password|secret|api_key)" ; then
    echo "潜在的な秘密が検出されました!"
    exit 1
fi

---

クロスプラットフォーム考慮事項

行末

# Windows(作業ディレクトリではCRLF、リポジトリではLF)
git config --global core.autocrlf true

# macOS/Linux(どこでもLF)
git config --global core.autocrlf input

# 変換なし(推奨されない)
git config --global core.autocrlf false

# 一貫性のため.gitattributesを使用
# .gitattributes:
* text=auto
*.sh text eol=lf
*.bat text eol=crlf

ケース感度

# macOS/Windows: ケース非感応ファイルシステム
# Linux: ケース感応ファイルシステム

# Gitでケース感度を有効化
git config --global core.ignorecase false

# ファイルを名前変更(ケースのみ変更)
git mv --force myfile.txt MyFile.txt

パス処理

# Gitは内部的に常にフォワードスラッシュを使用
# すべてのプラットフォームで動作:
git add src/components/Header.jsx

# Windows固有のツールによってはいくつかのコンテキストで
# バックスラッシュが必要な場合があります

Git Bash / MINGW パス変換(Windows)

重要: Git BashはWindowsの主要なGit環境です!

Git Bash (MINGW/MSYS2)は自動的にUnixスタイルのパスをネイティブ実行可能ファイルのWindowsパスに変換し、Git操作に問題が生じる可能性があります。

パス変換の動作:

# 発生する自動変換:
/foo          → C:/Program Files/Git/usr/foo
/foo:/bar     → C:\msys64\foo;C:\msys64\bar
--dir=/foo    → --dir=C:/msys64/foo

# 変換をトリガーするもの:
# ✓ 引数の先頭のフォワードスラッシュ(/)
# ✓ コロン区切りのパスリスト
# ✓ - または , の後のパスコンポーネント付き引数

# 変換から除外されるもの:
# ✓ = を含む引数(変数代入)
# ✓ ドライブ指定子(C:)
# ✓ ; を含む引数(既にWindows形式)
# ✓ // で始まる引数(Windowススイッチ)

パス変換を制御:

# 方法1: MSYS_NO_PATHCONV (Git for Windowsのみ)
# コマンドの全パス変換を無効化
MSYS_NO_PATHCONV=1 git command --option=/path

# 永続的に無効化(注意して使用 - スクリプトを破壊する可能性)
export MSYS_NO_PATHCONV=1

# 方法2: MSYS2_ARG_CONV_EXCL (MSYS2)
# 特定の引数パターンを除外
export MSYS2_ARG_CONV_EXCL="*"              # すべてを除外
export MSYS2_ARG_CONV_EXCL="--dir=;/test"  # 特定のプレフィックス

# 方法3: cgypathで手動変換
cygpath -u "C:\path"     # → Unix形式: /c/path
cygpath -w "/c/path"     # → Windows形式: C:\path
cygpath -m "/c/path"     # → ミックス形式: C:/path

# 方法4: 回避策
# ダブルスラッシュを使用: //e //s の代わりに /e /s
# ダッシュ記法を使用: -e -s の代わりに /e /s
# スペースのあるパスをクォート: "/c/Program Files/file.txt"

Gitワークフローでのシェル検出:

# 方法1: $MSYSTEM (Git Bashで最も信頼できる)
case "$MSYSTEM" in
  MINGW64)  echo "Git Bash 64ビット" ;;
  MINGW32)  echo "Git Bash 32ビット" ;;
  MSYS)     echo "MSYS環境" ;;
esac

# 方法2: uname -s (ポータブル)
case "$(uname -s)" in
  MINGW64_NT*)  echo "Git Bash 64ビット" ;;
  MINGW32_NT*)  echo "Git Bash 32ビット" ;;
  MSYS_NT*)     echo "MSYS" ;;
  CYGWIN*)      echo "Cygwin" ;;
  Darwin*)      echo "macOS" ;;
  Linux*)       echo "Linux" ;;
esac

# 方法3: $OSTYPE (Bashのみ、高速)
case "$OSTYPE" in
  msys*)       echo "Git Bash/MSYS" ;;
  cygwin*)     echo "Cygwin" ;;
  darwin*)     echo "macOS" ;;
  linux-gnu*)  echo "Linux" ;;
esac

Git Bashのパス問題と解決策:

# 問題: Git BashでパスのGitコマンドが失敗
# 例: git log --follow /path/to/file が失敗

# 解決策1: 相対パスを使用
git log --follow ./path/to/file

# 解決策2: パス変換を無効化
MSYS_NO_PATHCONV=1 git log --follow /path/to/file

# 解決策3: Windowsスタイルのパスを使用
git log --follow C:/path/to/file

# 問題: パスにスペース(Program Files)
# 解決策: 常にパスをクォート
git add "/c/Program Files/project/file.txt"

# 問題: ドライブレター重複(D:\dev → D:\d\dev)
# 解決策: 変換にcygpathを使用
file=$(cygpath -u "D:\dev\file.txt")
git add "$file"

Git Bashベストプラクティス:

1. Gitコマンドでは常にフォワードスラッシュを使用 - Gitはすべてのプラットフォームで処理
2. スペースのあるパスを常にクォート - Git Bashで必須
3. 可能な限り相対パスを使用 - 変換の問題を避ける
4. シェル環境を検出 - Git Bash検出に$MSYSTEMを使用
5. Git Bashでスクリプトをテスト - 主要なWindows Git環境
6. MSYS_NO_PATHCONVを選別的に使用 - グローバルではなく必要な場合のみ

---

成功基準

このスキルを使用したGitワークフローは次のようにすべき:

1. ✓ ユーザーに自動コミット vs 手動の希望を必ず確認
2. ✓ 破壊的操作の前に必ず警告
3. ✓ リスキーな操作の前に必ず安全ブランチを作成
4. ✓ リカバリ手順を常に説明
5. ✓ プロジェクト向けに適切なブランチ戦略を使用
6. ✓ 意味のあるコミットメッセージを書く
7. ✓ コミット履歴をきれいで線形に保つ
8. ✓ 秘密情報や大きいバイナリファイルをコミットしない
9. ✓ コミット前にコードをテスト
10. ✓ あらゆる誤りから復旧する方法を知る

---

緊急リカバリリファレンス

クイックリカバリコマンド:

# 最後のコミットを取り消す(変更を保持)
git reset --soft HEAD~1

# ファイルへの変更を取り消す
git checkout -- <file>

# 削除されたブランチを復