Git/GitHub を使う上で知っておくと嬉しいかも Tips

Transcript

1. Git/GitHub 知っておくと便利かも Tips 開運研修 2025 社外公開版 2025.05.01 サイボウズ株式会社 開発本部 技術支援部 生産性向上チーム 平木場 風太
2. 自己紹介: 平木場 風太（ひらこば ふうた） 社内でのニックネームは「きばちゃん」 所属 開発本部 技術支援部 副部長 生産性向上チーム エンジニア兼マネージャー 2020 年 4 月にサイボウズ株式会社に新卒入社 出身: 鹿児島、宮崎 好きな 技術, サービス: CI/CD、GitHub、AWS 時代: 15~20世紀ヨーロッパ、幕末〜昭和日本 音楽: B’z, YUI, Mr.Children 漫画・アニメ: ガンダム（宇宙世紀） 、寄生獣、ゲッタ ーロボサーガ（石川賢） ゲーム: Victoria 3、Elden Ring、Kingdom Come: Deliverance 2、Civilization シリーズ 仕事のアイコン SNS のアイコン GitHub: @korosuke613 Twitter: @shitimi_613 https://korosuke613.dev Git/GitHub 知っておくと便利かも Tips 2
3. はじめに 平木場が 5 年間業務をしてきた中でよく使う Git/GitHub に関する知っておくと嬉しいかもしれない Tips を紹介します。 Git/GitHub を使って何かしらの開発をしてきたくらいの人を対象にしています コンセプト 誰に：Git、GitHub を使って開発をしている人 なんと言ってほしいか：こんな使い方・機能・設定があったんだ！有効活用していきたいぜ おねがい 今回紹介する Tips が全てのチーム・ケースにおいて常に有効に活用できるとは限らないです チームの開発にマッチするかどうか、チームの開発方針に反しない範囲で適切に活用ください 他メンバーに影響を与える行動をする際は、先にチーム内での合意形成を行いましょう。とりあえず周りの先輩社員に 相談してみるといいかも 何か間違ってる情報があれば教えてください Git/GitHub 知っておくと便利かも Tips 3
4. 目次 I 1. Gitのおさらい 1. Git による開発の流れ例（ざっくり） 2. Git の内部構造（ざっくり） 2. Git を使ったチーム開発 Tips 1. 🔍 main ブランチの変更を取り入れたい 2. 🔍 直近のコミットメッセージ変更＆差分追 加したい 3. 🔍 コミット履歴を操作したい 4. 🔍 merge / rebase が途中で止まった！ 5. 🔍 作業中に pull や rebase を行う 6. 🔍 git 操作を間違えた！ 3. 安全に Git を使う Tips 1. 💡 force push で他人のコミットをなかった ことにするのを防ぐ 2. 💡 commit に署名してなりすましを防ぐ 4. Git 操作高速化 Tips 1. 💨 status 高速化 2. 💨 clone 高速化 3. 💨 高速化、効率化をいい感じにやってくれ るコマンド
5. 目次 II 5. GitHubのおさらい 1. GitHub とは（ざっくり） 2. GitHub の機能群（ざっくり） 6. GitHub の知ってて損しない Tips 1. 🎓 GitHub の種類 2. 🎓 アカウントの種類とチーム 3. 🎓 可視性 (visibility) 7. GitHub でのガバナンス・セキュリティ向上 Tips 1. 💡 コードのオーナーを定義する 2. 💡 適切なロール（役割）を与える 3. 💡 ルールを定めてブランチ、タグ、プッシ ュを保護する 4. 💡 リポジトリのセキュリティ向上機能たち 8. GitHub での生産性向上 Tips 1. 💪 マージされたブランチを自動で削除 2. 💪 タスク番号を自動でハイパーリンク化 3. 💪 複数人で開発したことを明示的に表す 4. 💪 パーマリンクで不変なコードを共有する 5. 💪 コンソールや CI から GitHub を操作す る 9. おわりに 1. まずはドキュメントを探そう 2. おまけ: 平木場が設定している Git のエイリ アス集
6. Gitのおさらい
7. Git による開発の流れ例（ざっくり） リモートリポジトリ ローカルリポジトリ main A B C origin/main B C feature 1. git pull 2. git switch -c D E F HEAD 3. git add → 4. git commit 5. git push origin/feature E F 6. merge (Pull Request) G ワーキングディレクトリ （変更したファイル） Git/GitHub 知っておくと便利かも Tips 7
8. Git の内部構造（ざっくり） Commit SHA: a1b2c3... Tree (root) SHA: d4e5f6... Blob SHA: g7h8i9... （ファイル内容） Tree (sub) SHA: j0k1l2... Blob SHA: m3n4o5... （ファイル内容） Blob SHA: p6q7r8... README.md main.js utils.js src/ HEAD Branch (main) Branch (feature) Commit SHA: f9g0h1... 各オブジェクトはSHA-1 ハッシュで⼀意に識別される 現在の作業ブランチを指すポインタ 特定のコミットを指すポインタ Git/GitHub 知っておくと便利かも Tips 8
9. Git を使ったチーム開発 Tips
10. 🔍 main ブランチの変更を取り入れたい チーム開発を行ってると知らない間にどんどんリモートにあるマージ先ブランチ（base branch）に新しいコミットが追 加されていく リモートにあるマージ先ブランチが進み差分が大きくなってくるとマージの際にコンフリクトが発生する可能性が高くな る feature-2 main feature-1 A B C D E 1. feature-1 ブランチで作業中 feature-2 main feature-1 A B C D E F 2. メンバーがマージ先ブランチ（main）に変更を入れた Git/GitHub 知っておくと便利かも Tips 10
11. 作業ブランチに別ブランチの変更を取り入れるコマンド git merge git rebase git cherry-pick（あまり使わない＆使わないに越したことはないので割愛） Git/GitHub 知っておくと便利かも Tips 11
12. git merge 指定したブランチのコミットを current ブランチに統合 指定したブランチとcurrentブランチのコミットを親に持つマージコミットを作成 Before Merge A B C D E main feature After Merge A B C D E M main feature マージコミットM は親コミット（parent ）がC, E であるという情報を持つ $ git merge ＜branch ＞ Git/GitHub 知っておくと便利かも Tips 12
13. git rebase 指定したブランチのコミットを current ブランチに統合 マージコミットは作成せず、履歴を直線的に保つ 指定ブランチからブランチを切り直して再度同じ内容をコミットするのと同じ 既存のコミットを再適用するため、コミットハッシュが変わる Before Rebase A B C D E main feature After Rebase A B C D' E' feature main D' とE' はD とE と同じ変更内容だが、新しいコミットハッシュを持つ $ git rebase ＜branch ＞ Git/GitHub 知っておくと便利かも Tips 13
14. merge 、rebase の使い分け 大前提として、チームで決めたルールに従う 自分で判断できる場合は、基本的にブランチに関わっているのが自分のみかどうかで判断すると良い 自分のみがコミットするブランチ、かつ、PR のレビュー依頼前 -> rebase 他者もコミットするブランチ、または、PR のレビュー依頼後 -> merge 理由 merge と rebase の大きな違いは、 「マージコミット作成の有無 」と「コミットハッシュ変更の有無」どうか コミットハッシュが変更されることはコミット履歴が変わることを意味する 他者も同じブランチで作業していたり、他人が PR にコメントを残したりしている場合、コミット履歴が変更されることは 避けるのが望ましい（もちろんチームで合意が取れていれば別） 他者にローカルリポジトリでのコンフリクト解消を強制させる可能性があるため PR へのコメントがどこに対してされたものなのかがわからなくなってしまうため [1] 1. マージの場合、 --ff 、 --no-ff でマージコミット作成の有無が変わるが、ここでは割愛 ↩︎ Git/GitHub 知っておくと便利かも Tips 14
15. 🔍 直近のコミットメッセージ変更＆差分追加したい 例えば コミットメッセージを誤ってコミットしてしまった場合 差分をステージング（ git add ）し忘れた場合 Git/GitHub 知っておくと便利かも Tips 15
16. git commit --amend 現在のコミット（＝ HEAD が指すコミット）に差分を追加し、コミットメッセージを変更する コマンドを実行するとエディタが立ち上がりコミットメッセージを編集できる コミットメッセージの変更に加え、差分の追加も行いたい場合は先に差分をステージング（ git add ）しておく 現在のコミット（＝ HEAD が指すコミット）に差分を追加する コミットメッセージは変更しないため、エディタは起動しない 差分の追加のみを行いたい場合にスピーディーに実行できる $ git commit --amend $ git commit --amend --no-edit Git/GitHub 知っておくと便利かも Tips 16
17. 🔍 コミット履歴を操作したい コミット順を変更したい 直近じゃないコミットに新たに差分を加えたい 直近じゃないコミットのコミットメッセージを変更したい 直近じゃないコミットをなかったことにしたい Git/GitHub 知っておくと便利かも Tips 17
18. git rebase -i / --interactive 指定したブランチのコミットを current ブランチに統合、に加え、current ブランチが持つコミットを編集する コミット履歴を整理・編集するための強力なツール 実行するとエディタが立ち上がり、インタラクティブにコミットを操作できる 便利なのでめちゃくちゃ使う $ git rebase -i ＜branch ＞ # `-i` の代わりに `--interactive` でも可 Git/GitHub 知っておくと便利かも Tips 18
19. 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/GitHub 知っておくと便利かも Tips 19
20. git rebase -i の操作方法（抜粋） pick : コミットをそのまま使用 reword : コミットを使用するが、コミットメッセージを変更 squash : コミットを使用するが、前のコミットに統合し、両方のコミットメッセージを編集 fixup : コミットを使用するが、前のコミットに統合し、選択したコミットのメッセージは破棄 edit : コミットで一時停止し、コミットを修正 drop or 行を削除: コミットを削除 行の順序を変更: コミット順を変更 # : コメント行 Git/GitHub 知っておくと便利かも Tips 20
21. git rebase -i ユースケース 色々なケースで使う。 コミット順を変更したい(順序入れ替え) 直近じゃないコミットに新たに差分を加えたい ( edit or 順序入れ替え -> fixup ) 直近じゃないコミットのコミットメッセージを変更したい ( reword ) 直近じゃないコミットをなかったことにしたい ( drop or 行を削除) Git/GitHub 知っておくと便利かも Tips 21
22. 🔍 簡単に古いコミットを修正 古いコミット修正を楽に行うためのオプション git commit --fixup= ＜commit hash ＞ で指定したコミットを編集するコミットを追加 fixup! ＜commit message ＞ という形式のメッセージでコミットされる git rebase -i --autosquash で fixup! の付いたコミットを自動的に順序入れ替え＆ fixup コマンドを指定 コンフリクトに注意 $ git commit --fixup= ＜commit hash ＞ $ git rebase -i --autosquash ＜branch ＞ [1] 1. fixup と autosquash の詳しい話は https://www.docswell.com/s/korosuke613/5XVNYZ-2022-08-04-fixup-autosquash-are-number-1 でも発表したよ ↩︎ Git/GitHub 知っておくと便利かも Tips 22
23. -fixup & --autosquash 実行例 エディタ操作を省略できるので特定コミットの修正を楽に行える。 $ git log --oneline # 現在の履歴 f813dac (HEAD -> hoge) README を更新 4c088b1 機能A のテストを追加 2e07860 機能A を実装 ... $ git commit --fixup=2e07860 # 機能A に typo があったので修正 [hoge f2e25ba] fixup! 機能A を実装 1 file changed, 1 insertions(+), 1 deletions(-) $ git log --oneline # 修正のためのコミットが追加された f2e25ba (HEAD -> hoge) fixup! 機能A を実装 f813dac README を更新 4c088b1 機能A のテストを追加 2e07860 機能A を実装 # `git rebase -i --autosquash main` を実行 pick 2e07860 機能A を実装 fixup f2e25ba fixup! 機能A を実装 # 自動でコミット順が入れ替わり、コマンドが `fixup` に変更された pick 4c088b1 機能A のテストを追加 pick f813dac README を更新 Git/GitHub 知っておくと便利かも Tips 23
24. 🔍 merge / rebase が途中で止まった！ merge や rebase を実行中にコンフリクトが発生した場合、以下のオプションを使う。 merge や rebase がコンフリクト等で中断された場合に使うオプション --continue : merge/rebase を再開 先にコンフリクトを解消し、対象ファイルをステージングしておくこと --abort : merge/rebase を中止して元に戻す めちゃよく使う。コンフリクトしない前提でコミット順を入れ替えたらコンフリクトしたみたいな想定外のコンフリク トが起きた時にとりあえず abort することが多い $ git merge --continue $ git merge --abort $ git rebase --continue $ git rebase --abort Git/GitHub 知っておくと便利かも Tips 24
25. 🔍 作業中に 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/GitHub 知っておくと便利かも Tips 25
26. git stash 作業中の変更を一時的に退避させる ブランチの切り替えや、急なバグ修正などで便利 退避させた変更を作業ディレクトリに戻す スタックから最新の変更を取り出し、スタックから削除 $ git stash $ git stash pop Git/GitHub 知っておくと便利かも Tips 26
27. git stash 実行例 # 作業中の変更を一時的に退避 $ git stash # main ブランチに切り替え $ git switch main # main ブランチの変更を取り込む $ git pull # 作業ブランチに戻る（`-` で直前のブランチに移動） $ git switch - # 退避した変更を戻す $ git stash pop Git/GitHub 知っておくと便利かも Tips 27
28. 🔍 git 操作を間違えた！ merge, rebase するブランチを誤ってしまい履歴がめちゃくちゃになった 間違ったブランチに変更をコミットしてしまった 誤ったコミットを force push してしまった git rebase -i で必要なコミットを削除してしまった こういった git 操作を誤って履歴がおかしくなってしまった場合、 git reflog や git reset を使ってリカバリーでき る（ことがある） 。 Git/GitHub 知っておくと便利かも Tips 28
29. git reflog これまでのGit操作履歴とコミットIDを表示 HEADが移動するたびに記録される 誤ってforce pushやreset --hardしてしまった場合の救済に便利 使用例： $ git reflog $ 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/GitHub 知っておくと便利かも Tips 29
30. git reset HEADの位置を指定したコミットに移動（–mixed がデフォルト） オプション --mixed : HEAD の位置を指定したコミットに移動、ステージングエリアは変更しない、作業ディレクトリの変更は 保持（デフォルト） --soft : HEAD の位置を指定したコミットに移動、ステージングエリアは変更しない、作業ディレクトリの変更は保 持 --hard : HEAD の位置を指定したコミットに移動、ステージングエリアと作業ディレクトリも指定したコミットの状 態に戻す $ git reset ＜commit ＞ Git/GitHub 知っておくと便利かも Tips 30
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/GitHub 知っておくと便利かも Tips 31
32. 具体例: コミットが消えた…？ 1. git reset main --hard 実行前 main feature-1 91e239d 2e4b5c8 1d56bb2 27b85b0 2. git reset main --hard 実行後 main, feature-1 91e239d 27b85b0 feature-1 ブランチにあったコミット（ 2e4b5c8 , 1d56bb2 ）が消えてしまった…？ 実はコミットは残っている！（短期間の間は ） [1] 1. 孤立したコミット（orphaned commit）は git のガベージコレクションによってそのうち消える ↩︎ Git/GitHub 知っておくと便利かも Tips 32
33. 具体例: git reflog で過去の履歴を確認＆復元 2 行目で問題の reset を行っている 8 行目で 2 つ目のコミット（ 1d56bb2 ）を行っている 消えてしまったコミット ID がわかったので git reset --hard 1d56bb2 を実行すれば、元の状態に戻せる！ 1 $ git reflog 2 27b85b0 (HEAD -> feature-1, origin/main, origin/HEAD, main) HEAD@{0}: reset: moving to main 3 1d56bb2 HEAD@{1}: rebase (abort): returning to refs/heads/feature-1 4 27b85b0 (HEAD -> feature-1, origin/main, origin/HEAD, main) HEAD@{2}: rebase (start): checkout main 5 1d56bb2 HEAD@{3}: checkout: moving from main to feature-1 6 27b85b0 (HEAD -> feature-1, origin/main, origin/HEAD, main) HEAD@{4}: pull --rebase --set-upstream origin main: Fast-f 7 91e239d HEAD@{5}: checkout: moving from feature-1 to main 8 1d56bb2 HEAD@{6}: commit: feat: add perfect feature 9 2e4b5c8 HEAD@{7}: commit: feat: add super feature 10 91e239d HEAD@{8}: checkout: moving from main to feature-1 11 ... [1] [2] 1. git reset --hard HEAD@{6} でも可 ↩︎ 2. 実際のところ今回のケースではコミットIDさえわかればいいので、reflogを使わなくてもなんとかなる。コミットID知りたいなら git fsck --lost-found も使えるが、reflog で操作履歴ごと 知れたほうがわかりやすいっちゃわかりやすい ↩︎ Git/GitHub 知っておくと便利かも Tips 33
34. 安全に Git を使う Tips
35. 💡 force push で他人のコミットをなかったことにするのを防ぐ git push --force はリモートブランチの他人の変更を無視してブランチを上書きしてしまう危険性がある 。 git push --force-with-lease リモート ref ( remotes/origin/< ブランチ名> ) とローカル ref ( origin/< ブランチ名> ) が一致している場合のみ force push git push --force-with-lease --force-if-includes リモートブランチの最新コミットがローカルブランチのreflogに含まれている場合のみ force push --force-with-lease と併用しないと無効になる --force-with-lease のみでは、 git fetch を行うだけで force push ができてしまい不十分。 --force-if- includes を併用することで force push のために git pull 等で最新のリモートの変更の取得が必要となり安全性が増す 。 [1] [2] [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/GitHub 知っておくと便利かも Tips 35
36. 💡 commit に署名してなりすましを防ぐ コミットに署名することで、その committer のなりすましを防げる。事前に設定が必 要 。 平木場は SSH 鍵 + 1Password で署名時に 認証を挟むようにしているため、署名時に 1Password の認証が求められる。 [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! 1. 設定方法はいろいろあるので検索してください。 ↩︎ Git/GitHub 知っておくと便利かも Tips 36
37. 署名に関するタイムリーな話 最近あった tj-actions/changed-files などのアクションが改ざんされた件のレポート記事。 GitHub Actions Supply Chain Attack: A Targeted Attack on Coinbase Expanded to the Widespread tj- actions/changed-files Incident: Threat Assessment (Updated 4/2) https://unit42.paloaltonetworks.com/github-actions-supply-chain-attack/ 攻撃者は悪意のあるコミットを行う際に Renovate になりすましてコミットを追加したことが報告されている。 The attacker was able to add the malicious commit (0e58ed8) to the repository by using a GitHub token with write permissions that they obtained previously. The attacker disguised the commit to look as if it was created by renovate[bot] — a legitimate user. コミッターのなりすましは攻撃の発見が遅れる原因となるとともに、原因調査を難しくする。 こういったなりすましを防ぐにはコミットの署名と verify ではないコミットを受け付けないようにする対策が有効。 Git/GitHub 知っておくと便利かも Tips 37
38. GitHub は署名を検証してくれる GitHub では署名が verify かどうかを表示する機能と署名のないコミットのプッシュを拒否する機能がある。 Verified の文字 署名がない、検証に失敗したコミットには Unverified の文字 Verified の詳細 Git/GitHub 知っておくと便利かも Tips 38
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: Found 1 violation: remote: remote: 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/GitHub 知っておくと便利かも Tips 39
40. Git 操作高速化 Tips
41. 大規模リポジトリでは git 操作が遅くなりがち 大規模リポジトリでは、履歴やオブジェクト（ファイルやコミットなど）の肥大化、大量の非追跡ファイルなどの影響で git 操作に関するパフォーマンスが低下することがある さまざまな設定を有効化することでパフォーマンス改善を図れる 今回は git status 、 git clone の高速化について紹介 Git/GitHub 知っておくと便利かも Tips 41
42. 💨 status 高速化 非追跡ファイルのあるディレクトリの更新日時をキャッシュ ディレクトリの更新日時が変わっている場合のみ再スキャンすることで status を高速化 利点: 非追跡ファイル・ディレクトリが多い場合、status の高速化を見込める 欠点: mtime（最終更新日時）が正しく動作しないシステムでは予期しない動作の可能性 総評: 基本的に有効化しておいて損はない（と思う） ファイルシステムを監視する常駐プロセスを起動し、変更のあったファイルをリストアップ git status 時に変更のあったファイルのみをスキャンすることで status を高速化 利点: 追跡ファイルが大量にある場合、status の高速化を見込める 欠点: プロセスを常駐させるため、システムリソースを消費する 総評: 常に大規模リポジトリで開発するような場合は有効化しておくといいかも git config --global core.untrackedCache true git config --global core.fsmonitor true Git/GitHub 知っておくと便利かも Tips 42
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/GitHub 知っておくと便利かも Tips 43
44. shallow clone 指定したコミット数分の git objects のみをクローン 利点: clone速度が速い、リポジトリサイズが小さい 欠点: 過去のコミットを持たないため、本格的な開発には追加の履歴 取得が必要 総評: 大きなリポジトリの一時的な実験や動作確認、CI に便利。継続 的な開発には不向き https://github.blog/open-source/git/get-up-to-speed-with-partial- clone-and-shallow-clone/より git clone --depth 1 <repo> Git/GitHub 知っておくと便利かも Tips 44
45. partial clone 特定の Git オブジェクトのみをクローン。必要に応じてオンデマン ドで取得 例: blob:none ではtreeとcommitオブジェクトのみクローン 利点: clone速度が速い、リポジトリサイズが小さい、過去コミット を保持 欠点: オフライン環境で別ブランチに切り替えると必要な blob がな いため開発できない 総評: 欠点が少なくバランスが良い。困る場面は少ない https://github.blog/open-source/git/get-up-to-speed-with-partial- clone-and-shallow-clone/より git clone --filter blob:none <repo> [1] 1. --filter=blob:none の場合は blobless clone、 --filter=tree:0 の場合は treeless clone と呼ばれることもある。 ↩︎ Git/GitHub 知っておくと便利かも Tips 45
46. sparse checkout 特定のディレクトリのみをチェックアウト 利点: clone速度が速い、リポジトリサイズを小さく保ちやすい、過 去コミットを保持 欠点: リポジトリ内依存関係を把握した上での利用が必要 総評: 特に大規模なモノレポで有効、自身の開発とは無関係のファイ ル数の多いリポジトリで真価を発揮 https://github.blog/open-source/git/bring-your-monorepo-down- to-size-with-sparse-checkout/ より引用。 service/ 、 web/browser/ ディレクトリをチェックアウトの対象としている git clone --sparse --no-checkout <repo> git sparse-checkout set <directory> Git/GitHub 知っておくと便利かも Tips 46
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.49.0/builtin/gc.c, https://github.com/git/git/blob/v2.49.0/scalar.c ↩︎ Git/GitHub 知っておくと便利かも Tips 47
48. scalar で有効化される設定例 通常の方法でクローンしたリポジトリと scalar でクローンしたリポジトリの設定（ git config --list --local ）を比較。 1 --- ../git_normal_settings.txt 2025-04-11 17:07:05 2 +++ ../git_scalar_settings.txt 2025-04-11 17:06:58 3 @@ -4,7 +4,39 @@ 4 core.logallrefupdates=true 5 core.ignorecase=true 6 core.precomposeunicode=true 7 +core.fscache=true 8 +core.multipackindex=true 9 +core.preloadindex=true 10 +core.untrackedcache=true 11 +core.safecrlf=false 12 +core.fsmonitor=true 13 remote.origin.url=https://github.com/git/git.git 14 remote.origin.fetch=+refs/heads/*:refs/remotes/origin/* 15 +remote.origin.promisor=true 16 +remote.origin.partialclonefilter=blob:none 17 +extensions.worktreeconfig=true 18 +am.keepcr=true 19 +credential.https://dev.azure.com.usehttppath=true 20 +credential.validate=false 21 +gc.auto=0 22 +gui.gcwarning=false 23 +index.skiphash=false 24 +index.threads=true 25 +index.version=4 26 +merge.stat=false 27 +merge.renames=true 28 +pack.usebitmaps=false 29 +pack.usesparse=true 30 +receive.autogc=false 31 +feature.manyfiles=false 32 +feature.experimental=false 33 +fetch.unpacklimit=1 34 +fetch.writecommitgraph=false 35 +fetch.showforcedupdates=false 36 +status.aheadbehind=false 37 +commitgraph.generationversion=1 38 +log.excludedecoration=refs/prefetch/* 39 branch.master.remote=origin 40 branch.master.merge=refs/heads/master 41 +maintenance.auto=false 42 +maintenance.strategy=incremental Git/GitHub 知っておくと便利かも Tips 48
49. GitHubのおさらい
50. GitHub とは（ざっくり） 曰く、Build and ship software on a single, collaborative platform 噛み砕いて言うと、ソフトウェア開発とリリ ースまでを、複数人で一緒に進められるオー ルインワンなプラットフォーム 元々 Git 関係の機能しかなかったが、だんだ ん CI/CD やアーティファクトリポジトリ、リ モート開発環境などの機能が追加され、ソフ トウェア開発・運用における開発部分を GitHub 上で完結できるようになってきた https://github.com より Git/GitHub 知っておくと便利かも Tips 50
51. GitHub の機能群（ざっくり） C ode Plan Test R elease O perate Build M onitor D eploy Dev Ops Sec 🌴 Git server 📝 Issues 🙏 Pull requests 🗣 Discussions 📊 Projects Copilot 💻 Codespaces Copilot ⚙ Actions ⚙ Actions ⚙ Actions ⚙ Actions 📦 Packages ✨ Releases 📜 Pages 🤖 Dependabot Copilot 🆘 Code scanning 🔑 Secret scanning GitHub Interface 🌏 Web 📱 Mobile ◼ CLI 🖥 Desktop 📠 API Git/GitHub 知っておくと便利かも Tips 51
52. GitHub の知ってて損しない Tips
53. 🎓 GitHub の種類 クラウド版（github.com のこと ） Free（個人向け無料） Pro（個人向け有料） Team（組織向け有料） Enterprise（大規模組織向け有料） GitHub Enterprise Cloud を略して俗に GHEC と呼ばれていたりする オンプレ版（任意ドメインのものは大体オンプレ版） オンプレ版は自社サーバーでの運用が可能 GitHub Enterprise Server を略して俗に GHES と呼ばれていたりする [1] 1. 実はちょっと前に顧客専用 GHEC（ <customer>.ghe.com ）が GA になった（EU、オーストラリア限定） 。気になる人は「GitHub Enterprise Cloud with data residency」で検索 ↩︎ Git/GitHub 知っておくと便利かも Tips 53
54. 🎓 アカウントの種類とチーム User accounts 個人を表すアカウント Repository を所有、管理できる Organization accounts 組織を表すアカウント Repository、Team を所有、管理できる Team Organization 所属 User を束ねるグループ 効率の良いレビュワーや権限の指定を実現する Enterprise 複数の Organization を束ねる組織を表すアカウント Organization を所有、管理できる Repository User Organization Enterprise Team 所属する 0..* 1..* 所属する 1..* 0..1 所有する 1 0..* 所有する 0..* 1 所有する 0..* 1 所属する 0..* 0..* クラス図で表すとこんな感じ [1] 1. Enterprise Managed Users という Enterprise 専用 User も存在するが割愛 ↩︎ Git/GitHub 知っておくと便利かも Tips 54
55. 🎓 可視性 (visibility) GitHubのリポジトリには3つの可視性がある。 Public 全世界に公開。誰でもアクセス可能 OSS くらいでしか使わない Private 権限のあるユーザーのみアクセス可能 他の社員にも公開できないようなリポジトリの場合に使う Internal 権限のあるユーザー、および、同一 enterprise のユーザーはアクセス可能 特段理由がなければ Internal を選ぶのが無難 Git/GitHub 知っておくと便利かも Tips 55
56. GitHub でのガバナンス・セキュリティ向 上 Tips
57. ガバナンスを高める GitHub にはガバナンスを高める機能がある ガバナンスを高めることは人手によるミスを減らすとともに万が一何らかの攻撃を受けた場合の攻撃者の行動を制限する ことにもつながる 以下のような機能がある CODEOWNERS ( .github/CODEOWNERS ) 特定のファイルやディレクトリに対する責任者を指定することでレビュワーを自動的に指定する Roles, Custom roles Organization や Enterprise のメンバーに対して細かい権限を設定することができる Organization、Enterprise で設定可能 Rulesets ブランチ保護、タグ保護、プッシュ保護 Git/GitHub 知っておくと便利かも Tips 57
58. 💡 コードのオーナーを定義する CODEOWNERS ( .github/CODEOWNERS ) リポジトリ内のコードに対するオーナーを定義するファイル プルリクエストが作成された際に定義に応じたレビュワーが自動でアサインされる レビュワーとしての設定は可能だが、そのままだと承認されなくてもマージ可能。マージに承認を必要としたいのであれ ば後述の Rulesets と組み合わせる .github/CODEOWNERS の例（※ 登場する固有名詞、設定内容は全て架空のものです） # どのパターンにもマッチしない場合は @cybozu/product-owners チームをレビュワーにアサインする * @cybozu/product-owners # コンポーネントごとにそれぞれのチームをレビュワーにアサインする /frontend/ @cybozu/frontend-team /backend/ @cybozu/backend-team # CODEOWNERS の変更は社長をレビュワーにアサインする /.github/CODEOWNERS @cybozu-ceo Git/GitHub 知っておくと便利かも Tips 58
59. 💡 適切なロール（役割）を与える GitHub 上でできる権限をまとめたロール（役割）が定義されている。ロールは User や Team に対して付与できる Repository roles Read : リポジトリを読む人向け Triage : Issue や PR の優先順位やカテゴリ分けを決める人向け Write : リポジトリのコードを変更する人向け Maintain : リポジトリのメンテナ向け（ Write と Admin の中間） Admin : リポジトリの管理者向け Organization roles All-repository * : Repository roles を全てのリポジトリに対して適用するロール CI/CD Admin : Organization 上の GitHub Actions に関する管理やメトリクスの取得を行う人向け Security Manager : Organization やリポジトリに対するセキュリティ機能のレビュー、管理を行う人向け [1] [2] 1. 詳しくは https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository- roles-for-an-organization ↩︎ 2. 詳しくは https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization ↩︎ Git/GitHub 知っておくと便利かも Tips 59
60. ロールをカスタムする Roles を付与することで、特定の役割の人に必要な権限のみを付与できるが、定義済みのロールだと権限が大きすぎること がある。そういう時は Custom roles という機能を使えば任意の権限を付与したロールが作れる 例 シナリオ：GitHub Actions のジョブ・ワークフローの無駄を見つけ改善案を提案する仕事をすることになった A さ ん。Actions には利用状況をダッシュボード的に確認する機能があるが、リポジトリ横断で確認するには Organization Owner であるかもしくは CI/CD Admin ロールが必要。でも Owner の持つ権限も CI/CD Admin ロールの持つ権限 も強すぎて懸念が多い… 解決例：A さんをメンバーに招待した上で GitHub Actions の Usage metrics、Performance metrics の閲覧権限 （ View organization Actions usage metrics ）を持つカスタムロールを作成し、A さんに付与する Git/GitHub 知っておくと便利かも Tips 60
61. 💡 ルールを定めてブランチ、タグ、プッシュを保護する Rulesets ブランチやタグに対して保護ルールを設定することで、特定の操作を制限できる ブランチの保護設定（branch ruleset） 直接 push の禁止、レビュー必須化、署名コミット要求、CI パス必須化、etc… タグの保護設定（tag ruleset） 作成、削除制限、命名パターン、etc… プッシュの保護設定（push ruleset） プッシュの制限、コミットメッセージのパターン、etc… Git/GitHub 知っておくと便利かも Tips 61
62. Rulesets の構成 Enforcement status: Active, Evaluate, Disabled から選択。Active にするとルールに従い操作が制限される。Evaluate にすると操作に対する評価は行われる（ログに記録される）が、操作は制限されないため、ルールのテストに使える Bypass list: ルールを無視できるロールやチーム、App、ユーザーを指定できる Targets: ルールを適用するブランチやタグをパターンで指定（default branch の指定も可能） Rules・Restrictions: 適用するルールを指定 Targets にマッチするブランチやタグに対して Rules・Restrictions が適用される。ただし、Bypass list に指定された存在に よる操作は制限されない。 Git/GitHub 知っておくと便利かも Tips 62
63. ブランチ保護のルール一覧（branch ruleset） Restrict creations: ブランチの作成を拒否 Restrict updates: ブランチの更新を拒否 Restrict deletions: ブランチの削除を拒否 Require linear history: merge コミットを禁止。プルリクエストを取り入れる際は squash と rebase のみ許可 Require merge queue: マージ時はマージキュー機能の利用を強制 Require deployments to succeed: environments において deployments の成功を強制 Require signed commits: 署名付きコミットを強制 Require a pull request before merging: 全てのコミットをプルリクエスト経由で行うことを強制 Require status checks to pass: ステータスチェック(Actions のジョブなど)の成功を強制 Block force pushes: force push を禁止 Require code scanning results: code scanning によるアラートが指定したレベル未満であることを強制 Restrict commit metadata: コミットのメールアドレスやメッセージのパターンを指定してコミットを制限 Restrict branch names: パターンにマッチする（しない）ブランチ名を強制 [1] 1. 設定が非常に複雑だが使いこなすと強力。個人リポジトリでは使えないので試しづらいのが難点。ぜひ探究してほしい ↩︎ Git/GitHub 知っておくと便利かも Tips 63
64. よくあるブランチ保護ルール例 ブランチ、コミットが消失しないようにする Rules Restrict deletions Block force pushes 特定の CI ジョブの通過を必須にする Rules Require a pull request before merging Require status checks to pass Do not require status checks on creation Status checks that are required : GitHub Actions: npm test （Actions のジョブ等を指定） [1] 1. デフォルトブランチが対象なら問題ないが、合流ブランチなどの短命なブランチに対して適用する場合は設定しないとブランチ作成 (push) ができないため、これを有効にしている ↩︎ Git/GitHub 知っておくと便利かも Tips 64
65. よくあるブランチ保護ルール例 Code Owners によるプルリクエストのレビューを必須にする Rules Require a pull request before merging Require review from Code Owners Require approval of most recent reviewable push conventional commit、および、マージ時のコミットメッセージのみを強制する Targets: All branches Restrictions Restrict commit metadata Commit message , Must match a given regex pattern , ^(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test){1}(\([\w\-\.]+\))? (!)?: ([\w ])+([\s\S]*)|^Merge pull request.* Git/GitHub 知っておくと便利かも Tips 65
66. タグ保護のルール一覧 Restrict creations: タグの作成を拒否 Restrict updates: タグの更新を拒否 Restrict deletions: タグの削除を拒否 Require linear history: merge コミットを禁止。プルリクエストを取り入れる際は squash と rebase のみ許可 Require deployments to succeed: environments において deployments の成功を強制 Require signed commits: 署名付きコミットを強制 Require status checks to pass: ステータスチェック(Actions のジョブなど)の成功を強制 Block force pushes: force push を禁止 Restrict commit metadata: コミットのメールアドレスやメッセージのパターンを指定してコミットを制限 Restrict branch names: パターンにマッチする（しない）ブランチ名を強制 Git/GitHub 知っておくと便利かも Tips 66
67. よくあるタグ保護ルール例 タグの上書き、削除を禁止 Rules Restrict deletions Restrict updates Block force pushes タグ名に semantic versioning を強制 Targets: All tags Restrictions Restrict tag names Tag name , Must match a given regex pattern , ^v(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1- 9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0- 9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ Git/GitHub 知っておくと便利かも Tips 67
68. プッシュ保護のルール一覧 Restrict file paths: 特定のファイルパスのファイルのプッシュを禁止 Restrict file path length: 特定のファイルパスの長さ超えたファイルのプッシュを禁止 Restrict file extensions: 特定のファイル拡張子のファイルのプッシュを禁止 Restrict file size: 特定のファイルサイズを超えたファイルのプッシュを禁止 Git/GitHub 知っておくと便利かも Tips 68
69. よくあるプッシュ保護ルール例 実行ファイルのプッシュを禁止 Rules Restrict file extensions File extension , *.exe シークレットを含みうるファイルのプッシュを禁止 Rules Restrict file paths */.terraform/** .terraform/** Restrict file extensions .envrc [1] 1. .gitignore に書いておけばいい話ではあるが、 .gitignore に書き忘れた場合や git add --force で無理やりコミットしてしまった場合であってもプッシュ保護を設定しておけばプッ シュを防げる ↩︎ Git/GitHub 知っておくと便利かも Tips 69
70. 💡 リポジトリのセキュリティ向上機能たち GitHub にはリポジトリのセキュリティを高める機能がある Dependabot（無料！） alerts 依存関係の脆弱性を検出して通知する security updates 脆弱性のある依存関係を更新する PR を自動的に作成する Advanced Security（課金 ） Secret scanning git push 時にシークレットを検出して push を拒絶したり、コミットされたシークレットを検出してアラートする Code scanning コード内の脆弱性を検出し、修正を提案する [1] [2] 1. これらの設定は Organization の Advanced Security / Configurations から横断的に設定もできる ↩︎ 2. Advanced Security に内包されている機能の一部は public リポジトリにおいて無料で利用できる ↩︎ Git/GitHub 知っておくと便利かも Tips 70
71. GitHub での生産性向上 Tips
72. 💪 マージされたブランチを自動で削除 Automatically delete head branches プルリクエストをマージした後に、マージ元のブランチを自動的に削除する機能 大規模なリポジトリになるとマージ済みで不要になったブランチであふれかえりがちなので設定しておくと便利 マージ後に CI でブランチを再利用して何かやる場合には困るかもしれないので注意 不要なブランチが残らなくて便利 Git/GitHub 知っておくと便利かも Tips 72
73. 💪 タスク番号を自動でハイパーリンク化 Autolink references リポジトリ内の Issue や PR、コミットメッセージに含まれる特定の文字列を自動的にリンクにする機能。 kintone や Linear、Jira などでタスク管理している場合に便利。 TASK-< 数字> に https://example.com/tickets/TASK-< 数字> のリンクを貼る設定 こんな感じでマッチする文字列がリンクになる Git/GitHub 知っておくと便利かも Tips 73
74. 💪 複数人で開発したことを明示的に表す Co-authored-by 複数人で作業したコミットであることを示すための機能 コミットメッセージに Co-authored-by: < 名前> << メアド>> を追加する 誰の貢献であるか、誰の責任でコミットされたかをはっきりさせられる。モブプログラミング時に有用 ただし、これを毎回設定することの面倒くささの方が勝る… GitHub のユーザと紐づいた形で表示される # コミットメッセージ feat: most fantastic feature Co-authored-by: Seisan Shain kun <seisan-shain-kun@example.com> Git/GitHub 知っておくと便利かも Tips 74
75. 💪 パーマリンクで不変なコードを共有する GitHub 上のコードを共有する際、気をつけないとブランチに 依存した URL になってしまう 例: https://github.com/korosuke613/homepage- 2nd/blob/main/src/components/MyIcon/index.tsx#L101- L105 この URL は main ブランチの /src/components/MyIcon/index.tsx の 101 行目か ら 105 行目を指している main ブランチが更新されると、101 行目から 105 行目の コードが変わってしまう こうならないようにコードを URL で共有する際はパーマリン ク化して共有する A さん「隠しコマンド一覧を共有します」 ↓ main ブランチが更新された！ ↓ B さん「本当にこれ隠しコマンド一覧？？？」 Git/GitHub 知っておくと便利かも Tips 75
76. パーマリンクで不変なコードを共有する GitHub では簡単にパーマリンク化できる ショートカットキー y アドレスバーの ref 部分がコミットハッシュになる 3点リーダー（ ••• ）をクリックして Copy permalink をクリック パーマリンクとしてクリップボードにコピーされる 先ほどの例だと https://github.com/korosuke613/homepage- 2nd/blob/299bb6174a38c85d4b2deebd5f96c3427fce2b17/src/components/MyIcon/index.tsx#L101-L105 が得 られる コミットが残る限り共有されるコードの内容は不変となる 注意点：共有される側はコミットハッシュを含む URL が最新のコミットとは限らないことを理解しておく必要がある [1] [2] 1. 平木場はもはや y キーを押すのが癖になっている ↩︎ 2. すぐに気づくとは思う ↩︎ Git/GitHub 知っておくと便利かも Tips 76
77. 💪 コンソールや CI から GitHub を操作する GitHub 公式ツールの GitHub CLI（ gh コマンド）を使えば CLI 環境や Actions 上から簡単に GitHub を操作できる よく使うコマンド gh auth login : OAuth app 経由で GitHub にログイン gh pr view --web : 現在のブランチから PR を特定してブラウザでオープン gh api : GitHub API を直接実行するためのコマンド API の検証や GitHub CLI ではできないことを自動化する際に使う 例: gh api /rate_limit : 現在の認証情報における各種 API の rate limit を取得 各種 API はドキュメントをチェック REST API: https://docs.github.com/en/rest GraphQL API: https://docs.github.com/en/graphql [1] 1. GITHUB_TOKEN を渡すだけで（スコープの範囲内の API が）実行できて楽 ↩︎ Git/GitHub 知っておくと便利かも Tips 77
78. おわりに
79. まずはドキュメントを探そう よくわからない git のコマンドやオプション、GitHub の機能を見つけたらドキュメントを確認しよう。 Git 公式ドキュメント: https://git-scm.com/docs Google 検索するときに git < コマンド名やオプション名> scm とか、 git < コマンド名やオプション名> site:git-scm.com とかで検索すると、すぐに辿り着ける それでもわからないときはソースコード (https://github.com/git/git) を見よう！（小声） GitHub 公式ドキュメント: https://docs.github.com Copilot くんによるサポート（要ログイン）: https://support.github.com/success/copilot 自然言語で質問すると、Copilot くんが GitHub のドキュメントを参照した回答をしてくれる Git / GitHub を使って生産性の高い開発ライフを！ Git/GitHub 知っておくと便利かも Tips 79
80. おまけ: 平木場が設定している 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/GitHub 知っておくと便利かも Tips 80