# 実験: 同一内容のblob共有を確認する
$ mkdir /tmp/git-snapshot-test && cd /tmp/git-snapshot-test
$ git init
 
# 最初のコミット
$ echo "unchanged content" > stable.txt
$ echo "version 1" > changing.txt
$ git add -A && git commit -m "v1"
 
# 2回目のコミット（changing.txtだけ変更）
$ echo "version 2" > changing.txt
$ git add -A && git commit -m "v2"
 
# stable.txt のblobハッシュを両方のコミットで比較
$ git ls-tree HEAD~1 stable.txt
100644 blob 8c4e7a1b2c3d... stable.txt
 
$ git ls-tree HEAD stable.txt
100644 blob 8c4e7a1b2c3d... stable.txt
# → 同じハッシュ = 同じオブジェクト（コピーは作られていない）

# ファイルの内容からblobオブジェクトを作成
$ echo "Hello, Git!" | git hash-object -w --stdin
557db03de997c86a4a028e1ebd3a1ceb225be238
 
# blobの中身を確認
$ git cat-file -p 557db03
Hello, Git!
 
# オブジェクトの型を確認
$ git cat-file -t 557db03
blob

# blobオブジェクトの生データを確認する
$ python3 -c "
import zlib, sys
with open('.git/objects/55/7db03de997c86a4a028e1ebd3a1ceb225be238', 'rb') as f:
    raw = zlib.decompress(f.read())
    print(repr(raw))
"
# b'blob 12\x00Hello, Git!\n'

# 同じ内容のファイルに異なる権限を設定
$ echo "#!/bin/bash" > script.sh
$ chmod +x script.sh
$ cp script.sh library.sh
$ chmod -x library.sh
 
# 両方のファイルのblobハッシュを確認
$ git hash-object script.sh
# => abc123...
$ git hash-object library.sh
# => abc123...  ← 同じハッシュ！内容が同じだから
 
# tree内では異なるモードで参照される
$ git add -A && git commit -m "test"
$ git ls-tree HEAD
100755 blob abc123... script.sh    ← 実行可能
100644 blob abc123... library.sh   ← 通常ファイル
# 同じblobオブジェクトが異なるモードで参照されている

# 空ファイルにもblobは作られる
$ touch empty.txt
$ git hash-object empty.txt
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
 
# このハッシュは全Gitリポジトリで共通
# 「空の内容」のSHA-1は常に同じ値になる
$ git cat-file -s e69de29
0

# 最新コミットのtreeを確認
$ git cat-file -p HEAD^{tree}
100644 blob 557db03de997c86a4a028e1ebd3a1ceb225be238    README.md
040000 tree 8f94139338f9404f26296befa88755fc2598c289    src
100755 blob a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0    run.sh

# treeオブジェクトの生バイナリデータを解析
$ python3 -c "
import zlib, binascii
with open('.git/objects/8f/94139338f9404f26296befa88755fc2598c289', 'rb') as f:
    raw = zlib.decompress(f.read())
    # ヘッダーを除去
    null_idx = raw.index(b'\x00')
    header = raw[:null_idx].decode()
    print(f'Header: {header}')
 
    data = raw[null_idx+1:]
    pos = 0
    while pos < len(data):
        # モードとファイル名を読む
        space_idx = data.index(b' ', pos)
        mode = data[pos:space_idx].decode()
        null_idx = data.index(b'\x00', space_idx)
        name = data[space_idx+1:null_idx].decode()
        sha1 = binascii.hexlify(data[null_idx+1:null_idx+21]).decode()
        pos = null_idx + 21
        print(f'{mode} {sha1} {name}')
"

# 再帰的にtreeを展開して確認
$ git ls-tree -r HEAD
100644 blob bbb222... package.json
100644 blob ddd444... src/index.ts
100644 blob fff666... src/components/Header.tsx
100644 blob ggg777... src/components/Footer.tsx
100644 blob iii999... src/utils/format.ts
100644 blob kkk111... tests/format.test.ts
 
# treeも含めて表示
$ git ls-tree -r -t HEAD
040000 tree ccc333... src
040000 tree eee555... src/components
040000 tree hhh888... src/utils
040000 tree jjj000... tests
100644 blob bbb222... package.json
100644 blob ddd444... src/index.ts
# ... (以下略)

# 空ディレクトリはgit addできない
$ mkdir empty-dir
$ git add empty-dir
# → 何も追加されない
 
# 慣例的な解決策: .gitkeepファイルを配置
$ touch empty-dir/.gitkeep
$ git add empty-dir/.gitkeep
# → empty-dirがtreeとして追跡される
 
# 別の解決策: .gitignoreを使う
$ echo "*" > logs/.gitignore
$ echo "!.gitignore" >> logs/.gitignore
$ git add logs/.gitignore

$ git cat-file -p HEAD
tree 8f94139338f9404f26296befa88755fc2598c289
parent a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0
author Gaku <gaku@example.com> 1707600000 +0900
committer Gaku <gaku@example.com> 1707600000 +0900
 
feat: ユーザー認証機能を追加

# パッチを適用した場合のcommitオブジェクト
$ git cat-file -p abc123
tree 8f94139338f9404f26296befa88755fc2598c289
parent def456789...
author Alice <alice@example.com> 1707500000 +0900
committer Bob <bob@example.com> 1707600000 +0900
 
fix: メモリリークを修正
 
# Alice がパッチを作成（author）
# Bob がそのパッチを適用（committer）

# cherry-pickの場合
$ git cherry-pick abc123
# → 新しいcommitが作成される
#   author = 元のcommitのauthor（Alice）
#   committer = cherry-pickを実行した人（Bob）
 
# rebaseの場合
$ git rebase main
# → 各commitが再作成される
#   author = 元のcommitのauthor（変更なし）
#   committer = rebaseを実行した人 + 現在の時刻

# author date: 元のコードが書かれた日時
# committer date: commitオブジェクトが作成された日時
 
# 両方のタイムスタンプを確認
$ git log --format='author:    %ai%ncommitter: %ci%n' -3
author:    2024-02-11 10:30:00 +0900
committer: 2024-02-11 10:30:00 +0900
 
author:    2024-02-10 15:00:00 +0900
committer: 2024-02-11 09:00:00 +0900    ← rebase等で異なる
 
# author dateを指定してcommitする
$ GIT_AUTHOR_DATE="2024-01-01T00:00:00+0900" git commit -m "New Year commit"
 
# committer dateも指定する場合
$ GIT_AUTHOR_DATE="2024-01-01T00:00:00+0900" \
  GIT_COMMITTER_DATE="2024-01-01T00:00:00+0900" \
  git commit -m "New Year commit"

# マージコミットの親を確認
$ git cat-file -p HEAD
tree 8f94139...
parent abc123...    ← 1st parent（マージ先ブランチの先頭）
parent def456...    ← 2nd parent（マージ元ブランチの先頭）
 
Merge branch 'feature/auth' into main
 
# 1st parentだけをたどる（マージ元を無視）
$ git log --first-parent
 
# オクトパスマージ（3つ以上のブランチを同時マージ）
$ git merge feature/a feature/b feature/c
# → parentが3つのcommitが作成される

# 署名付きコミットの作成
$ git commit -S -m "Signed commit"
 
# 署名付きコミットのオブジェクト内容
$ git cat-file -p HEAD
tree abc123...
parent def456...
author Gaku <gaku@example.com> 1707600000 +0900
committer Gaku <gaku@example.com> 1707600000 +0900
gpgsig -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEE...
 ...
 -----END PGP SIGNATURE-----
 
feat: 署名付きリリース
 
# 署名の検証
$ git verify-commit HEAD
gpg: Signature made Mon Feb 12 10:00:00 2024 JST
gpg:                using RSA key ABC123...
gpg: Good signature from "Gaku <gaku@example.com>" [ultimate]

# 注釈付きタグの作成
$ git tag -a v1.0.0 -m "Release version 1.0.0"
 
# タグオブジェクトの中身を確認
$ git cat-file -p v1.0.0
object a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0
type commit
tag v1.0.0
tagger Gaku <gaku@example.com> 1707600000 +0900
 
Release version 1.0.0

# commitを参照するタグ（最も一般的）
$ git tag -a v1.0.0 -m "Release v1.0.0" HEAD
 
# treeを参照するタグ（特定のディレクトリ状態をマーク）
$ git tag -a tree-snapshot -m "Snapshot of src/" HEAD^{tree}
 
# blobを参照するタグ（特定ファイルの特定バージョンをマーク）
$ BLOB_HASH=$(git rev-parse HEAD:README.md)
$ git tag -a readme-v1 -m "README v1" $BLOB_HASH
 
# 別のタグを参照するタグ（tag-of-tag、珍しい）
$ git tag -a meta-tag -m "Meta tag" v1.0.0

# 軽量タグの中身（直接commitを指す）
$ git rev-parse v1.0.0-light
abc123def456...  ← commitのSHA-1
 
$ git cat-file -t v1.0.0-light
commit  ← 直接commitを指している
 
# 注釈付きタグの中身（tagオブジェクトを指す）
$ git rev-parse v1.0.0
xyz789...  ← tagオブジェクトのSHA-1
 
$ git cat-file -t v1.0.0
tag  ← tagオブジェクトを指している
 
# tagオブジェクトの先のcommitを取得
$ git rev-parse v1.0.0^{commit}
abc123def456...
 
# タグ一覧をオブジェクト型付きで表示
$ git for-each-ref --format='%(refname:short) %(objecttype) %(objectname:short)' refs/tags/
v1.0.0        tag    xyz789
v1.0.0-light  commit abc123

# GPG署名付きタグの作成
$ git tag -s v1.0.0 -m "Signed release v1.0.0"
 
# 署名の検証
$ git verify-tag v1.0.0
gpg: Signature made Mon Feb 12 10:00:00 2024 JST
gpg: Good signature from "Gaku <gaku@example.com>"
 
# SSH鍵での署名（Git 2.34以降）
$ git config --global gpg.format ssh
$ git config --global user.signingkey ~/.ssh/id_ed25519.pub
$ git tag -s v2.0.0 -m "SSH-signed release"

# 手動でblobのハッシュを計算
$ echo -n "Hello, Git!" | python3 -c "
import hashlib, sys
content = sys.stdin.buffer.read()
header = f'blob {len(content)}\0'.encode()
print(hashlib.sha1(header + content).hexdigest())
"
557db03de997c86a4a028e1ebd3a1ceb225be238
 
# git hash-objectと同じ結果になる
$ echo -n "Hello, Git!" | git hash-object --stdin
557db03de997c86a4a028e1ebd3a1ceb225be238

# blobのハッシュ計算
# SHA-1("blob <size>\0<file-content>")
$ echo -n "Hello, Git!" | git hash-object --stdin
557db03...
 
# treeのハッシュ計算
# SHA-1("tree <size>\0<binary-tree-entries>")
# treeのバイナリ形式は直接構築が複雑なため、git mktreeを使う
$ echo -e "100644 blob 557db03de997c86a4a028e1ebd3a1ceb225be238\tREADME.md" | git mktree
# => <tree-hash>
 
# commitのハッシュ計算
# SHA-1("commit <size>\0tree ...\nparent ...\nauthor ...\ncommitter ...\n\n<message>")
$ python3 -c "
import hashlib
 
commit_content = '''tree 8f94139338f9404f26296befa88755fc2598c289
parent a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0
author Gaku <gaku@example.com> 1707600000 +0900
committer Gaku <gaku@example.com> 1707600000 +0900
 
feat: add user authentication
'''.encode()
 
header = f'commit {len(commit_content)}\0'.encode()
sha1 = hashlib.sha1(header + commit_content).hexdigest()
print(sha1)
"

# 実験: データ完全性の検証
$ git fsck
Checking object directories: 100%
Checking objects: 100%
 
# 手動でオブジェクトを破損させてみる
$ echo "corrupted" > .git/objects/55/7db03de997c86a4a028e1ebd3a1ceb225be238
 
$ git fsck
error: object file .git/objects/55/7db03... is empty or corrupted
missing blob 557db03de997c86a4a028e1ebd3a1ceb225be238
# → 即座に検出される

# SHA-256を使用するリポジトリの作成
$ git init --object-format=sha256 my-repo

# SHA-256リポジトリの作成と確認
$ git init --object-format=sha256 sha256-test
$ cd sha256-test
 
# ハッシュの長さを確認
$ echo "Hello" | git hash-object --stdin
# => 64文字のハッシュ（SHA-256）
 
# SHA-1リポジトリとの互換性に関する注意点
# 現時点では以下の制限がある:
# - SHA-1とSHA-256リポジトリ間のpush/pullは不可
# - GitHub, GitLabなどのホスティングサービスは未対応（2024年時点）
# - submoduleの参照に互換性の問題がある
 
# SHA-256リポジトリのオブジェクト形式を確認
$ git rev-parse --show-object-format
sha256

# Gitが使用しているSHA-1実装を確認
$ git version
git version 2.44.0
 
# Git 2.13以降、sha1dc（SHA-1 Collision Detection）が標準
# SHAttered攻撃パターンを検出して拒否する
 
# 衝突検出のデモンストレーション
# （実際の攻撃ファイルは配布されていないが、仕組みを理解する）
# sha1dcは計算中に衝突攻撃の特徴的なパターンを検出し、
# 検出した場合はハッシュ値を意図的に変更して衝突を回避する

# 短縮ハッシュの解決
$ git rev-parse --short HEAD
abc1234
 
# 短縮長の制御（デフォルトは動的）
$ git rev-parse --short=12 HEAD
abc1234def56
 
# 曖昧なハッシュの検出
$ git rev-parse --disambiguate=abc
abc1234def567890...
abc1235678901234...
# → 複数のオブジェクトがマッチする場合がある
 
# リポジトリ内のオブジェクト数と推奨短縮長の関係
# オブジェクト数     推奨短縮長
# 1,000              7文字
# 100,000            8-9文字
# 1,000,000          10文字
# 10,000,000         11-12文字
 
# Linuxカーネルリポジトリの場合
$ git -C /path/to/linux log --format='%h' -1
# => 12文字程度が使われる

# 1. 内容をzlib圧縮
$ python3 -c "
import zlib, hashlib
 
content = b'Hello, Git!\n'
header = f'blob {len(content)}\0'.encode()
store = header + content
 
# SHA-1ハッシュを計算
sha1 = hashlib.sha1(store).hexdigest()
print(f'SHA-1: {sha1}')
print(f'ディレクトリ: {sha1[:2]}/')
print(f'ファイル名: {sha1[2:]}')
 
# zlib圧縮
compressed = zlib.compress(store)
print(f'元のサイズ: {len(store)} bytes')
print(f'圧縮後サイズ: {len(compressed)} bytes')
print(f'圧縮率: {len(compressed)/len(store)*100:.1f}%')
"
 
# 2. .git/objects/<先頭2文字>/<残り38文字> に保存
# 先頭2文字をディレクトリ名にする理由:
# - ファイルシステムの性能（1ディレクトリに大量のファイルがあると遅い）
# - 256個のサブディレクトリに分散される

# alternatesファイル: 他のリポジトリのオブジェクトを参照する
$ cat .git/objects/info/alternates
/path/to/other/repo/.git/objects
 
# 使用例: CIでの共有オブジェクトストア
# 同じプロジェクトの複数ブランチをビルドする場合、
# 共通のオブジェクトを共有してディスク使用量を削減
 
$ git clone --reference /path/to/cached-repo https://github.com/org/repo.git
# → cachedリポジトリのオブジェクトを参照し、ネットワーク転送を削減

# 実験: オブジェクトの到達可能性を確認する
 
# 1. コミットを作成
$ echo "test" > file.txt
$ git add file.txt && git commit -m "test commit"
 
# 2. commitのハッシュを記録
$ OLD_COMMIT=$(git rev-parse HEAD)
 
# 3. 新しいコミットでamend
$ echo "test2" > file.txt
$ git add file.txt && git commit --amend -m "amended commit"
 
# 4. 古いコミットは到達不可能になる（reflogからは参照可能）
$ git cat-file -t $OLD_COMMIT
commit  # → まだ存在する
 
$ git fsck --unreachable
# → reflogがあるため「unreachable」とは表示されない
 
$ git fsck --unreachable --no-reflogs
unreachable commit $OLD_COMMIT
# → reflogを無視すると到達不可能
 
# 5. reflogの期限切れ後にGCで削除される
$ git reflog expire --expire=now --all
$ git gc --prune=now
$ git cat-file -t $OLD_COMMIT
fatal: Not a valid object name  # → 削除された

# リポジトリのオブジェクト統計を確認
$ git count-objects -v
count: 43          ← loose objectの数
size: 128          ← loose objectの合計サイズ（KB）
in-pack: 12345     ← packfile内のオブジェクト数
packs: 1           ← packfileの数
size-pack: 4567    ← packfileの合計サイズ（KB）
prune-packable: 0  ← packfileに含まれているloose objectの数
garbage: 0         ← 不正なファイルの数
size-garbage: 0    ← 不正なファイルのサイズ（KB）
 
# 大きなオブジェクトを特定する
$ git rev-list --objects --all |
  git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' |
  sort -k3 -n -r |
  head -20
blob abc123... 5242880 assets/large-image.png
blob def456... 2097152 data/sample.csv
# ...

# 1. 空のリポジトリを作成
$ git init /tmp/manual-git-test && cd /tmp/manual-git-test
 
# 2. blobを作成
$ echo "console.log('hello');" | git hash-object -w --stdin
# => aabbcc11...
 
# 3. インデックスにエントリを追加
$ git update-index --add --cacheinfo 100644,aabbcc11...,main.js
 
# 4. treeを書き出す
$ git write-tree
# => ddeeff22...
 
# 5. commitを作成（親なし = 初回コミット）
$ echo "Initial commit" | git commit-tree ddeeff22...
# => 112233aa...
 
# 6. ブランチをcommitに向ける
$ git update-ref refs/heads/main 112233aa...
 
# 7. HEADをmainに向ける
$ git symbolic-ref HEAD refs/heads/main
 
# 8. 確認
$ git log --oneline
112233a Initial commit
 
$ git show HEAD:main.js
console.log('hello');

# より複雑な構造を手動で構築する
 
# 1. 複数のblobを作成
$ echo '{ "name": "my-app" }' | git hash-object -w --stdin
# => pkg_hash...
 
$ echo 'export function add(a, b) { return a + b; }' | git hash-object -w --stdin
# => utils_hash...
 
$ echo 'import { add } from "./utils";' | git hash-object -w --stdin
# => main_hash...
 
$ echo '# My App' | git hash-object -w --stdin
# => readme_hash...
 
# 2. src/ ディレクトリのtreeを作成
$ printf '100644 blob %s\t%s\n' utils_hash utils.js main_hash main.js | git mktree
# => src_tree_hash...
 
# 3. ルートtreeを作成
$ printf '100644 blob %s\t%s\n040000 tree %s\t%s\n100644 blob %s\t%s\n' \
    pkg_hash package.json \
    src_tree_hash src \
    readme_hash README.md | git mktree
# => root_tree_hash...
 
# 4. commitを作成
$ echo "feat: initial project structure" | \
    GIT_AUTHOR_NAME="Gaku" GIT_AUTHOR_EMAIL="gaku@example.com" \
    GIT_COMMITTER_NAME="Gaku" GIT_COMMITTER_EMAIL="gaku@example.com" \
    git commit-tree root_tree_hash
# => commit_hash...
 
# 5. 確認
$ git cat-file -p root_tree_hash
100644 blob readme_hash    README.md
100644 blob pkg_hash       package.json
040000 tree src_tree_hash  src
 
$ git cat-file -p src_tree_hash
100644 blob main_hash      main.js
100644 blob utils_hash     utils.js

# 2つのtreeの差分を確認（git diff-treeの内部動作を理解する）
$ git diff-tree tree_hash_1 tree_hash_2
:100644 100644 old_blob new_blob M  src/main.js
:000000 100644 0000000 new_blob A  src/config.js
:100644 000000 old_blob 0000000 D  src/legacy.js
 
# 出力形式の解説:
# :旧モード 新モード 旧ハッシュ 新ハッシュ ステータス パス
# ステータス:
#   A = Added（追加）
#   M = Modified（変更）
#   D = Deleted（削除）
#   R = Renamed（リネーム）
#   C = Copied（コピー）
#   T = Type changed（型変更、例: ファイル→シンボリックリンク）
 
# リネーム検出付き
$ git diff-tree -M tree_hash_1 tree_hash_2
:100644 100644 abc123 abc123 R100  old-name.js  new-name.js
# R100 = 100%一致のリネーム（内容が完全に同じ）
# R075 = 75%一致のリネーム（内容が75%同じ）

# 全オブジェクトの一覧（loose + packed）
$ git rev-list --all --objects
 
# 特定オブジェクトのサイズと型
$ git cat-file -s abc123    # サイズ（バイト）
$ git cat-file -t abc123    # 型
 
# オブジェクトのダンプ（デバッグ用）
$ git cat-file --batch-check --batch-all-objects
 
# 全オブジェクトの型別カウント
$ git cat-file --batch-check --batch-all-objects | \
    awk '{print $2}' | sort | uniq -c | sort -rn
  12345 blob
   3456 tree
   1234 commit
      5 tag

# 特定のオブジェクトが存在するか確認
$ git cat-file -e abc123def456 && echo "exists" || echo "not found"
 
# リポジトリ全体の整合性チェック
$ git fsck --full
Checking object directories: 100%
Checking objects: 100%
Checking connectivity: 12345 objects reachable
 
# 厳密なチェック（より多くの問題を検出）
$ git fsck --strict
# 通常はwarningとなる問題もerrorとして報告
 
# dangling objectの確認
$ git fsck --no-reflogs
dangling commit abc123...
dangling blob def456...
# dangling = どの参照からも到達できないオブジェクト
 
# 修復手順（破損したリポジトリ）
$ git fsck --full 2>&1 | grep "missing"
missing blob abc123...
# → 他のクローンからオブジェクトをコピーして修復
$ cp /path/to/backup/.git/objects/ab/c123... .git/objects/ab/c123...

# リポジトリサイズの詳細分析スクリプト
#!/bin/bash
echo "=== Repository Object Analysis ==="
echo ""
 
# 全体統計
echo "--- General Statistics ---"
git count-objects -vH
echo ""
 
# オブジェクト型別の統計
echo "--- Object Type Distribution ---"
git cat-file --batch-check --batch-all-objects 2>/dev/null | \
    awk '{
        type[$2]++
        size[$2] += $3
    }
    END {
        for (t in type) {
            printf "%-10s count: %6d  total_size: %s\n", t, type[t], size[t]
        }
    }'
echo ""
 
# 最大のblobオブジェクトTOP10
echo "--- Largest Blobs (TOP 10) ---"
git rev-list --objects --all | \
    git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | \
    grep '^blob' | \
    sort -k3 -n -r | \
    head -10 | \
    awk '{printf "%s  %10d bytes  %s\n", $2, $3, $4}'
echo ""
 
# コミット数の統計
echo "--- Commit Statistics ---"
echo "Total commits: $(git rev-list --all --count)"
echo "Merge commits: $(git rev-list --all --merges --count)"
echo "Authors: $(git shortlog -sn --all | wc -l)"

# ファイルの各バージョンのblobハッシュを一覧表示
$ git log --follow --format="%H" -- src/config.ts | while read commit; do
    blob=$(git rev-parse "$commit:src/config.ts" 2>/dev/null)
    if [ $? -eq 0 ]; then
        size=$(git cat-file -s "$blob")
        date=$(git log -1 --format="%ai" "$commit")
        echo "$date  $blob  ${size}bytes"
    fi
done
 
# 出力例:
# 2024-02-11 10:30:00 +0900  abc123...  2048bytes
# 2024-02-10 15:00:00 +0900  def456...  1856bytes
# 2024-02-09 09:00:00 +0900  ghi789...  1024bytes
 
# 特定のバージョン間の差分を確認
$ git diff blob_hash_1 blob_hash_2

# サブモジュールはtree内でモード160000として記録される
$ git ls-tree HEAD
100644 blob abc123... .gitmodules
160000 commit def456... libs/external-lib    ← サブモジュール
 
# サブモジュールのcommitハッシュを確認
$ git ls-tree HEAD libs/external-lib
160000 commit def456... libs/external-lib
# → def456... はサブモジュールリポジトリのcommitハッシュ
 
# .gitmodulesファイルの内容
$ git cat-file -p HEAD:.gitmodules
[submodule "libs/external-lib"]
    path = libs/external-lib
    url = https://github.com/org/external-lib.git

# shallow clone: 履歴を制限してクローン
$ git clone --depth=1 https://github.com/org/repo.git
# → 最新のcommitとそのtree/blobのみ取得
 
# shallow cloneのオブジェクト状態
$ git cat-file -p HEAD
tree abc123...
parent def456...     ← 存在するが、このcommitオブジェクトは取得されていない
author ...
 
# shallow boundary（浅いクローンの境界）を確認
$ cat .git/shallow
def456789...    ← この先の履歴は持っていない
 
# 深さを追加で取得
$ git fetch --deepen=10
# → 10コミット分追加で取得
 
# 完全な履歴を取得
$ git fetch --unshallow
# → 全コミットを取得（.git/shallowファイルが削除される）

# git replaceを使ってオブジェクトを「差し替え」る
# （元のオブジェクトは変更せず、参照時に別のオブジェクトを返す）
 
# ユースケース1: コミットメッセージの修正（歴史を書き換えずに）
$ git replace --edit HEAD
# → エディタが開き、commitオブジェクトの内容を編集できる
# → .git/refs/replace/<original-hash> に新しいハッシュが記録される
 
# ユースケース2: 大きな歴史の接合（graft point）
# 別々のリポジトリの歴史を接合する
$ git replace --graft <commit> <new-parent>
 
# replaceオブジェクトの一覧
$ git replace -l
 
# replaceを無視してオリジナルを参照
$ git --no-replace-objects cat-file -p HEAD
 
# replaceの削除
$ git replace -d <original-hash>

# 大規模リポジトリの最適化設定
$ git config core.commitGraph true        # commit-graphを有効化
$ git config gc.writeCommitGraph true      # GC時にcommit-graphを更新
$ git config feature.manyFiles true        # 大量ファイル向け最適化
$ git config core.untrackedCache true      # untracked fileのキャッシュ
$ git config core.fsmonitor true           # ファイルシステム監視
 
# commit-graphの生成
$ git commit-graph write --reachable
# → .git/objects/info/commit-graphs/ にバイナリファイルが作成
# → git logの高速化に大きく寄与する
 
# commit-graphの内容確認
$ git commit-graph verify

# blobless clone: blobを取得しない
$ git clone --filter=blob:none https://github.com/org/large-repo.git
# → commit + treeのみ取得、blobはcheckout時にオンデマンド取得
 
# treeless clone: tree + blobを取得しない
$ git clone --filter=tree:0 https://github.com/org/large-repo.git
# → commitのみ取得、tree/blobは必要時に取得
 
# サイズ制限付きclone: 指定サイズ以上のblobを除外
$ git clone --filter=blob:limit=1m https://github.com/org/large-repo.git
# → 1MB以上のblobは取得しない
 
# 遅延取得されたオブジェクトの確認
$ git rev-list --objects --all --missing=print | grep "^?"
?abc123...    ← 未取得のオブジェクト
?def456...
 
# 明示的にオブジェクトを取得
$ git fetch origin --filter=blob:none

# sparse-checkoutの設定
$ git sparse-checkout init --cone
$ git sparse-checkout set src/frontend
 
# sparse-checkout時のオブジェクト取得
# → treeオブジェクトは全て取得されるが、
#   blobはsparse-checkoutのパターンに一致するファイルのみcheckoutされる
# → partial cloneと組み合わせると、不要なblobは全く取得されない
 
$ git clone --filter=blob:none https://github.com/org/large-repo.git
$ cd large-repo
$ git sparse-checkout init --cone
$ git sparse-checkout set src/frontend
# → src/frontend/ 配下のblobのみオンデマンド取得される

# NG: 巨大ファイルを直接コミット
$ git add dataset-5gb.csv
$ git commit -m "Add dataset"
# → blobが5GB消費、gc後もpackfileが肥大化
# → clone時に全履歴をダウンロードする必要がある
 
# OK: Git LFS を使用する
$ git lfs install
$ git lfs track "*.csv"
$ git add .gitattributes dataset-5gb.csv
$ git commit -m "Add dataset via LFS"

# 既にコミットされた巨大ファイルの影響を確認
$ git rev-list --objects --all | \
    git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | \
    grep '^blob' | sort -k3 -n -r | head -5
 
# 巨大ファイルを履歴から完全に除去する
$ git filter-repo --path dataset-5gb.csv --invert-paths
# ※ git filter-branchは非推奨、git filter-repoを使う
 
# LFS移行ツール
$ git lfs migrate import --include="*.csv" --everything
# → 全ブランチの全履歴でCSVファイルをLFSに移行

# NG: スクリプトに短縮ハッシュをハードコード
DEPLOY_COMMIT="abc123"
git checkout $DEPLOY_COMMIT
 
# OK: タグやブランチ名を使う、または十分な長さのハッシュを使用
DEPLOY_TAG="v1.0.0"
git checkout $DEPLOY_TAG
 
# OK: フルハッシュを使う（自動化スクリプト）
DEPLOY_COMMIT=$(git rev-parse v1.0.0)
git checkout $DEPLOY_COMMIT

# NG: .git/objects/ を手動で操作
$ rm .git/objects/ab/c123def456...
# → リポジトリが破損する
 
# NG: .git/objects/ をコピーしてバックアップ
$ cp -r .git/objects/ /backup/
# → packfileのロック状態が不整合になる可能性
 
# OK: Gitコマンドを使う
$ git gc                    # オブジェクトの整理
$ git prune                 # 到達不可能なオブジェクトの削除
$ git bundle create backup.bundle --all  # バックアップ

# NG: 機密情報をコミット
$ echo "API_KEY=sk-abc123" > .env
$ git add .env && git commit -m "Add config"
# → blobオブジェクトとして永続的に保存される
# → git rmしても過去のcommitからアクセス可能
 
# 機密情報を履歴から完全に除去する
$ git filter-repo --path .env --invert-paths --force
# → 全commitが書き換えられ、新しいSHA-1が割り当てられる
# → すべてのフォーク・クローンに影響するため注意
 
# OK: .gitignoreで最初から除外
$ echo ".env" >> .gitignore
$ git add .gitignore && git commit -m "Ignore .env"

# NG: 頻繁にrebase + force push
$ git rebase -i HEAD~10
$ git push --force
# → リモートリポジトリに到達不可能なオブジェクトが蓄積
# → 他の開発者のローカルリポジトリとの整合性が崩れる
 
# OK: force-with-leaseを使用し、影響を最小限に
$ git push --force-with-lease
# → リモートの状態が想定と異なる場合は拒否される

# 検証
$ for i in $(seq 1 10); do cp template.txt "file_$i.txt"; done
$ git add -A && git commit -m "Add 10 identical files"
$ git ls-tree HEAD | awk '{print $3}' | sort -u | wc -l
# → 1（blobは1つだけ）

# amend前のcommitを復元する
$ git reflog
abc123 HEAD@{0}: commit (amend): fixed message
def456 HEAD@{1}: commit: original message
 
$ git checkout def456
# → amend前の状態を確認できる
 
$ git branch recover-amend def456
# → amend前のcommitをブランチとして保存

# 自動GCのトリガー条件
$ git config gc.auto
6700    # loose objectがこの数を超えると自動GC（デフォルト: 6700）
 
$ git config gc.autoPackLimit
50      # packfileがこの数を超えると自動GC（デフォルト: 50）
 
# 自動GCを無効化
$ git config gc.auto 0
 
# 手動GC
$ git gc
$ git gc --aggressive    # より積極的な圧縮（時間がかかる）

# 実験
$ echo "version 1" > test.txt
$ git add test.txt && git commit -m "v1"
$ BLOB_V1=$(git rev-parse HEAD:test.txt)
 
$ echo "version 2" > test.txt
$ git add test.txt && git commit -m "v2"
$ BLOB_V2=$(git rev-parse HEAD:test.txt)
 
# 異なるハッシュ = 異なるオブジェクト
$ echo "$BLOB_V1"
$ echo "$BLOB_V2"
# → 全く異なるハッシュ
 
# packfile内ではdelta圧縮される
$ git gc
$ git verify-pack -v .git/objects/pack/*.idx | grep "$BLOB_V2"
# → deltaとして表示される（基準blobからの差分のみ保存）

# 実験
$ git log --format="%H %T" -5
commit1 tree_A    ← 現在
commit2 tree_B    ← revertされる変更
commit3 tree_A    ← revert後（tree_Aと同じ！）
 
# treeが同じでもcommitは別オブジェクト
# （parent, author, committer, messageが異なるため）

# リポジトリの暗号化が必要な場合のオプション
# 1. git-crypt: 特定ファイルを暗号化
$ git-crypt init
$ echo "secrets/** filter=git-crypt diff=git-crypt" >> .gitattributes
 
# 2. ファイルシステムレベルの暗号化
# → LUKS, FileVault, BitLockerなどを使用
 
# 3. リポジトリホスティングのアクセス制御
# → GitHub Private Repository, GitLab Privateなど

# 1. 整合性チェック
$ git fsck --full --strict 2>&1 | tee fsck-report.txt
 
# 典型的なエラーと対処法:
 
# エラー: missing object
# → オブジェクトファイルが削除された or 破損した
$ git fsck 2>&1 | grep "missing"
missing blob abc123...
# 対処: バックアップまたは他のクローンからオブジェクトを取得
$ git fetch origin  # リモートから不足オブジェクトを取得
 
# エラー: corrupt object
# → zlib圧縮データが破損している
$ git fsck 2>&1 | grep "corrupt"
error: corrupt loose object 'abc123...'
# 対処: 破損ファイルを削除し、リモートから再取得
$ rm .git/objects/ab/c123...
$ git fetch origin
 
# エラー: broken link
# → commitやtreeが参照するオブジェクトが存在しない
$ git fsck 2>&1 | grep "broken"
broken link from commit abc123...
# 対処: git reflogから正常な状態に復帰
$ git reflog
$ git reset --hard HEAD@{n}

# シナリオ: 誤ってgit reset --hardした後のファイル復元
 
# 1. reflogから元のcommitを特定
$ git reflog
abc123 HEAD@{0}: reset: moving to HEAD~5
def456 HEAD@{1}: commit: important work
 
# 2. danglingオブジェクトを確認
$ git fsck --lost-found
dangling commit def456...
dangling blob ghi789...
 
# 3. danglingオブジェクトの内容を確認
$ git show def456
# → commitの内容が表示される
 
# 4. 復元
$ git checkout -b recovery def456
 
# 5. .git/lost-found/ に復元されたオブジェクト
$ ls .git/lost-found/
other/    ← blob, treeなど
commit/   ← danglingなcommit

# Git操作のトレース（何が遅いか特定する）
$ GIT_TRACE=1 git status
$ GIT_TRACE_PERFORMANCE=1 git log --oneline -100
 
# オブジェクトアクセスのトレース
$ GIT_TRACE_PACK_ACCESS=1 git log --oneline -10
 
# packfileのインデックス再構築（破損時）
$ git index-pack .git/objects/pack/pack-abc123.pack
 
# loose objectの最適化
$ git repack -a -d
# -a: 全オブジェクトを1つのpackfileにまとめる
# -d: 不要なloose objectを削除
 
# より積極的な最適化
$ git repack -a -d --depth=250 --window=250
# depth: deltaチェーンの最大深度
# window: delta計算時の比較ウィンドウサイズ