設定と初期化
グローバルとローカル設定
Git は3つのレベルで設定を保存します:システム(/etc/gitconfig)、グローバル(ユーザーの ~/.gitconfig)、ローカル(リポジトリごとの .git/config)。下位レベルが上位レベルを上書きします。コミット前に必ず user.name と user.email を設定してください。そうしないと役に立たないデフォルトIDが使用されます。init.defaultBranch を main に設定すると、非推奨の master デフォルトを避け、現代の慣行に合わせることができます。
# set user identity (required for commits)
git config --global user.name "Alice Lee"
git config --global user.email "[email protected]"
# set default editor and branch name
git config --global core.editor "code --wait"
git config --global init.defaultBranch main
# view all settings and their origin
git config --list --show-origin
# edit config files directly
git config --global --edit # ~/.gitconfig
git config --edit # repo .git/configリポジトリの作成とクローン
git init はバージョンデータをすべて格納する隠し .git ディレクトリを追加して空のリポジトリを作成します。git clone は完全な履歴を含むリモートリポジトリをコピーします。最新のスナップショットのみが必要な場合(CI ビルドなど)は --depth 1 でシャロークローンを使用します — ダウンロードサイズを劇的に削減します。--single-branch は無関係なブランチの取得を避けます。
# create a new repo from scratch in current dir
mkdir my-app && cd my-app
git init
# clone a remote repository
git clone https://github.com/user/repo.git
# clone into a specific folder name
git clone https://github.com/user/repo.git my-folder
# clone a single branch (saves bandwidth)
git clone -b dev --single-branch https://github.com/user/repo.git
# shallow clone: only the latest commit
git clone --depth 1 https://github.com/user/repo.gitエイリアスとショートカット
エイリアスは頻繁に使用するコマンドやコマンドシーケンスに短い名前を定義できます。gitconfig の [alias] セクションに保存されます。! で始まるエイリアスはシェルコマンドとして実行され、複雑なワークフローを可能にします。上記の lg エイリアスは、ブランチ構造を理解するのに非常に便利なコンパクトな視覚的履歴グラフを生成します。
# create shortcuts for common commands
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.lg "log --oneline --graph --all"
# now use them
git co main
git lg
# alias that runs an external command (starts with !)
git config --global alias.unstage "reset HEAD --"
git unstage file.txtヘルプとドキュメント
Git には包括的な組み込みドキュメントが付属しています。git help <コマンド> はページャで man ページを開きます。-h フラグはオプションの1画面の要約を表示します。ガイド(git help -g)にはチュートリアル、用語集、日常のワークフローリファレンスが含まれており — 用語を学ぶ初心者に最適です。
# open the full manual for a command
git help commit
git commit --help
# show a concise synopsis
git commit -h
# list all git commands
git help -a
# list all guides (tutorial, glossary, etc.)
git help -g
git help glossary.gitignore パターン
.gitignore は Git がバージョン管理から除外するファイルを指定します — ビルド成果物、依存関係、シークレットに不可欠です。パターンは glob 構文を使用し、末尾のスラッシュはディレクトリにマッチします。! を先頭に付けるとパターンを否定し、ファイルの追跡を強制します。.gitignore 自体はコミットしてチームで無視ルールを共有すべきです。既に追跡されているファイルは新しい無視パターンの影響を受けません — まず git rm --cached で削除してください。
# .gitignore file — patterns for files to skip
node_modules/
*.log
.env
.env.local
dist/
build/
# but track this specific file even if it matches
!important.log
# ignore all .txt files in build/ but not subdirs
build/*.txt
# ignore everything in a folder except one file
secrets/*
!secrets/template.envステージングとコミット
ステータスとステージング
Git は2段階モデルを使用します:変更はコミットされる前にステージングエリア(インデックス)に入ります。git status は変更、ステージ済み、未追跡を表示します。git add -p はパッチの個別ハンクをステージでき — 乱雑な作業ツリーを焦点を絞った論理的なコミットに分割するのに不可欠です。git restore --staged(モダンなコマンド)で編集を失わずにステージ解除できます。
# see current state of working tree
git status
git status -s # short format
git status -sb # short + branch info
# stage changes
git add file.txt # one file
git add src/ # a directory
git add . # all changes in repo
git add -p # stage interactively by hunk
# unstage a file (keep changes in working dir)
git restore --staged file.txt
git reset HEAD file.txt # older syntax変更のコミット
コミットはステージされた変更のスナップショットを記録します。メッセージは命令法で書きます('added feature' ではなく 'add feature')。-a フラグは既に追跡されているファイルのみをステージします — 新しいファイルには git add が必要です。--amend は最後のコミットを書き換えます。タイプミスの修正や忘れたファイルの追加に使用しますが、共有ブランチに既にプッシュしたコミットは決して修正しないでください。
# commit staged changes with a message
git commit -m "feat: add login form"
# multi-line commit message
git commit -m "feat: add login form" -m "Closes #42"
# stage tracked files AND commit in one step
git commit -am "fix: correct typo"
# amend the previous commit (keep message)
git commit --amend --no-edit
# amend and edit the message
git commit --amend -m "feat: add login form (v2)"コミットメッセージの規約
Conventional Commits は構造化されたコミットメッセージのために広く採用されている仕様です。タイププレフィックス(feat、fix、docs など)により、自動化された変更履歴生成とセマンティックバージョニングが可能になります。! マーカーは破壊的変更を示します。空行で件名(50文字以内)と本文を区切り、さらに空行で 'Closes #123' のようなフッターを区切ります。これは GitHub で自動的に issue をクローズします。
# Conventional Commits format
feat: add user registration endpoint
fix: resolve crash on empty cart
docs: update API reference
style: format login component
refactor: extract validation logic
test: add unit tests for parser
chore: upgrade dependencies
# with scope and breaking change marker
feat(api): add pagination to list endpoint
fix!: change default port (BREAKING CHANGE)
# with body and footer
feat: add dark mode
Implement theme toggle using CSS variables.
Closes #128log で履歴を表示
git log は履歴を探索する主要なツールです。--oneline --graph --all はブランチ構造を一目で理解するのに最も便利な組み合わせです。--author、日付範囲、--grep でメッセージ内容でフィルタできます。--stat はどのファイルが変更されたかと行数を表示し、--patch は各コミットの完全な diff を表示します。
# full history with details
git log
git log --oneline # one line per commit
git log --oneline --graph --all # visual branch graph
git log -n 5 # last 5 commits
# filter by author, date, or message
git log --author="Alice"
git log --since="2 weeks ago"
git log --grep="fix"
# show files changed in each commit
git log --stat
git log --patch # full diffsdiff と show
git diff はスナップショットを比較します — 引数なしだとインデックスに対する未ステージの変更を表示します。--staged はインデックスと HEAD を比較します。git show は単一コミットのメタデータとパッチを表示します。HEAD:path 構文でチェックアウトせずに任意のコミットの任意のファイルの内容を表示でき、古いバージョンの復元や履歴の調査に便利です。
# compare working tree, index, and commits
git diff # unstaged changes
git diff --staged # staged but uncommitted
git diff HEAD # all changes vs last commit
git diff main feature # compare two branches
git diff abc1234 def5678 # compare two commits
# inspect a single commit
git show HEAD # latest commit diff + metadata
git show abc1234
git show HEAD:file.txt # view a file at a given commitブランチとマージ
ブランチの作成と切り替え
Git のブランチはコミットへの軽量なポインタです — 作成はほぼ瞬時です。git switch(Git 2.23+)はブランチ変更のためのモダンで安全な checkout の代替で、checkout はファイルの復元に予約されています。-d は未マージのブランチの削除を拒否し(作業を保護)、-D は強制削除します。ブランチリストをクリーンに保つため、マージ後に必ずブランチを削除してください。
# list branches
git branch # local branches
git branch -a # local + remote
git branch -vv # with tracking info
# create and switch
git branch feature # create only
git checkout feature # switch to it
git checkout -b feature # create + switch (classic)
git switch -c feature # create + switch (modern)
# delete branches
git branch -d feature # safe delete (merged only)
git branch -D feature # force deleteブランチのマージ
ファストフォワードマージは、ターゲットに新しいコミットがない場合、ブランチポインタを単に前に移動します — 線形な履歴を生成します。--no-ff はマージコミットを強制し、ブランチが存在した事実を保存します(機能追跡に便利)。--squash はすべてのブランチコミットを1つのステージされた変更にまとめ、その後1回コミットします — main に統合する前にノイズの多い機能履歴を整理するのに最適です。
# merge feature into main
git checkout main
git merge feature
# fast-forward merge (default when possible)
# main just moves forward to feature's commit
# create a merge commit (preserves branch history)
git merge --no-ff feature -m "Merge feature branch"
# squash all feature commits into one
git merge --squash feature
git commit -m "feat: add feature (squashed)"
# abort a merge with conflicts
git merge --abortマージコンフリク トの解決
コンフリクトは同じ行が2つのブランチで異なる変更を受けた時に発生します。Git は両側を示すコンフリクトマーカー(<<<<<<<、=======、>>>>>>>)を挿入します。ファイルを望ましい最終状態に編集し、git add で解決済みとしてマークして解決します。マージを完了するにはコミットします。git mergetool は視覚的 diff ツールを起動します。圧倒された場合は、git merge --abort でマージ前の状態に戻れます。
# a conflict produces markers in the file
# <<<<<<< HEAD
# my changes (current branch)
# =======
# their changes (incoming branch)
# >>>>>>> feature
# edit the file to resolve, then:
git add resolved-file.txt
git commit # finalize the merge
# use a merge tool
git mergetool
# see which files conflict
git status
# abandon the merge
git merge --abortリベース
リベースはブランチのコミットを別のブランチの上にリプレイし、マージコミットのない線形な履歴を生成します。インタラクティブリベース(-i)はパワーツールです:squash はコミットをマージ、reword はメッセージを編集、drop はコミットを削除、edit はコミットを変更するために一時停止します。プッシュして共有したコミットは決してリベースしないでください — 履歴を書き換え、チームメイトのリポジトリを壊します。リベースは自分のローカルブランチでのみ使用してください。
# rebase feature onto main (replay feature commits)
git checkout feature
git rebase main
# interactive rebase — rewrite last 5 commits
git rebase -i HEAD~5
# options: pick, reword, squash, fixup, drop, edit
# continue, skip, or abort during a rebase
git rebase --continue
git rebase --skip
git rebase --abort
# rebase while pulling
git pull --rebase origin mainチェリーピックと reflog
チェリーピックは別のブランチの個別コミットを現在のブランチに適用します — ブランチ全体をマージせずにバグ修正をバックポートするのに便利です。reflog はすべての HEAD の移動(コミット、チェックアウト、リセット)を記録するローカルログで、約90日間保持されます。これはセーフティネットです:破壊的なリセットの後でも、reflog で古いコミットハッシュを見つけて復元できます。reflog データはローカルのみで、プッシュされません。
# apply a specific commit onto current branch
git cherry-pick abc1234
git cherry-pick abc1234 def5678 # multiple commits
git cherry-pick abc1234..def5678 # range (exclusive start)
# reflog: record of where HEAD has been
git reflog
git reflog show feature
# recover a 'lost' commit
git reset --hard HEAD@{2}
# view a branch's history of moves
git reflog show mainリモートリポジトリ
リモートの管理
リモートは別のリポジトリへの名前付き参照で、通常はフォークに origin、元のプロジェクトに upstream を使用します。git remote -v は fetch と push の URL を表示します。GitHub のフォークは upstream リモートを使用して元のリポジトリと同期します:upstream から fetch、merge または rebase、その後 origin に push します。set-url は HTTPS と SSH 認証の切り替えに便利です。
# list configured remotes
git remote -v
git remote show origin
# add a remote
git remote add origin https://github.com/user/repo.git
# add an upstream remote (for forks)
git remote add upstream https://github.com/original/repo.git
# rename or remove
git remote rename origin upstream
git remote remove origin
# change a remote URL (e.g. HTTPS to SSH)
git remote set-url origin [email protected]:user/repo.gitfetch、pull と push
fetch はリモートデータをダウンロードしますが、作業ツリーは変更しません — マージ前に安全に検査できます。pull = fetch + merge(--rebase で rebase)。新しいブランチの最初の push には -u が必要で、トラッキングを設定して以降の git push/pull が引数なしで動作するようにします。--force-with-lease は --force の安全な代替です:その間に他の人がプッシュしていない場合のみリモートを上書きし、チームメイトの作業の誤った上書 きを防ぎます。
# download remote changes without merging
git fetch origin
git fetch --all --prune # all remotes, drop deleted branches
# fetch + merge in one step
git pull
git pull --rebase # rebase instead of merge
# push local commits to remote
git push origin main
git push -u origin feature # push + set upstream tracking
git push # subsequent pushes (uses tracking)
# force push (rewrites remote history — DANGER)
git push --force-with-lease # safer than --forceトラッキングとブランチの同期
トラッキングブランチはローカルブランチをリモートブランチにリンクし、git pull と git push が fetch/push 先を指定なしで把握できるようにします。-u(--set-upstream-to の短縮形)が最初の push でこれを設定します。チームメイトがリモートブランチを削除すると、ローカルのリモートトラッキング参照が古くなります — git remote prune origin でクリーンアップします。git fetch --prune は fetch 中にこれを自動的に行います。
# set upstream for current branch
git branch -u origin/main
git branch --set-upstream-to=origin/main
# create a local branch tracking a remote one
git checkout -b feature origin/feature
git switch feature # auto-detects tracking branch
# delete a remote branch
git push origin --delete feature
# list all remote-tracking branches
git branch -r
git remote prune origin # remove stale remote refsプルリクエストのワークフロー
標準的な GitHub フロー:機能ブランチを作成、プッシュ、レビュー用のプルリクエストを開き、マージ後にブランチを削除します。フォークの場合、upstream リモートで元のリポジトリから変更をプルできます。フォークの main を定期的に upstream と同期しておくと、後の大規模で苦痛なマージを防げます。多くのチームはブランチリストを整理するために「マージ時に自動削除」を有効にしています。
# typical feature workflow
git checkout -b feature/login
# ... make changes, commit ...
git push -u origin feature/login
# create PR on GitHub, then after merge:
git checkout main
git pull origin main
git branch -d feature/login
# sync a fork with its upstream
git fetch upstream
git checkout main
git merge upstream/main
git push origin mainベアリポジトリとミラー
ベアリポジトリには作業ツリーがありません — .git データのみを保存します。ベアリポジトリはサーバー(セルフホスト Git など)で複数 人が push/pull する中央リモートとして使用されます。--mirror はリモートトラッキング参照を含むすべてをクローンし、バックアップやリポジトリのホスト間移行に使用されます。--all はすべてのブランチを、--tags はすべてのタグをプッシュします。
# create a bare repo (no working tree) — for servers
git init --bare project.git
# mirror clone (full copy including all refs)
git clone --mirror https://github.com/user/repo.git
# push all branches and tags
git push --all
git push --tags
# push a specific branch to a specific remote
git push origin local-name:remote-name変更の取り消し
reset:soft、mixed、hard
reset は現在のブランチポインタを移動します。--soft は変更をステージしたまま保持(コミットのみ取り消し)— 再コミットに理想的です。--mixed(デフォルト)はステージ解除しますが作業ツリーの変更は保持します。--hard はすべてを完全に破棄します — 唯一の復元手段は reflog です。共有履歴を書き換え、分岐を引き起こすため、プッシュしたコミットには決して --hard を使用しないでください。
# reset moves HEAD and optionally the index/worktree
git reset --soft HEAD~1 # undo commit, keep staged
git reset --mixed HEAD~1 # undo commit + unstage (DEFAULT)
git reset --hard HEAD~1 # undo commit + discard changes
# reset to a specific commit
git reset --hard abc1234
# reset a single file to HEAD
git reset HEAD file.txt # unstage
git checkout -- file.txt # discard working changesrevert(安全な取り消し)
reset(履歴を書き換える)とは異なり、revert は対象コミットを逆転する新しいコミットを追加します — 履歴が保存されるため共有ブランチに安全です。これは既にプッシュされた変更を取り消す正しい方法です。マージコミットの revert には -m 1 でどの親ラインを保持するかを指定する必要があります(1 = マージ先のブランチ)。
# revert creates a NEW commit that undoes another
git revert abc1234
git revert HEAD # undo last commit
# revert a range
git revert HEAD~3..HEAD
# revert without committing (stage the inverse)
git revert --no-commit abc1234
# revert a merge commit
git revert -m 1 abc1234 # -m 1 = keep main branch parentrestore と clean
git restore(Git 2.23+)は作業ツリー操作のためのモダンで焦点を絞ったコマンドで、checkout から懸念を分離します。--staged は作業変更に触れずにステージ解除します。git clean は未追跡フ ァイルを削除します — 常に最初に -n(ドライラン)で何が削除されるかをプレビューしてください。-x は積極的で、gitignore されたファイルも削除し、クリーンなビルドに便利ですが、シークレットやビルド成果物を消去する可能性があります。
# discard unstaged changes in a file
git restore file.txt
git checkout -- file.txt # older syntax
# unstage a file (keep working changes)
git restore --staged file.txt
# restore a file from a specific commit
git restore --source=abc1234 file.txt
# remove untracked files
git clean -n # dry run (preview)
git clean -fd # remove untracked files + dirs
git clean -fdx # also remove ignored filesamend と fixup
--amend は最後のコミットを書き換えます — タイプミスの修正や忘れたファイルの追加に便利ですが、プッシュしたコミットは決して修正しないでください。fixup ワークフローはエレガントです:小さな問題に気づいたら fixup コミットを作成し、git rebase -i --autosquash が自動的に並べ替えて対象コミットにスカッシュします。これにより履歴をクリーンに保ちながら、小さな修正を段階的にコミットできます。
# amend the last commit (message + content)
git add forgotten-file.txt
git commit --amend --no-edit
# change only the commit message
git commit --amend -m "better message"
# create a fixup commit (for later autosquash)
git commit --fixup=abc1234
# squash fixups during interactive rebase
git rebase -i --autosquash abc1234~1reflog による復元
reflog はセーフティネットです。コミット、チェックアウト、reset、rebase のすべてを記録します — コミットを「破壊」する操作も含みます。エントリは約90日間保持されます。誤って reset --hard したりブランチを削除した場合、reflog で孤立したコミットハッシュを見つけて reset するか、そのハッシュを指す新しいブランチを作成できます。reflog はローカルのみなので、オフラインでも機能します。
# reflog records every HEAD movement
git reflog
# abc1234 HEAD@{0}: reset: moving to abc1234
# def5678 HEAD@{1}: commit: feat: add x
# ghi9012 HEAD@{2}: checkout: moving to feature
# recover a 'lost' commit
git reset --hard def5678
# recover a deleted branch
git branch recovered-feature def5678
# reflog for a specific branch
git reflog show featureスタッシュとワークフロー
変更のスタッシュ
stash は未コミットの変更を退避し、クリーンなツリーでブランチを切り替えたり更新をプルできるようにします。apply はスタッシュをリストに保持(複数のブランチに適用したい場合に便利)し、pop は適用して削除します。スタッシュは stash@{N} で参照される LIFO スタックです。clear は慎重に使用してください — すべてのスタッシュを完全に破棄します。
# save uncommitted changes (reverts working tree to HEAD)
git stash
git stash push -m "wip: login form" # with a message
# list, show, apply
git stash list
git stash show -p stash@{0} # show diff
git stash apply # apply latest, keep stash
git stash pop # apply latest, drop stash
# apply a specific stash
git stash apply stash@{2}
# drop a stash
git stash drop stash@{0}
git stash clear # drop ALL stashes部分スタッシュと選択的スタッシュ
これらのフラグは何をスタッシュするかを細かく制御します。--keep-index は論理的なコミットをステージしたが、その変更のみをテストしたい場合に便利です — 残りをスタッシュし、テストを実行して pop します。-u は未追跡ファイルを含め(そうでなければ作業ツリーに残ります)。-p は git add -p と同様に特定のハンクを選択できます。
# stash only staged changes
git stash --staged
# stash only unstaged changes (keep staged)
git stash --keep-index
# stash interactively by hunk
git stash -p
# stash including untracked files
git stash -u
git stash --include-untracked
# stash everything (even ignored)
git stash -aスタッシュブランチと作成
git stash branch はスタッシュの元の親コミットで新しいブランチを作成し、そこにスタッシュを適用します — コンフリクトでスタッシュが現在のブランチにクリーンに適用できなくなった時に最適です。show -p でスタッシュをパッチファイルとしてエクスポートしてアーカイブや共有もできます。スタッシュはローカルでプッシ ュされないため、長期保存には使用しないでください。
# create a branch from a stash (great for conflicts)
git stash branch feature/wip stash@{0}
# create a commit from a stash without applying
git stash store -m "saved wip" stash@{0}
# apply a stash to a different branch
git checkout other-branch
git stash apply stash@{0}
# inspect stash contents
git stash show stash@{0} --stat
git stash show -p stash@{0} > patch.diffGit ワークフローモデル
GitHub Flow が最もシンプルです:1つの main ブランチ、PR 付きの機能ブランチ、マージ時にデプロイ — 継続的デプロイに理想的です。Git Flow(Vincent Driessen のモデル)は構造化されたリリース管理のために develop、release、hotfix ブランチを追加します — バージョン管理された製品に適しています。Trunk-Based Development は非常に短命なブランチを使用し、最大限の統合速度を求める高性能な DevOps チームに好まれます。
# GitHub Flow (simple, popular)
# main is always deployable; feature branches + PRs
git checkout -b feature/x
git push -u origin feature/x
# open PR, review, merge to main, deploy
# Git Flow (structured, with release branches)
# main: production releases
# develop: integration branch
# feature/*: features off develop
# release/*: release prep
# hotfix/*: urgent fixes off main
# Trunk-Based Development
# short-lived branches (1-2 days), frequent rebase on mainサブモジュール
サブモジュールは1つの Git リポジトリを別のリポジトリに埋め込みます — ライブラリを独立してバージョン管理しながらプロジェクト間で共有するのに便利です。親リポジトリはサブモジュールの特定コミットへのポインタを保存します。クローンはデフォルトでサブモジュールの内容を取得しません。--recurse-submodules で1ステップで取得します。サブモジュールは扱いにくい場合があります。よりシンプルな依存関係管理には、Git subtrees やパッケージマネージャーを検討してください。
# add another repo as a submodule
git submodule add https://github.com/user/lib.git libs/lib
# clone a repo with its submodules
git clone --recurse-submodules https://github.com/user/repo.git
# initialize submodules in an existing clone
git submodule update --init --recursive
# update submodules to their latest remote commit
git submodule update --remote
# record a submodule pointer change
git add libs/lib
git commit -m "chore: bump lib submodule"検査とデバッグ
blame と annotate
git blame(annotate とも呼ばれる)はファイルの各行のコミットと作成者を表示します — コードがなぜそのようになっているかを理解するために不可欠です。-L は行範囲に制限し、大きなファイルに便利です。-w は純粋な空白変更を無視し、-C は別のファイルから移動またはコピーされたコードを検出し、行が実際にどこから来たかのより正確な履歴を提供します。
# show who last changed each line
git blame file.txt
git blame -L 10,20 file.txt # only lines 10-20
git blame -e file.txt # show author email
git blame -w file.txt # ignore whitespace changes
git blame -C file.txt # detect moved lines across files
# GUI annotation in some editors
git gui blame file.txtbisect(二分探索バグ発見)
bisect は履歴を二分探索してバグを導入した正確なコミットを特定します。既知の good と bad コミットをマークし、Git が中間点をチェックアウトし、テストして good/bad をマークし、毎回範囲を半分にします。スクリプトがあれば、プロセス全体を完全に自動化できます — 大規模な履歴の回帰バグに大きな時間を節約します。
# find the commit that introduced a bug
git bisect start
git bisect bad # current commit is broken
git bisect good v1.0.0 # v1.0.0 was working
# Git checks out a midpoint; test it, then:
git bisect good # or git bisect bad
# automate with a script that exits non-zero on bug
git bisect start HEAD v1.0.0 -- npm test
# finish and return to original branch
git bisect reset
# view the bisect log
git bisect logコードと履歴の検索
git grep は作業ツリーの追跡ファイルを検索します — インデックスを使用するため grep -r より高速です。-S 'pickaxe' オプションは特定の文字列を追加または削除したコミットを見つけ、関数やバグがいつ導入されたかを追跡するのに非常に便利です。-G は似ていますが diff 内の任意の場所の正規表現にマッチします。--author や --since フィルタと組み合わせて、履歴内の任意の変更を特定できます。
# search working tree for a string
git grep "TODO"
git grep -n "TODO" -- "*.js"
git grep -i "error" src/
# search across all commits (history)
git log -S "functionName" --oneline # pickaxe: when added/removed
git log -G "functionName.*\(" --oneline # regex match in diffs
# search commit messages
git log --grep="fix.*login" --oneline
git log --author="Alice" --since="1 week ago"fsck とダングリングオブジェクト
git fsck(ファイルシステムチェック)はオブジェクトデータベースの整合性を検証し、ダングリングコミットを見つけられます — reflog が不十分な場合の復元に便利です。git gc はオブジェクトを再編成して圧縮しディスク容量を節約します。--prune=now は到達不能なオブジェクトを即座に削除します。Git は定期的に自動 gc を実行しますが、手動で実行すると大きなリポジトリを縮小できます。--aggressive は最大圧縮のためにデルタを再計算します。