# バイナリファイルの場合
$ git merge feature
# warning: Cannot merge binary files: assets/logo.png
# → バイナリファイルは行分割できないため、常にコンフリクト扱い
# → ours/theirsのどちらかを手動で選択する
 
# バイナリのコンフリクト解決
$ git checkout --ours assets/logo.png     # 自分側を採用
$ git checkout --theirs assets/logo.png   # 相手側を採用
$ git add assets/logo.png
 
# カスタムマージドライバーの設定
$ cat .gitattributes
*.psd merge=binary        # バイナリとして扱う（常にコンフリクト）
*.lock merge=ours         # 自分側を常に採用（lockファイル）
*.pbxproj merge=union     # 両方の変更を結合（Xcodeプロジェクト）

# マージドライバーの定義
$ git config merge.union.driver "union-merge %O %A %B"
$ git config merge.custom.driver "custom-merge-tool %O %A %B %P"
# %O = 共通祖先（base）
# %A = 自分側（ours）
# %B = 相手側（theirs）
# %P = ファイルパス

# 2つのブランチの共通祖先を特定
$ git merge-base main feature/auth
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0
 
# 複数の共通祖先がある場合（criss-cross merge）
$ git merge-base --all main feature/auth
a1b2c3d4...
f5e6d7c8...

# merge baseの詳細な確認
$ git merge-base --is-ancestor A B
# exit 0: AはBの祖先
# exit 1: AはBの祖先ではない
 
# fork-pointの検出（reflogベース）
$ git merge-base --fork-point main feature
# → featureがmainから分岐した正確なポイントを検出
# → reflogを使うため、mainがrebaseされた場合にも対応
 
# octopus mergeのmerge base
$ git merge-base --octopus branch-a branch-b branch-c
# → 3ブランチ共通の祖先を計算

# ort戦略の明示的な使用
$ git merge -s ort feature/auth
 
# ort戦略のオプション
$ git merge -X ours feature/auth      # コンフリクト時に自分側を優先
$ git merge -X theirs feature/auth    # コンフリクト時に相手側を優先
$ git merge -X patience feature/auth  # patience diffアルゴリズム使用

# ortの性能改善を示す例（大規模リポジトリ）
# Linux kernelリポジトリでのベンチマーク（参考値）
# recursive: 25.3秒
# ort:        4.1秒  (約6倍高速)
 
# ortが作業ディレクトリを使用しないことの確認
$ git merge -s ort feature/auth
# → マージ中に作業ディレクトリのファイルが一時的に変更されない
# → 他のプロセスが同時にファイルを参照しても安全

# recursive戦略の再帰深さ制限
# デフォルトでは再帰の深さに制限なし（実用上は問題にならない）
# 理論上は無限ループしない（DAGなので祖先は必ず有限）
 
# recursiveで仮想共通祖先の作成時にコンフリクトが発生する場合
# → コンフリクトマーカーを含んだ状態で仮想共通祖先を作成
# → 最終マージのコンフリクト解決結果に影響する可能性がある

# resolve戦略: 複数の共通祖先がある場合、1つだけを選択
$ git merge -s resolve feature/auth
 
# 使用場面:
# - recursive/ortでコンフリクトが発生し、resolveだと成功する場合がある
# - criss-cross mergeの状況で、特定の共通祖先を使いたい場合
# - 非常にまれだが、デバッグ目的で使用することもある

# 3つ以上のブランチを同時にマージ
$ git merge feature/a feature/b feature/c
# → 自動的にoctopus戦略が選択される
 
# octopus戦略の制約
# - コンフリクトが発生すると自動的に中断される
# - 手動コンフリクト解決は不可能
# - コンフリクトが予想される場合は個別にマージすべき

# -s ours: 戦略としてのours（相手の変更を完全に無視）
$ git merge -s ours feature/deprecated
# → 自分側（HEAD）の内容をそのまま保持
# → feature/deprecatedの変更は一切反映されない
# → しかし、履歴上はマージ済みとして記録される
 
# 主な用途:
# 1. 不要なブランチの履歴を閉じる
# 2. リリースブランチの不要な変更をスキップ
# 3. 意図的に特定のブランチの変更を拒否する
 
# 重要: -s ours と -X ours は全く異なる
$ git merge -s ours feature    # 戦略: 相手の変更を全て無視
$ git merge -X ours feature    # オプション: コンフリクト時のみ自分側を優先

# subtree戦略: サブプロジェクトの統合
$ git merge -s subtree library-repo/main
 
# 使用例: 別リポジトリのコードをサブディレクトリに統合
$ git remote add library-repo https://github.com/example/lib.git
$ git fetch library-repo
$ git merge -s subtree --allow-unrelated-histories library-repo/main
 
# subtree戦略の動作:
# 1. 相手側のファイルツリーが自分側のサブディレクトリに対応するか自動検出
# 2. パスの対応関係を調整してから3-way mergeを実行
# 3. git-subtreeコマンドの内部でも使用される

# fast-forwardが可能な場合
#   main:    A---B
#   feature: A---B---C---D
 
$ git checkout main
$ git merge feature
# → mainのポインタをDに移動するだけ（新commitは作らない）
 
# fast-forwardを強制的にno-ffにする
$ git merge --no-ff feature
# → マージコミットを必ず作成する
 
# fast-forward限定（不可能ならエラー）
$ git merge --ff-only feature

# チームでの推奨設定: --no-ffを強制
$ git config merge.ff false
# → 全てのマージでマージコミットが作成される
# → 「いつマージされたか」が履歴から明確にわかる
 
# 個人ブランチでは--ff-onlyを使い、rebase + ff-onlyの運用
$ git config pull.ff only
# → pullがfast-forwardできない場合はエラー（rebaseを促す）

# コンフリクト状態のインデックスを確認
$ git ls-files -u
100644 abc123... 1	src/auth.js    # Stage 1: 共通祖先 (base)
100644 def456... 2	src/auth.js    # Stage 2: 自分側 (ours / HEAD)
100644 789abc... 3	src/auth.js    # Stage 3: 相手側 (theirs / MERGE_HEAD)
 
# 各ステージの内容を確認
$ git show :1:src/auth.js    # base
$ git show :2:src/auth.js    # ours
$ git show :3:src/auth.js    # theirs
 
# ステージ番号の意味
# Stage 0: 通常のファイル（コンフリクトなし）
# Stage 1: Base（共通祖先）
# Stage 2: Ours（HEAD側）
# Stage 3: Theirs（MERGE_HEAD側）

// コンフリクトが発生したファイルの内容
function authenticate(user) {
<<<<<<< HEAD
  return bcrypt.compare(user.password, hash);
||||||| abc123 (merge.conflictStyle = zdiff3 の場合)
  return checkPassword(user.password);
=======
  return argon2.verify(hash, user.password);
>>>>>>> feature/auth
}

# コンフリクトスタイルの設定
$ git config merge.conflictStyle zdiff3
# zdiff3: base（共通祖先）の内容も表示される → 判断が容易に
 
# 利用可能なコンフリクトスタイル
# merge: デフォルト。ours/theirsの2つだけ表示
# diff3: base + ours + theirsの3つを表示
# zdiff3: diff3の改良版。baseとours/theirsの共通部分を省略（Git 2.35+）

# rerereを有効化
$ git config rerere.enabled true
 
# 動作の仕組み:
# 1. コンフリクトが発生 → コンフリクトのパターンを記録
# 2. 手動で解決 → 解決方法を .git/rr-cache/ に保存
# 3. 同じコンフリクトが再発 → 自動的に以前の解決を適用
 
# 記録された解決の確認
$ git rerere status
$ git rerere diff
 
# rerereのキャッシュを手動管理
$ git rerere forget <pathspec>       # 特定ファイルの記録を削除
$ git rerere gc                       # 古い記録を削除

# rerereの具体的な使用シナリオ
 
# シナリオ: featureブランチをmainにrebaseするたびに同じコンフリクトが発生
 
# 1回目: 手動で解決
$ git rebase main
# CONFLICT! src/config.js
$ vim src/config.js       # 手動で解決
$ git add src/config.js
$ git rebase --continue
# → rerereが解決パターンを記録
 
# 2回目以降: 自動で解決
$ git rebase main
# CONFLICT! src/config.js
# Resolved 'src/config.js' using previous resolution.
$ git add src/config.js    # rerereの解決結果を確認して追加
$ git rebase --continue
 
# rerereキャッシュの中身
$ ls .git/rr-cache/
abc123def456.../
├── preimage    # コンフリクトの状態（マーカー付き）
└── postimage   # 解決後の状態

# コンフリクトの確認
$ git diff --name-only --diff-filter=U
# → コンフリクトしているファイルの一覧
 
# 各ファイルのコンフリクト箇所をカウント
$ grep -c "<<<<<<< HEAD" src/auth.js
3
 
# ours/theirsで一括解決
$ git checkout --ours src/auth.js      # 自分側で一括解決
$ git checkout --theirs src/auth.js    # 相手側で一括解決
$ git add src/auth.js
 
# merge-toolを使った対話的解決
$ git mergetool
# → 設定されたマージツール（vimdiff, meld, kdiff3等）が起動
 
# mergeツールの設定
$ git config merge.tool vimdiff
$ git config mergetool.vimdiff.layout "LOCAL,BASE,REMOTE / MERGED"
$ git config mergetool.keepBackup false
# keepBackup=false: .origファイルを作成しない

# マージの中断と再開
$ git merge --abort         # マージを完全に中断（マージ前に戻る）
$ git merge --quit          # マージを中断（作業ディレクトリの変更は保持）
$ git merge --continue      # コンフリクト解決後にマージを続行
 
# rebase中のコンフリクト
$ git rebase --abort        # rebaseを完全に中断
$ git rebase --skip         # 現在のコミットをスキップして続行
$ git rebase --continue     # コンフリクト解決後にrebaseを続行

# パターン1: 両方の変更を取り込む（手動マージ）
# Before:
# <<<<<<< HEAD
#   validateEmail(email);
#   validatePassword(password);
# =======
#   validateEmail(email);
#   sanitizeInput(email);
# >>>>>>> feature/security
 
# After:（両方の変更を採用）
#   validateEmail(email);
#   validatePassword(password);
#   sanitizeInput(email);
 
# パターン2: 構造的なコンフリクト（関数の並び順が変わった場合）
# → diffアルゴリズムの変更で改善できることがある
$ git merge -X diff-algorithm=histogram feature
$ git merge -X diff-algorithm=patience feature
 
# パターン3: 大量のコンフリクトを効率的に解決
# コンフリクトファイルの一覧とカウント
$ git diff --name-only --diff-filter=U | wc -l
42
 
# パターンに基づく一括解決
$ git diff --name-only --diff-filter=U | xargs -I{} git checkout --theirs {}
$ git diff --name-only --diff-filter=U | xargs git add
# → 全てtheirsで解決（内容を後で確認する前提）

$ git checkout feature
$ git rebase main

# rebase の内部動作は以下のcherry-pickと同等
$ git checkout main                # mainに移動
$ git cherry-pick C               # C を適用 → C'
$ git cherry-pick D               # D を適用 → D'
$ git cherry-pick E               # E を適用 → E'
$ git branch -f feature HEAD      # featureを更新
$ git checkout feature             # featureに移動
 
# ただし実際のrebaseは:
# 1. detached HEAD状態で実行
# 2. ORIG_HEAD にrebase前のHEADを保存
# 3. .git/rebase-merge/ または .git/rebase-apply/ に状態を保存
# 4. 全cherry-pick完了後にref更新

# cherry-pick: 特定のコミットを現在のブランチに適用
$ git cherry-pick abc123
# → abc123の変更（差分）を現在のHEADに適用
# → 新しいcommitが作成される（元のcommitのメッセージを引き継ぐ）
# → cherry-pick元と先で同じ変更が別のcommitとして存在する
 
# rebase: ブランチ全体を移動
$ git rebase main
# → 内部的にはcherry-pickの連鎖だが、ブランチrefも更新される
# → 元のcommitへの参照はreflogのみ

# cherry-pickの詳細オプション
$ git cherry-pick abc123 --no-commit
# → 変更を適用するがcommitは作成しない（作業ディレクトリにのみ反映）
 
$ git cherry-pick abc123..def456
# → 範囲指定で複数のcommitをcherry-pick
 
$ git cherry-pick -x abc123
# → コミットメッセージに "(cherry picked from commit abc123)" を追記
# → 追跡に便利
 
$ git cherry-pick -m 1 MERGE_COMMIT
# → マージコミットをcherry-pick（-m 1 で第一親をbaseに使用）

# merge: 履歴を保存、マージコミット作成
$ git checkout main
$ git merge feature
 
# rebase: 履歴を直線化、マージコミットなし
$ git checkout feature
$ git rebase main
$ git checkout main
$ git merge feature  # fast-forward

# --onto: より柔軟なrebase先の指定
$ git rebase --onto NEW_BASE OLD_BASE BRANCH
 
# 使用例1: featureブランチの一部だけを別のブランチに移動
# Before:
#     C---D---E  feature (HEAD)
#    /
# A---B---F  main
#        \
#         G---H  release
 
# featureのD, Eだけをreleaseに移動したい
$ git rebase --onto release C feature
# → D'---E' がreleaseの上に作成される
 
# 使用例2: マージ済みのcommitをスキップしてrebase
# Before:
#     C---D---E---F  feature
#    /       \
# A---B-------M  main (Dがマージ済み)
 
# D を除いて feature を main にrebase
$ git rebase --onto main D feature
# → C'---E'---F' がmainの上に作成される

# diffアルゴリズムの指定
$ git diff --diff-algorithm=myers      # デフォルト（Myers）
$ git diff --diff-algorithm=minimal    # 最小差分（遅いが正確）
$ git diff --diff-algorithm=patience   # patience diff
$ git diff --diff-algorithm=histogram  # histogram diff
 
# 永続設定
$ git config diff.algorithm histogram

# Gitはリネームを明示的に記録しない
# マージ時にヒューリスティックでリネームを検出する
 
# リネーム検出の閾値（類似度）を設定
$ git merge -X rename-threshold=50 feature
# → 50%以上の類似度でリネームと判定
 
# diffでのリネーム検出
$ git diff --find-renames=50 HEAD~1
# rename src/old.js => src/new.js (85%)
 
# コピー検出も可能
$ git diff --find-copies --find-copies-harder HEAD~1
# copy src/template.js => src/new-page.js (72%)

# リネーム検出の制限設定
$ git config merge.renameLimit 10000
# デフォルト: 7000
# → 追加+削除されたファイルの組み合わせ数の上限
# → 超える場合はリネーム検出がスキップされる
 
$ git config diff.renameLimit 10000
# diff時のリネーム検出制限
 
# ort戦略でのリネーム検出の高速化
# ort は以下の最適化を行う:
# 1. ディレクトリリネームの検出（ファイル単位ではなくディレクトリ単位）
# 2. 前回のマージ結果のキャッシュ
# 3. 不要な類似度計算のスキップ

# ort戦略ではディレクトリリネームも検出する
 
# 例:
# Base: src/components/auth/login.js, src/components/auth/register.js
# Ours: src/modules/auth/login.js, src/modules/auth/register.js (ディレクトリ移動)
# Theirs: src/components/auth/login.js, src/components/auth/register.js,
#          src/components/auth/forgot-password.js (新ファイル追加)
 
# ort戦略の結果:
# → src/components/auth/ → src/modules/auth/ のディレクトリリネームを検出
# → Theirsの新ファイルも src/modules/auth/forgot-password.js に配置
# → 手動でファイルを移動する必要がない

# コンフリクト解決のオプション
$ git merge -X ours feature         # コンフリクト時に自分側を優先
$ git merge -X theirs feature       # コンフリクト時に相手側を優先
 
# 空白の扱い
$ git merge -X ignore-space-change feature    # 空白の量の変更を無視
$ git merge -X ignore-all-space feature       # 全ての空白を無視
$ git merge -X ignore-space-at-eol feature    # 行末空白を無視
 
# リネーム
$ git merge -X rename-threshold=40 feature    # リネーム検出閾値を変更
 
# diffアルゴリズム
$ git merge -X diff-algorithm=histogram feature
 
# サブツリー
$ git merge -X subtree=path/to/dir feature    # サブツリーパスの指定
 
# find-renames（リネーム検出の詳細制御）
$ git merge -X find-renames=30 feature        # 30%一致でリネーム判定

# --no-commit: マージ結果をコミットせずにステージに留める
$ git merge --no-commit feature
# → コンフリクトがなくてもコミットしない
# → 内容を確認・修正してから手動でcommitできる
$ git diff --staged   # マージ結果を確認
$ git commit -m "merge: feature branch with modifications"
 
# --squash: マージ結果を1つのcommitにまとめる
$ git merge --squash feature
# → featureの全変更を作業ディレクトリとインデックスに適用
# → マージcommitではなく通常のcommitとして記録
# → 親はHEADのみ（featureブランチへの参照なし）
$ git commit -m "feat: squash merge of feature branch"
 
# 注意: --squashはfeatureブランチを「マージ済み」として記録しない
# → 同じfeatureブランチを再度マージしようとするとコンフリクトする
# → featureブランチは使い終わったら削除すべき

# NG: mainやdevelopなど共有ブランチをrebase
$ git checkout main
$ git rebase feature
$ git push --force origin main
# → 他のメンバーのローカルmainと履歴が不整合
# → 他のメンバーが強制的にreset --hardする必要がある
 
# OK: 自分専用のfeatureブランチのみrebaseする
$ git checkout feature/my-work
$ git rebase main
$ git push --force-with-lease origin feature/my-work
# --force-with-lease: 他者のpushがあれば拒否される

# NG: "ours"戦略で相手の変更を完全に無視
$ git merge -s ours feature/important-fix
# → feature/important-fix の変更が一切反映されない
# → 履歴上はマージ済みに見えるため、再マージも不可
 
# OK: 意図的に履歴を閉じる場合のみ使用
$ git merge -s ours legacy/deprecated-feature
# → 明確に "このブランチの内容は不要" という意思表示として使用

# NG: コンフリクトの内容を確認せずに一括解決
$ git checkout --theirs .
$ git add .
$ git commit
# → 自分の変更が全て失われる可能性がある
# → テストもせずにマージ完了としてしまう
 
# OK: 各コンフリクトを個別に確認して解決
$ git diff --name-only --diff-filter=U    # コンフリクトファイル一覧
$ git show :1:src/auth.js > /tmp/base.js  # base版を確認
$ git show :2:src/auth.js > /tmp/ours.js  # ours版を確認
$ git show :3:src/auth.js > /tmp/theirs.js # theirs版を確認
# → 3つのバージョンを比較して適切に解決
$ git mergetool src/auth.js               # マージツールで解決

# NG: デフォルトのマージメッセージをそのまま使用
$ git merge feature
# "Merge branch 'feature' into main"  ← 情報が少なすぎる
 
# OK: 意味のあるマージメッセージを記述
$ git merge --no-ff feature -m "merge: feature/auth - OAuth2認証の追加
 
- Google/GitHubプロバイダー対応
- セッション管理の統合
- 既存のパスワード認証との互換性を維持
 
Closes #123"

# NG: rebaseが完了する前にpush
$ git rebase main
# コンフリクト発生...
$ git push origin feature   # ← まだrebase途中
# → rebase途中の不完全な状態がリモートに残る
 
# OK: rebaseを完了してからpush
$ git rebase main
# コンフリクト解決...
$ git rebase --continue
# 全コミットの適用完了
$ git push --force-with-lease origin feature

# 演習1: 基本実装のテンプレート
class Exercise1:
    """基本的な実装パターンの演習"""
 
    def __init__(self):
        self.data = []
 
    def validate_input(self, value):
        """入力値の検証"""
        if value is None:
            raise ValueError("入力値がNoneです")
        return True
 
    def process(self, value):
        """データ処理のメインロジック"""
        self.validate_input(value)
        self.data.append(value)
        return self.data
 
    def get_results(self):
        """処理結果の取得"""
        return {
            'count': len(self.data),
            'data': self.data
        }
 
# テスト
def test_exercise1():
    ex = Exercise1()
    assert ex.process(1) == [1]
    assert ex.process(2) == [1, 2]
    assert ex.get_results()['count'] == 2
 
    try:
        ex.process(None)
        assert False, "例外が発生するべき"
    except ValueError:
        pass
 
    print("全テスト合格!")
 
test_exercise1()

# 演習2: 応用パターン
from typing import List, Dict, Optional
from datetime import datetime
 
class AdvancedExercise:
    """応用パターンの演習"""
 
    def __init__(self, max_size: int = 100):
        self._items: List[Dict] = []
        self._max_size = max_size
        self._created_at = datetime.now()
 
    def add(self, key: str, value: any) -> bool:
        """アイテムの追加（サイズ制限付き）"""
        if len(self._items) >= self._max_size:
            return False
        self._items.append({
            'key': key,
            'value': value,
            'timestamp': datetime.now().isoformat()
        })
        return True
 
    def find(self, key: str) -> Optional[Dict]:
        """キーによる検索"""
        for item in reversed(self._items):
            if item['key'] == key:
                return item
        return None
 
    def remove(self, key: str) -> bool:
        """キーによる削除"""
        for i, item in enumerate(self._items):
            if item['key'] == key:
                self._items.pop(i)
                return True
        return False
 
    def stats(self) -> Dict:
        """統計情報"""
        return {
            'total_items': len(self._items),
            'max_size': self._max_size,
            'usage_percent': len(self._items) / self._max_size * 100,
            'uptime': str(datetime.now() - self._created_at)
        }
 
# テスト
def test_advanced():
    ex = AdvancedExercise(max_size=3)
    assert ex.add("a", 1) == True
    assert ex.add("b", 2) == True
    assert ex.add("c", 3) == True
    assert ex.add("d", 4) == False  # サイズ制限
    assert ex.find("b")['value'] == 2
    assert ex.remove("b") == True
    assert ex.find("b") is None
    stats = ex.stats()
    assert stats['total_items'] == 2
    print("応用テスト全合格!")
 
test_advanced()

# 演習3: パフォーマンス最適化
import time
from functools import lru_cache
 
# 最適化前（O(n^2)）
def slow_search(data: list, target: int) -> int:
    """非効率な検索"""
    for i in range(len(data)):
        for j in range(i + 1, len(data)):
            if data[i] + data[j] == target:
                return (i, j)
    return (-1, -1)
 
# 最適化後（O(n)）
def fast_search(data: list, target: int) -> tuple:
    """ハッシュマップを使った効率的な検索"""
    seen = {}
    for i, num in enumerate(data):
        complement = target - num
        if complement in seen:
            return (seen[complement], i)
        seen[num] = i
    return (-1, -1)
 
# ベンチマーク
def benchmark():
    import random
    data = list(range(5000))
    random.shuffle(data)
    target = data[100] + data[4000]
 
    start = time.time()
    result1 = slow_search(data, target)
    slow_time = time.time() - start
 
    start = time.time()
    result2 = fast_search(data, target)
    fast_time = time.time() - start
 
    print(f"非効率版: {slow_time:.4f}秒")
    print(f"効率版:   {fast_time:.6f}秒")
    print(f"高速化率: {slow_time/fast_time:.0f}倍")
 
benchmark()

# マージの中断
$ git merge --abort
 
# rebaseの中断
$ git rebase --abort
 
# cherry-pickの中断
$ git cherry-pick --abort

$ git merge feature/a feature/b feature/c
# → 自動的にoctopus戦略が選択される

# 1. コンフリクトを手動で解決
$ vim src/conflicted-file.js
 
# 2. 解決したファイルをステージ
$ git add src/conflicted-file.js
 
# 3. rebaseを続行
$ git rebase --continue
 
# または、このコミットをスキップ
$ git rebase --skip
 
# または、rebase全体を中断
$ git rebase --abort

$ git config --global merge.conflictStyle zdiff3

# マージcommitの取り消し
$ git revert -m 1 abc123
# → マージで導入された変更を打ち消すcommitが作成される
 
# 注意: revertしたマージを再度マージしたい場合
# → revertのrevertが必要
$ git revert def456  # def456 = 上記のrevert commit
$ git merge feature  # 再マージが可能になる