Gitを使う上で知っておくと嬉しいかも Tips
166 Views
August 13, 26
スライド概要
2026年エンジニア新人研修の資料です。
サイボウズ株式会社の主に開発本部の資料を公開するアカウントです。
関連スライド
各ページのテキスト
Git 知っておくと便利かも Tips 2026 開運研修 2026 社外公開版 2026.05.08 社内公開 2026.07.21 更新 サイボウズ株式会社 開発本部 開発支援副本部 技術支援部 生産性向上副部 平木場 風太
自己紹介: 平木場 風太（ひらこば ふうた） 社内でのニックネームは「きばちゃん」 所属 開発本部 開発支援副本部 技術支援部 生産性向上副部 生産性向上副部 エンジニア兼マネージャー（副部長） 2020 年 4 月に新卒入社、生産性向上チーム配属 2024 年 10 月から生産性向上副部の副部長 出身: 鹿児島、宮崎 好きな 技術, サービス: CI/CD、GitHub、AWS 時代: 14~20世紀ヨーロッパ、幕末〜昭和日本 音楽: B’z, YUI, Mr.Children ゲーム: パラドゲー（EU5, Vic3, CK3） 仕事のアイコン SNS のアイコン GitHub: @korosuke613 Twitter: @shitimi_613 https://korosuke613.dev Git 知っておくと便利かも Tips 2026 2
はじめに 平木場が 6 年間業務をしてきた中でよく使う Git に関する知っておくと嬉しいかもしれない Tips を紹介します。Git を使 って何かしらの開発をしてきたくらいの人を対象にしています 本資料は Git v2.55.0 時点の情報に基づいています コンセプト 誰に：Git を使って開発をしている人 なんと言ってほしいか：こんな使い方・機能・設定があったんだ！有効活用していきたいぜ おねがい 今回紹介する Tips が全てのチーム・ケースにおいて常に有効に活用できるとは限らないです チームの開発にマッチするかどうか、チームの開発方針に反しない範囲で適切に活用ください 他メンバーに影響を与える行動をする際は、先にチーム内での合意形成を行いましょう。とりあえず周りの先輩社員に 相談してみるといいかも 何か間違ってる情報があれば教えてください Git 知っておくと便利かも Tips 2026 3
2025 年版との主な変更点 講義を分割: 「Git/GitHub Tips」→「Git Tips」と「GitHub Tips」の 2 講義に 本講義は Git Tips です。GitHub Tips は別講義をご覧ください 新セクション追加: 「AI エージェントとの協業 Tips」 git worktree の仕組み、Claude Code の --worktree フラグ、各 AI CLI の対応状況 コマンド紹介の拡充: git stash export/import （Git 2.51〜） 署名セクション更新: 2026/03 の Trivy サプライチェーン攻撃の事例を追加 データモデル図を刷新: gitdatamodel ベースの図に差し替え、blob/tree/commit/HEAD の関係を見やすく おまけ追加: この 1 年間の Git リリース履歴（2.50〜2.55） Git 知っておくと便利かも Tips 2026 4
目次 1. Gitのおさらい 3. 安全に Git を使う Tips 1. Git による開発の流れ例（GitHub Flow） 1. 💡 force push で他人のコミットをなかった 2. Git の内部構造 ことにするのを防ぐ 2. Git を使ったチーム開発 Tips 2. 💡 commit に署名してなりすましを防ぐ 1. 🔍 main ブランチの変更を取り入れたい 4. Git 操作高速化 Tips 2. 🔍 直近のコミットメッセージ変更＆差分追 1. 💨 status 高速化 加したい 2. 💨 clone 高速化 3. 🔍 コミット履歴を操作したい 3. 💨 高速化、効率化をいい感じにやってくれ 4. 🔍 merge / rebase が途中で止まった！ るコマンド 5. 🔍 作業中に pull や rebase を行う 5. AI エージェントとの協業 Tips 6. 🔍 git 操作を間違えた！ 1. 🤖 AI エージェントと同時に作業したい
Gitのおさらい
Git による開発の流れ例（GitHub Flow） ローカルリポジトリ リモートリポジトリ 1. git pull main A B C B C G origin/main 2. git switch -c feature 6. merge HEAD D 3. git add → 4. git commit E F (Pull Request) 5. git push E F origin/feature ワーキングディレクトリ （変更したファイル） Git 知っておくと便利かも Tips 2026 7
Git の内部構造 References コミットに名前を付けるポインタ HEAD refer symbolic ref Objects Branch Branch Tag feature main v1.0 イミュータブル。SHA ハッシュで識別 refer Commit refer parent a1b2c3d Commit refer object Tag Obj e5f6g7h tree v1.0 tree Tree Tree... (root) entry entry entry Blob Tree Blob README.md src/ main.js entry 💡 詳しくは gitdatamodel - Git’s core data model も参照 Index (Staging Area) ファイルパス + blob ID のリスト。git add / git commit で操作 Blob utils.js Reflogs 参照の変更履歴。ローカルのみ。git reflog で確認 Git 知っておくと便利かも Tips 2026 8
Git を使ったチーム開発 Tips
🔍 main ブランチの変更を取り入れたい チーム開発を行ってると知らない間にどんどんリモートにあるマージ先ブランチ（base branch）に新しいコミットが追 加されていく リモートにあるマージ先ブランチが進み差分が大きくなってくるとマージの際にコンフリクトが発生する可能性が高くな る feature-2 E E feature-2 D C D feature-1 C 1. feature-1 ブランチで作業中 B A B A feature-1 F main main 2. メンバーがマージ先ブランチ（main）に変更を入れた Git 知っておくと便利かも Tips 2026 10
作業ブランチに別ブランチの変更を取り入れるコマンド git merge git rebase git cherry-pick（あまり使わない＆使わないに越したことはないので割愛） Git 知っておくと便利かも Tips 2026 11
git merge $ git merge ＜branch＞ 指定したブランチのコミットを current ブランチに統合 指定したブランチとcurrentブランチのコミットを親に持つマージコミットを作成 Before Merge A B C main D E feature After Merge A B C D E main M feature マージコミットMは親コミット（parent）がC, Eであるという情報を持つ Git 知っておくと便利かも Tips 2026 12
git rebase $ git rebase ＜branch＞ 指定したブランチのコミットを current ブランチに統合 マージコミットは作成せず、履歴を直線的に保つ 指定ブランチからブランチを切り直して再度同じ内容をコミットするのと同じ 既存のコミットを再適用するため、コミットハッシュが変わる Before Rebase A B C main D E feature After Rebase A B C D' E' feature main と は と と同じ変更内容だが、新しいコミットハッシュを持つ D' E' D E Git 知っておくと便利かも Tips 2026 13
merge 、 rebase の使い分け 大前提として、チームで決めたルールに従う 自分で判断できる場合は、基本的にブランチに関わっているのが自分のみかどうかで判断すると良い 自分のみがコミットするブランチ、かつ、PR のレビュー依頼前 -> rebase 他者もコミットするブランチ、または、PR のレビュー依頼後 -> merge 理由 merge と rebase の大きな違いは、 「マージコミット作成の有無[1]」と「コミットハッシュ変更の有無」どうか コミットハッシュが変更されることはコミット履歴が変わることを意味する 他者も同じブランチで作業していたり、他人が PR にコメントを残したりしている場合、コミット履歴が変更されることは 避けるのが望ましい（もちろんチームで合意が取れていれば別） 他者にローカルリポジトリでのコンフリクト解消を強制させる可能性があるため PR へのコメントがどこに対してされたものなのかがわからなくなってしまうため 1. マージの場合、 --ff 、 --no-ff でマージコミット作成の有無が変わるが、ここでは割愛 ↩︎ Git 知っておくと便利かも Tips 2026 14
🔍 直近のコミットメッセージ変更＆差分追加したい 例えば コミットメッセージを誤ってコミットしてしまった場合 差分をステージング（ git add ）し忘れた場合 Git 知っておくと便利かも Tips 2026 15
git commit --amend $ git commit --amend 現在のコミット（＝ HEAD が指すコミット）に差分を追加し、コミットメッセージを変更する コマンドを実行するとエディタが立ち上がりコミットメッセージを編集できる コミットメッセージの変更に加え、差分の追加も行いたい場合は先に差分をステージング（ git add ）しておく $ git commit --amend --no-edit 現在のコミット（＝ HEAD が指すコミット）に差分を追加する コミットメッセージは変更しないため、エディタは起動しない 差分の追加のみを行いたい場合にスピーディーに実行できる Git 知っておくと便利かも Tips 2026 16
🔍 コミット履歴を操作したい コミット順を変更したい 直近じゃないコミットに新たに差分を加えたい 直近じゃないコミットのコミットメッセージを変更したい 直近じゃないコミットをなかったことにしたい Git 知っておくと便利かも Tips 2026 17
git rebase -i $ git rebase -i / --interactive ＜branch＞ # `-i` の代わりに `--interactive` でも可 指定したブランチのコミットを current ブランチに統合、に加え、current ブランチが持つコミットを編集する コミット履歴を整理・編集するための強力なツール 実行するとエディタが立ち上がり、インタラクティブにコミットを操作できる 便利なのでめちゃくちゃ使う Git 知っておくと便利かも Tips 2026 18
git rebase -i
実行例
＜command＞ ＜commit SHA＞ ＜commit message＞ という形式。この文字列を操作してコミットを操作する。
機能 を実装
修正
機能 のテストを追加
を更新
pick 2e07860
A
fixup eec4f44 typo
pick 4c088b1
A
pick f813dac README
# Rebase 7890123..3456789 onto 7890123 (4 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# u, update-ref <ref> = track a placeholder for the <ref> to be updated
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
Git 知っておくと便利かも Tips 2026 19
git rebase -i の操作方法（抜粋） : コミットをそのまま使用 reword : コミットを使用するが、コミットメッセージを変更 squash : コミットを使用するが、前のコミットに統合し、両方のコミットメッセージを編集 fixup : コミットを使用するが、前のコミットに統合し、選択したコミットのメッセージは破棄 edit : コミットで一時停止し、コミットを修正 drop or 行を削除: コミットを削除 行の順序を変更: コミット順を変更 # : コメント行 pick Git 知っておくと便利かも Tips 2026 20
git rebase -i ユースケース 色々なケースで使う。 コミット順を変更したい(順序入れ替え) 直近じゃないコミットに新たに差分を加えたい ( edit or 順序入れ替え -> fixup ) 直近じゃないコミットのコミットメッセージを変更したい ( reword ) 直近じゃないコミットをなかったことにしたい ( drop or 行を削除) Git 知っておくと便利かも Tips 2026 21
🔍 簡単に古いコミットを修正 ＜ ＞ $ git commit --fixup= commit hash $ git rebase -i --autosquash branch ＜ ＞ 古いコミット修正を楽に行うためのオプション[1] git commit --fixup=＜commit hash＞ で指定したコミットを編集するコミットを追加 fixup! ＜commit message＞ という形式のメッセージでコミットされる git rebase -i --autosquash で fixup! の付いたコミットを自動的に順序入れ替え＆ fixup コマンドを指定 コンフリクトに注意 1. fixup と autosquash の詳しい話は https://www.docswell.com/s/korosuke613/5XVNYZ-2022-08-04-fixup-autosquash-are-number-1 でも発表したよ ↩︎ Git 知っておくと便利かも Tips 2026 22
--fixup & --autosquash 実行例 # 現在の履歴 $ git commit --fixup=2e07860 [hoge f2e25ba] fixup! A 1 file changed, 1 insertions(+), 1 deletions(-) # 機能A に typo があったので修正 $ git log --oneline f2e25ba (HEAD -> hoge) fixup! f813dac README 4c088b1 A 2e07860 A # 修正のためのコミットが追加された # 自動でコミット順が入れ替わり、コマンドが `fixup` に変更された $ git log --oneline f813dac (HEAD -> hoge) README 4c088b1 A 2e07860 A ... 機能 のテストを追加 機能 を実装 を更新 機能 を実装 を更新 機能 のテストを追加 機能 を実装 機能Aを実装 # `git rebase -i --autosquash main` 機能 を実装 機能Aを実装 pick 4c088b1 機能Aのテストを追加 pick f813dac READMEを更新 pick 2e07860 A fixup f2e25ba fixup! を実行 エディタ操作を省略できるので特定コミットの修正を楽に行える。 Git 知っておくと便利かも Tips 2026 23
🔍 merge / rebase が途中で止まった！ merge や rebase を実行中にコンフリクトが発生した場合、以下のオプションを使う。 $ git merge --continue $ git merge --abort $ git rebase --continue $ git rebase --abort merge や rebase がコンフリクト等で中断された場合に使うオプション --continue : merge/rebase を再開 先にコンフリクトを解消し、対象ファイルをステージングしておくこと --abort : merge/rebase を中止して元に戻す めちゃよく使う。コンフリクトしない前提でコミット順を入れ替えたらコンフリクトしたみたいな想定外のコンフリク トが起きた時にとりあえず abort することが多い Git 知っておくと便利かも Tips 2026 24
🔍 作業中に pull や rebase を行う 追跡対象ファイルを編集中にリモートリポジトリ上で変更があり、pull や rebase を行いたい場合、ファイルを編集中であ ることが原因で pull, rebase ができない $ git status -s M hoge.txt $ git pull error: cannot pull with rebase: You have unstaged changes. error: Please commit or stash them. $ git rebase main error: cannot rebase: You have unstaged changes. error: Please commit or stash them. Git 知っておくと便利かも Tips 2026 25
git stash $ git stash 作業中の変更を一時的に退避させる ブランチの切り替えや、急なバグ修正などで便利 $ git stash pop 退避させた変更を作業ディレクトリに戻す スタックから最新の変更を取り出し、スタックから削除 Git 知っておくと便利かも Tips 2026 26
git stash 実行例 作業中の変更を一時的に退避 # $ git stash # main ブランチに切り替え $ git switch main ブランチの変更を取り込む # main $ git pull 作業ブランチに戻る（`-` で直前のブランチに移動） # $ git switch - 退避した変更を戻す # $ git stash pop Git 知っておくと便利かも Tips 2026 27
おまけ: git stash export/import （Git 2.51〜） Git 2.51 から、stash をリモートリポジトリ経由で共有できるようになった。 マシン をエクスポートして マシン してインポート # A: stash push $ git stash export --to-ref refs/stashes/my-work $ git push --force origin refs/stashes/my-work # B: fetch $ git fetch origin refs/stashes/my-work:refs/stashes/my-work $ git stash import refs/stashes/my-work 別マシンへの作業引き継ぎ、ペアプロでの状態共有などに便利 push した stash ref は自動削除されないので不要になったら手動で削除する GitHub でも利用可能（Web UI には表示されないが、push/fetch は可能） Git 知っておくと便利かも Tips 2026 28
🔍 git 操作を間違えた！ merge, rebase するブランチを誤ってしまい履歴がめちゃくちゃになった 間違ったブランチに変更をコミットしてしまった 誤ったコミットを force push してしまった git rebase -i で必要なコミットを削除してしまった こういった git 操作を誤って履歴がおかしくなってしまった場合、 git reflog や git reset を使ってリカバリーでき る（ことがある）。 Git 知っておくと便利かも Tips 2026 29
git reflog $ git reflog これまでのGit操作履歴とコミットIDを表示 HEADが移動するたびに記録される 誤ってforce pushやreset --hardしてしまった場合の救済に便利 使用例： $ git reflog 734713b HEAD@{0}: commit: Fix typo a735ec1 HEAD@{1}: pull origin main: Fast-forward 52c9646 HEAD@{2}: reset --hard HEAD~1 d27924e HEAD@{3}: commit: Add feature X Git 知っておくと便利かも Tips 2026 30
git reset $ git reset ＜commit＞ HEADの位置を指定したコミットに移動（–mixed がデフォルト） オプション --mixed : HEAD の位置を指定したコミットに移動、ステージングエリアをリセット、作業ディレクトリの変更は保 持（デフォルト） --soft : HEAD の位置を指定したコミットに移動、ステージングエリアは変更しない、作業ディレクトリの変更は保 --hard : HEAD の位置を指定したコミットに移動、ステージングエリアと作業ディレクトリも指定したコミットの状 持 態に戻す Git 知っておくと便利かも Tips 2026 31
具体例: git 操作をミスってコミットが行方不明になるケース 1. feature-1 ブランチを作成、作業（2回コミット） 2. main ブランチに変更が入った 3. feature-1 ブランチに main ブランチの変更を取り込むために git rebase main を実行 4. コンフリクトが発生したが、とても複雑だったため、コンフリクト解消は一度取りやめた( git rebase --abort ) 5. main ブランチからブランチを切り直すことにしたので、 git reset main を実行して、コミットのみを main ブランチ と同じ状態にしようとした 6. しかし、手が滑って git reset main --hard を行い、feature-1 ブランチで行っていた変更全てが失われてしまっ た… Git 知っておくと便利かも Tips 2026 32
具体例: コミットが消えた…？ 1. git reset main --hard 実行前 main 2. git reset main --hard 実行後 27 b8 5b 0 91 e2 39 d 27 b8 5b 0 91 e2 39 d main, feature-1 1d 56 bb 2 2e 4b 5c 8 feature-1 feature-1 ブランチにあったコミット（ 2e4b5c8 , 1d56bb2 ）が消えてしまった…？ 実はコミットは残っている！（短期間の間は[1]） 1. 孤立したコミット（orphaned commit）は git のガベージコレクションによってそのうち消える（デフォルトでは reflog 保持期間 90 日、到達不能なコミットは 30 日） ↩︎ Git 知っておくと便利かも Tips 2026 33
具体例: git reflog で過去の履歴を確認＆復元
1
2
3
4
5
6
7
8
9
10
$ git reflog
27b85b0 (HEAD -> feature-1, origin/main, origin/HEAD, main) HEAD@{0}: reset: moving to main
1d56bb2 HEAD@{1}: rebase (abort): returning to refs/heads/feature-1
27b85b0 (HEAD -> feature-1, origin/main, origin/HEAD, main) HEAD@{2}: rebase (start): checkout main
1d56bb2 HEAD@{3}: checkout: moving from main to feature-1
27b85b0 (HEAD -> feature-1, origin/main, origin/HEAD, main) HEAD@{4}: pull --rebase --set-upstream origin main: Fast-f
91e239d HEAD@{5}: checkout: moving from feature-1 to main
1d56bb2 HEAD@{6}: commit: feat: add perfect feature
2e4b5c8 HEAD@{7}: commit: feat: add super feature
91e239d HEAD@{8}: checkout: moving from main to feature-1
11
...
2 行目で問題の reset を行っている
8 行目で 2 つ目のコミット（ 1d56bb2 ）を行っている
消えてしまったコミット ID がわかったので git reset --hard 1d56bb2 [1] を実行すれば、元の状態に戻せる！[2]
1. git reset --hard HEAD@{6} でも可 ↩︎
2. 実際のところ今回のケースではコミットIDさえわかればいいので、reflogを使わなくてもなんとかなる。コミットID知りたいなら git fsck --lost-found も使えるが、reflog で操作履歴ごと
知れたほうがわかりやすいっちゃわかりやすい ↩︎
Git 知っておくと便利かも Tips 2026 34
安全に Git を使う Tips
💡 force push で他人のコミットをなかったことにするのを防ぐ git push --force はリモートブランチの他人の変更を無視してブランチを上書きしてしまう危険性がある[1]。 git push --force-with-lease 前回 git fetch した時点でローカルにキャッシュしているリモート追跡 ref ( refs/remotes/origin/<ブランチ 名> ) と、push 直前にサーバーが持つ実際の ref が一致している場合のみ force push git push --force-with-lease --force-if-includes リモートブランチの最新コミットがローカルブランチのreflogに含まれている場合のみ force push --force-with-lease と併用しないと無効になる[2] --force-with-lease のみでは、 git fetch を行うだけで force push ができてしまい不十分。 --force-ifincludes を併用することで force push のために git pull 等で最新のリモートの変更の取得が必要となり安全性が増す [3]。 1. わかりやすい記事: git push -f が更に安全になる --force-if-includes - id:onk のはてなブログ (https://onk.hatenablog.jp/entry/2022/12/18/000000) ↩︎ 2. https://git-scm.com/docs/git-push#Documentation/git-push.txt---no-force-if-includes ↩︎ 3. --force-if-includes は reflog にリモートの ref が含まれてるかどうかをチェックしているだけなので、pull 後に git reset --hard 等でリモートの最新コミットを吹き飛ばした場合 force push 可能であることに注意。 ↩︎ Git 知っておくと便利かも Tips 2026 36
💡 commit に署名してなりすましを防ぐ
コミットに署名することで、その committer のなりすましを防げる。事前に設定が必
要[1]。
$ git commit --gpg-sign -m "feat: super cool feature"
[hoge 606d6b0] feat: super cool feature
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 hoge.txt
$ git log -1 --show-signature
commit 606d6b0093e0671d97819c95f31a8b30399603c8 (HEAD -> hoge)
Good "git" signature for
with ED25519 key SHA256:eZvqeOd02bzO1Tz1pTv1m
Author: Futa HIRAKOBA <
>
Date:
Thu Apr 1 06:13:01 2025 +0900
ここにメアドが入る
ここにメアドが入る
feat: super cool feature!
平木場は SSH 鍵 + 1Password で署名時に
認証を挟むようにしているため、署名時に
1Password の認証が求められる。
1. 設定方法はいろいろあるので検索してください。 ↩︎
Git 知っておくと便利かも Tips 2026 37
署名の重要性を示す実例 2025〜2026 年にかけて、GitHub Actions のサプライチェーン攻撃が相次いで発生している。 tj-actions/changed-files 改ざん（2025/03）: 攻撃者が Renovate bot になりすましたコミットを追加し、CI ランナー のシークレットを窃取[1] Trivy サプライチェーン攻撃（2026/03）: 攻撃者がメンテナーになりすましたコミットを push し、75/76 のタグを悪意 あるバージョンに書き換え[2] 特に Trivy の事例では、攻撃者が既知のメンテナー（ DmitriyLewen ）のコミッター情報を偽装してコミットを追加した。 なりすましコミットは発見の遅れや原因調査の困難化を招く。 こういったなりすましを防ぐにはコミットの署名と verify ではないコミットを受け付けないようにする対策が有効。 1. https://unit42.paloaltonetworks.com/github-actions-supply-chain-attack/ ↩︎ 2. https://www.wiz.io/blog/trivy-compromised-teampcp-supply-chain-attack ↩︎ Git 知っておくと便利かも Tips 2026 38
GitHub は署名を検証してくれる GitHub では署名が verify かどうかを表示する機能と署名のないコミットのプッシュを拒否する機能がある。 Verified の文字 署名がない、検証に失敗したコミットには Unverified の文字 Verified の詳細 Git 知っておくと便利かも Tips 2026 39
GitHub の署名のないコミットを拒否する機能がある
Rulesets 機能で署名のないコミットを拒否するルールを追加できる。
拒否される例
$ git push #
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 12 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 278 bytes | 278.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
remote: error: GH013: Repository rule violations found for refs/heads/hoge.
remote: Review all repository rules at https://github.com/korosuke613/polybuckets/rules?ref=refs%2Fheads%2Fhoge
remote:
remote: - Commits must have verified signatures.
remote:
remote:
remote:
Found 1 violation:
606d6b0b775bc2715c38fecc4df5785b3f402491
remote:
To https://github.com/korosuke613/polybuckets.git
! [remote rejected] hoge -> hoge (push declined due to repository rule violations)
error: failed to push some refs to 'https://github.com/korosuke613/polybuckets.git'
Git 知っておくと便利かも Tips 2026 40
Git 操作高速化 Tips
大規模リポジトリでは git 操作が遅くなりがち 大規模リポジトリでは、履歴やオブジェクト（ファイルやコミットなど）の肥大化、大量の非追跡ファイルなどの影響で git 操作に関するパフォーマンスが低下することがある さまざまな設定を有効化することでパフォーマンス改善を図れる 今回は git status 、 git clone の高速化について紹介 Git 知っておくと便利かも Tips 2026 42
💨 status 高速化 git config --global core.untrackedCache true 非追跡ファイルのあるディレクトリの更新日時をキャッシュ ディレクトリの更新日時が変わっている場合のみ再スキャンすることで status を高速化 利点: 非追跡ファイル・ディレクトリが多い場合、status の高速化を見込める 欠点: mtime（最終更新日時）が正しく動作しないシステムでは予期しない動作の可能性 総評: 基本的に有効化しておいて損はない（と思う） git config --global core.fsmonitor true ファイルシステムを監視する常駐プロセスを起動し、変更のあったファイルをリストアップ git status 時に変更のあったファイルのみをスキャンすることで status を高速化 利点: 追跡ファイルが大量にある場合、status の高速化を見込める 欠点: プロセスを常駐させるため、システムリソースを消費する 総評: 常に大規模リポジトリで開発するような場合は有効化しておくといいかも Git 知っておくと便利かも Tips 2026 43
💨 clone 高速化 大規模リポジトリ、モノレポの場合、クローンに時間がかかったり、ディレクトリサイズが大きかったりする clone の方法を変えて高速化やサイズ削減が可能 shallow clone: 指定したコミット数分の履歴のみをクローン partial clone: 特定の Git オブジェクトのみをクローン sparse checkout: 特定のディレクトリのみをチェックアウト これらの方法は組み合わせて使うことも可能 個人の開発環境でも CI/CD でも使えるテクニック[1] 1. GitHub Actions の actions/checkout の場合、デフォルトは shallow clone ( --depth 1 ) するようになっている。履歴はほしいが blob はいらぬという場合は shallow clone をやめて partial clone するようにすると高速化が見込める ↩︎ Git 知っておくと便利かも Tips 2026 44
shallow clone git clone --depth 1 <repo> 指定したコミット数分の git objects のみをクローン 利点: clone速度が速い、リポジトリサイズが小さい 欠点: 過去のコミットを持たないため、本格的な開発には追加の履歴 取得が必要 総評: 大きなリポジトリの一時的な実験や動作確認、CI に便利。継続 的な開発には不向き https://github.blog/open-source/git/get-up-to-speed-with-partialclone-and-shallow-clone/より Git 知っておくと便利かも Tips 2026 45
partial clone git clone --filter blob:none <repo> 特定の Git オブジェクトのみをクローン。必要に応じてオンデマン ドで取得 例: blob:none ではtreeとcommitオブジェクトのみクローン[1] 利点: clone速度が速い、リポジトリサイズが小さい、過去コミット を保持 欠点: オフライン環境で別ブランチに切り替えると必要な blob がな いため開発できない 総評: 欠点が少なくバランスが良い。困る場面は少ない https://github.blog/open-source/git/get-up-to-speed-with-partialclone-and-shallow-clone/より 1. --filter=blob:none の場合は blobless clone、 --filter=tree:0 の場合は treeless clone と呼ばれることもある。 ↩︎ Git 知っておくと便利かも Tips 2026 46
sparse checkout git clone --sparse --no-checkout <repo> git sparse-checkout set <directory> 特定のディレクトリのみをチェックアウト 利点: clone速度が速い、リポジトリサイズを小さく保ちやすい、過 去コミットを保持 欠点: リポジトリ内依存関係を把握した上での利用が必要 総評: 特に大規模なモノレポで有効、自身の開発とは無関係のファイ ル数の多いリポジトリで真価を発揮 https://github.blog/open-source/git/bring-your-monorepo-downto-size-with-sparse-checkout/ より引用。 service/ 、 web/browser/ ディレクトリをチェックアウトの対象としている Git 知っておくと便利かも Tips 2026 47
💨 高速化、効率化をいい感じにやってくれるコマンド git maintenance リポジトリのメンテナンスを自動化するコマンド git maintenance start で git gc や git repack などのメンテナンスタスクがスケジューリングされる scalar コマンド Microsoft が開発した大規模 Git リポジトリの管理ツール 高速化や効率化のための git の設定を自動で有効化 git maintenance start コマンドも実行される さまざまな設定が有効化されるため、本当にその設定でいいのかの確認はした方がいい 詳しくはドキュメント[1]やソースコード[2]を見てね！ 1. https://git-scm.com/docs/git-maintenance, https://git-scm.com/docs/scalar ↩︎ 2. https://github.com/git/git/blob/v2.55.0/builtin/gc.c, https://github.com/git/git/blob/v2.55.0/scalar.c ↩︎ Git 知っておくと便利かも Tips 2026 48
scalar で有効化される設定例 通常の方法でクローンしたリポジトリと scalar でクローンしたリポジトリの設定（ git config --list --local ）を比較。 1 --- ../git_normal_settings.txt 2025-04-11 17:07:05 22 +gui.gcwarning=false 2 +++ ../git_scalar_settings.txt 2025-04-11 17:06:58 23 +index.skiphash=false 3 @@ -4,7 +4,39 @@ 24 +index.threads=true 4 core.logallrefupdates=true 25 +index.version=4 5 core.ignorecase=true 26 +merge.stat=false 6 core.precomposeunicode=true 27 +merge.renames=true 7 +core.fscache=true 28 +pack.usebitmaps=false 8 +core.multipackindex=true 29 +pack.usesparse=true 9 +core.preloadindex=true 30 +receive.autogc=false 10 +core.untrackedcache=true 31 +feature.manyfiles=false 11 +core.safecrlf=false 32 +feature.experimental=false 12 +core.fsmonitor=true 33 +fetch.unpacklimit=1 13 remote.origin.url=https://github.com/git/git.git 34 +fetch.writecommitgraph=false 14 remote.origin.fetch=+refs/heads/*:refs/remotes/origin/* 35 +fetch.showforcedupdates=false 15 +remote.origin.promisor=true 36 +status.aheadbehind=false 16 +remote.origin.partialclonefilter=blob:none 37 +commitgraph.generationversion=1 17 +extensions.worktreeconfig=true 38 +log.excludedecoration=refs/prefetch/* 18 +am.keepcr=true 39 branch.master.remote=origin 19 +credential.https://dev.azure.com.usehttppath=true 40 branch.master.merge=refs/heads/master 20 +credential.validate=false 41 +maintenance.auto=false 21 +gc.auto=0 42 +maintenance.strategy=incremental Git 知っておくと便利かも Tips 2026 49
AI エージェントとの協業 Tips
🤖 AI エージェントと同時に作業したい AI コーディングエージェント（Claude Code など）を使った開発が増えてきている AI にコードを書かせている間、自分も同じリポジトリで別の作業をしたい しかし同じディレクトリで同時に作業するとファイルの競合や上書きのリスクがある 同じディレクトリで作業 AI と人間がファイルを同時に編集 競合・上書きのリスク AI の作業中は手を出しにくい ディレクトリを分離して作業 AI と人間が別々のディレクトリで作業 互いに干渉しない 完了後にマージするだけ Git 知っておくと便利かも Tips 2026 51
git worktree $ git worktree add <path> <branch> 1 つのリポジトリから 複数の作業ディレクトリ を作成できる 各 worktree は独立したブランチをチェックアウトした状態になる .git オブジェクトは共有されるため、クローンし直すより高速・省ディスク 一覧表示 $ git worktree list # $ git worktree remove <path> # 削除 Git 知っておくと便利かも Tips 2026 52
git worktree 実行例 で作業中に、別ブランチの を作成 # feature-1 worktree $ git worktree add ../worktrees/hotfix hotfix/urgent-fix Preparing worktree (new branch 'hotfix/urgent-fix') HEAD is now at abc1234 feat: add new feature 現在の 一覧を確認 # worktree $ git worktree list /home/user/myrepo /home/user/worktrees/hotfix 別ターミナルで abc1234 [feature-1] abc1234 [hotfix/urgent-fix] に移動して作業 # worktree $ cd ../worktrees/hotfix $ vim src/app.ts $ git commit -am "fix: $ git push 緊急修正" 用が済んだら削除 # $ git worktree remove ../worktrees/hotfix 削除されたことを確認 # $ git worktree list /home/user/myrepo abc1234 [feature-1] Git 知っておくと便利かも Tips 2026 53
git worktree の注意点 worktree 自体は便利な機能だが、人間が手動で管理するのはちょっと難しい。 ディレクトリが散らかりやすい: リポジトリの外側にディレクトリを作るため、管理を怠ると把握しにくくなる 消し忘れ: 不要になった worktree を放置するとディスクを消費し続ける 同じブランチを複数の worktree でチェックアウトできない リポジトリ内にも作れてしまう: .gitignore 漏れでコミット対象や IDE の検索に巻き込まれるため、外側に作ることを 推奨 AI コーディングツール側で自動管理してくれる場合はこれらの心配は少ない。個人的には人間は触れずに、AI ツールが裏で を使ってくれるのが理想的。いくつかのツールは組み込みで対応している。 とはいえ、依然として人間の認知負荷を高めがちな機能であることは確かなので、基本的には並列作業を避けるほうが良いと 考える。 git worktree Git 知っておくと便利かも Tips 2026 54
git worktree × Claude Code Claude Code には --worktree （ -w ）フラグがあり、worktree の作成から削除まで自動で管理してくれる。 を作成して # worktree Claude Code ❯ claude --worktree issue-123 ▐▛███▜▌ ▝▜█████▛▘ ▘▘ ▝▝ を起動 Claude Code v2.1.92 Opus 4.6 (1M context) · Claude Team ~/<REPO_DIR>/.claude/worktrees/issue-123 ! pwd ⎿ <REPO_DIR>/.claude/worktrees/issue-123 ! git branch --show-current worktree-issue-123 ⎿ で、 .claude/worktrees/ ディレクトリの中に worktree-<name> という名前の worktree を自動で作成してくれる 変更がなければ終了時に自動で削除、変更があれば保持するか聞いてくれる 人間が git worktree コマンドを手動で打つ必要はない claude --worktree <name> Git 知っておくと便利かも Tips 2026 55
git worktree で終了。 × Claude Code に変更がある場合は削除するか聞いてくれる # Ctrl + C worktree ─────────────────────────────────────────────────────────────────────────────────── Exiting worktree session You have 1 uncommitted file. These will be lost if you remove the worktree. 1. Keep worktree ❯ 2. Remove worktree Stays at <REPO_DIR>/.claude/worktrees/test All changes and commits will be lost. Enter to confirm · Esc to cancel Resume this session with: claude --resume 7390ec50-d819-4bdc-acc7-ed5981d5da2f ❯ ls .claude/worktrees/issue-123 .claude/worktrees/issue-123: No such file or directory ❯ git show-ref --verify refs/heads/worktree-issue-123 fatal: 'refs/heads/worktree-issue-123' - not a valid ref セッション終了時、worktree に変更がある場合は削除するか聞いてくれる 削除を選ぶと worktree ディレクトリもブランチも両方消える Git 知っておくと便利かも Tips 2026 56
おわりに
まずはドキュメントを探そう よくわからない git のコマンドやオプションを見つけたらドキュメントを確認しよう。 公式ドキュメント: https://git-scm.com/docs Google 検索するときに git <コマンド名やオプション名> scm とか、 git <コマンド名やオプション名> site:gitscm.com とかで検索すると、すぐに辿り着ける Git の新機能を追うなら GitHub Blog の「Highlights from Git」シリーズもおすすめ。リリースごとの注目機能をわかり やすく解説してくれている それでもわからないときはソースコード (https://github.com/git/git) を見よう！（小声） Git を使って生産性の高い開発ライフを！ 別で用意している講義「GitHub 知ってると便利かも Tips 2026」もぜひミテネ。 Git 知っておくと便利かも Tips 2026 58
おまけ: 平木場が設定している Git のエイリアス集 gl: git log --oneline --graph gs: git status gaa: git add -A gcm: git commit -m gca: git commit --amend gcan: git commit --amend --no-edit gpl: git pull gps: git push gpsf: git push --force-if-includes --force-with-lease wip: git commit --fixup $(git log -1 --pretty=format:"%H" --grep="^fixup\!" --invert-grep) [1] 1. fixup! で始まらない直近のコミットに対して --fixup するエイリアス ↩︎ Git 知っておくと便利かも Tips 2026 59
おまけ: この 1 年間の Git リリース履歴 Git 2.50（2025/06）[1] ✨ 新機能: git maintenance に worktree-prune （不要 worktree 削除）、 rerere-gc （コンフリクト解消キャッシュの GC）、 reflog-expire （reflog の期限切れ処理）タスクが追加 ✨ 新機能: git reflog drop でブランチの reflog を削除可能に 💨 高速化: packfile の bitmap をインクリメンタル更新可能に（clone/fetch の高速化） 💨 高速化: マージエンジンが ORT に刷新され、大規模リポジトリでのマージが高速に Git 2.51（2025/08）[2] ✨ 新機能: git stash export / git stash import で stash をリモート経由で共有可能に ✨ 新機能: git repack --path-walk でパス単位にオブジェクトをグルーピングし packfile を縮小可能に 🎓 安定化: git switch / git restore が正式に安定版へ（6 年間の experimental 終了） 💨 高速化: 不要オブジェクトをインデックスから除外し、パック管理を効率化（サイズ 38% 削減） 1. https://github.com/git/git/blob/v2.50.0/Documentation/RelNotes/2.50.0.adoc , https://github.blog/open-source/git/highlights-from-git-2-50/ ↩︎ 2. https://github.com/git/git/blob/v2.51.0/Documentation/RelNotes/2.51.0.adoc , https://github.blog/open-source/git/highlights-from-git-2-51/ ↩︎ Git 知っておくと便利かも Tips 2026 60
おまけ: この 1 年間の Git リリース履歴（続き） Git 2.52（2025/11）[1] ✨ 新機能: git last-modified でディレクトリ内の最終変更コミットを高速取得（従来比 5.5 倍） ✨ 新機能: git maintenance に packfile を段階的に再編成する geometric タスクが追加 ✨ 新機能: git refs list / git refs exists で ref 操作を統合可能に ✨ 新機能: git sparse-checkout clean で不整合状態からの復旧可能に 🔮 Git 3.0 予告: デフォルトブランチ名の main 化、SHA-256 移行などが予告された Git 2.53（2026/02）[2] ✨ 新機能: git maintenance is-needed でメンテナンスの要否を判定可能に ✨ 新機能: git blame で diff アルゴリズムを指定可能に（ --diff-algorithm オプション） 📖 ドキュメント: Git のデータモデルを解説する新マニュアル gitdatamodel - Git’s core data model 追加[3] 1. https://github.com/git/git/blob/v2.52.0/Documentation/RelNotes/2.52.0.adoc , https://github.blog/open-source/git/highlights-from-git-2-52/ ↩︎ 2. https://github.com/git/git/blob/v2.53.0/Documentation/RelNotes/2.53.0.adoc ↩︎ 3. https://git-scm.com/docs/gitdatamodel ↩︎ Git 知っておくと便利かも Tips 2026 61
おまけ: この 1 年間の Git リリース履歴（続き）
Git 2.54（2026/04）[1]
✨ 新機能: git history reword / git history split で作業ツリーに触れずコミットメッセージ修正・分割が可能に（experimental）
✨ 新機能: git rebase --trailer "Reviewed-by: ..." でリベース対象コミットへ trailer を一括付与
✨ 新機能: config-based hooks 対応。設定ファイルでフックを定義でき、 git hook list で一覧可能に
💨 改善: git log -L が -S / -G （pickaxe 検索）と併用可能に
Git 2.55（2026/06）[2]
✨ 新機能: git history fixup でステージ済み変更を過去のコミットへ直接統合可能に（experimental）。fixup コミット + autosquash の手間を削減
✨ 新機能: config-based hooks が並列実行に対応（ hook.<name>.parallel ）。lint とテストなど独立したフックを同時実行可能に
💨 高速化: Linux でも core.fsmonitor が利用可能に（inotify ベース。macOS / Windows に続き対応）
💨 高速化: reachability bitmap の生成を最適化し、大規模リポジトリで約 50% 短縮
⚠️ 変更: Rust ビルドがデフォルト有効化。ソースビルド時に Rust がない環境ではビルド失敗に（フラグで無効化は可能。3.0 で完全必須化）
1. https://github.com/git/git/blob/v2.54.0/Documentation/RelNotes/2.54.0.adoc , https://github.blog/open-source/git/highlights-from-git-2-54/ ↩︎
2. https://github.com/git/git/blob/v2.55.0/Documentation/RelNotes/2.55.0.adoc , https://github.blog/open-source/git/highlights-from-git-2-55/ ↩︎
Git 知っておくと便利かも Tips 2026 62
おまけ: Git 3.0 で何が変わる？ Git の次期メジャーバージョン。リリース日は未定だが、破壊的変更がまとめて入る予定[1]。Git 2.52+ をソースから WITH_BREAKING_CHANGES フラ グ付きでビルドすると 3.0 の挙動を先行テストできる（Homebrew 等のパッケージでは不可）。 デフォルト値の変更 ハッシュ関数: SHA-1 → SHA-256 NIST が 2011 年に SHA-1 を非推奨化、2017 年に Google が衝突攻撃（SHAttered）を実証 新規リポジトリのデフォルトが SHA-256 に。既存の SHA-1 リポジトリはそのまま利用可能 SHA-1 ↔ SHA-256 の変換レイヤーを開発中 ref ストレージ: files → reftable 従来は 1 ref = 1 ファイル。大量ブランチでの走査が遅く、大文字小文字の衝突問題もあった reftable はバイナリ形式で ref を一括管理。高速検索・アトミックな複数 ref 更新が可能に デフォルトブランチ名: master → main init.defaultBranch 未設定時のデフォルトが master から main に変わる Git 2.28 から未設定時に警告が出ていた。すでに GitHub 等では main が広く採用されている その他（多くの人に影響はないと思う） コマンド廃止: git whatchanged 、 git pack-redundant 内部構造廃止: .git/branches/ 、 .git/remotes/ 、grafting commits Rust が必須に: Git 2.52 で自動検出・既定無効、2.55（2026/06）でデフォルト有効化。3.0 で完全必須化 1. https://git-scm.com/docs/BreakingChanges ↩︎ Git 知っておくと便利かも Tips 2026 63