Git の最新アップデートから考える開発手法の潮流

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon Confidential and Trademark.
Git の最新アップデートから考える
開発手法の潮流
AWS Developer Live Show

View Slide

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon Confidential and Trademark. 2
Yuki Yoshida
Sr. AppDev Consultant
AWS Japan Professional Services
好きな技術領域
Vim、Scrum、Terraform、Next.js、TypeScript、git
好きな⾔葉
「やってから考えようぜ︕」
yshd
whoami

View Slide


View Slide

注意事項
4
• 本セッションで利用している情報は全て各スライドの右下に参照元
リンクを掲載しています。
• 発表者が原文を和訳し情報が読み解けなかったものにつきましては
発表者の言葉で一部追記や変更をしています。
• スライドは後日公開されます。
#AWSDevLiveShow

View Slide

本日のテーマ
5
1. Gitとは
2. Git update 2022
3. Scalarとは
4. ブランチ戦略（git-flow、GitHub Flow、Trunk Based Development）
• Gitここが好き、ここが改善されるともっと好きになっちゃう
• リポジトリ構成（Monorepo、Polyrepo）
• Trunk Based DevelopmentでMonorepoを実際にやってみよう
• Git、DVCS、Mercurial、柔術（JJ）
• GitKon 2022のセッションの話
• よく使うgitコマンド、ツールの紹介

View Slide

Gitとは
6

View Slide

Gitとは
7
• gitコマンドを利用してデータの出し入れをするKVS
• Linux創始者のLinus Torvalds氏が2005年春に開発に着手※1
• 最初のコードは1300行ほど
• 2005年7月には一般ユーザーも使えるようになった
• 2007年7月末にメンテナーを濱野純氏に交代
˞ೖ໳(JUஶᖛ໺ ७ +VOJP$)BNBOP
ISBM: 4798023809
※2 https://www.infoworld.com/article/2669670/after-controversy--torvalds-begins-work-on--git-.html
「私は自己中心的だから、自分のプロジェクトには全て自分の名前をつけているんだ。
最初はLinuxで、今は ”git” だ」
※gitとは、英国のスラングで「腐った人間」や「馬鹿」、「間抜け」などと訳される

View Slide

Git Update 2022
8

View Slide

2022年のアップデートScalar関連
9
• 2.35（1/24）
• sparse indexのコマンドサポートが追加（reset, diff, blame, fetch, pull, ls-remote）
• git sparse-checkoutのinitが非推奨になり`git sparse-checkout set`を追加
• 2.36（4/18）
• sparse indexのコマンドサポートが追加（clean, checkout-index, update-index, read-tree）
• 2.37（6/27）
• WindowsとMac向けにgit組み込みのモニタリング機能が追加（fsmonitor）
• sparse indexのコマンドサポートが追加（show, sparse-checkout, stash）
• fsyncの設定にcore.fsyncMethod:batchが追加
• Partial Cloneの状態をgit remote –vコマンドの結果に追加
• 2.38（10/3 ）
• Scalar GA https://github.blog/2022-01-24-highlights-from-git-2-35/
https://github.blog/2022-04-18-highlights-from-git-2-36/

View Slide

2.35（1/24）
10
1. git stashにステージング領域に既にあるものを簡単に隠しておける--stagedモードが追加
2. git logのdescribe設定にlightweightタグ指定や、ハッシュ値の文字数設定が追加
3. OpenSSHのvalid-beforeおよびvalid-afterディレクティブの追加（OpenSSH8.8以上が必要）
4. git configのmerge.conflictStyle にzdiff3を追加（従前まではmerge、diff3）
5. git diffのhistogramアルゴリズムのパフォーマンス向上
6. git diffの--color-moved-wsのパフォーマンス向上
7. git-jump mergeで特定のディレクトリのコンフリクトに絞り込む機能を追加
8. 空のパッチをgit amした際の振る舞いを指定するオプションを追加（--empty=）
9. sparse indexのコマンドサポートが追加（reset, diff, blame, fetch, pull, ls-remote）
10. git sparse-checkoutのinitが非推奨になり`git sparse-checkout set`を追加
https://man.openbsd.org/ssh-keygen.1#ALLOWED_SIGNERS

View Slide

2.36（4/18）
1. git logとshowに—remerge-diffオプションを追加
2. fsyncの設定が柔軟に（core.fsync、core.fsyncMethodの追加）
3. リポジトリ所有者チェックの厳格化、safe.directoryを追加（2.35.2から）
4. git cat-fileに--batch-commandオプションが追加
5. git ls-treeに--object-only、--formatオプションが追加
6. git bisect の分類マーク忘れを検出し停止するようになりました
7. git fetchに—refetchオプションが追加
8. sparse indexのコマンドサポートが追加（clean, checkout-index, update-index, read-tree）
9. git clone --recurse-submodulesのfilterがsubmodule内まで再帰するように変更
10. バンドルがpartial cloneに対応
11. MIDX（Multi Pack IndeX）の同期バグ修正

View Slide

1. 到達不可能なオブジェクトを刈り取るためにcruft packsが追加
2. WindowsとMac向けにgit組み込みのモニタリング機能が追加（fsmonitor）
3. sparse indexのコマンドサポートが追加（show, sparse-checkout, stash）
4. sparse-checkoutのnon-coneモードが非推奨に
5. fsyncの設定にcore.fsyncMethod:batchが追加
6. git logやrev-listに--sinceオプションが追加
7. Partial Cloneの状態をgit remote –vコマンドの結果に追加
8. remote情報に認証情報が含まれている際に警告や終了するtransfer.credentialsInUrlが追加
9. git add –iの実装がPerlからCに変更されたものがデフォルトになりパフォーマンスが向上
2.37（6/27）

View Slide

1. Scalar GA
2. git rebaseに--update-refsオプションが追加
3. sparse indexのコマンドサポートが追加（rm）
4. sparse checkoutのConeの中から外に移す際のgit mvの動作を改善
5. オブジェクトへの到達可能性情報について.bitmapにルックアップテーブルを追加
6. .bitmapの技術的なドキュメント更新
7. git merge-treeコマンドがmerge-ortに統合（--trival-mergeオプションで既存の振る舞いも可能）
8. safe.bareRepository設定の追加（悪意あるリポジトリをCloneしgitコマンド実行されるのを防ぐ）
9. git grepに--max-countオプションが追加（ファイルごとに表示されるマッチ回数を制限する）
10. git ls-filesに--formatオプションが追加
11. git cat-fileに--[no-]use-mailmapオプションが追加
12. Gitの開発者向けドキュメントにコードレビューに関するGitコミュニティのガイドラインを追加
2.38（10/3）

View Slide

Scalarとは
14

View Slide

Scalarとは
15
https://github.com/microsoft/scalar
Slalarは以下のGit機能を有効にすることで実現します。
• Partial clone
• ダウンロードするGitオブジェクトを絞ることでリポジトリを取得する時間を短縮します。
• Background prefetch
• 定期的にリモートからGitオブジェクトをダウンロードすることでgitフェッチ呼び出しの時間を短縮します。
• Sparse-checkout
• 作業ディレクトリの大きさを制限します。
• File system monitor
• 最近更新されたファイルを追跡し、Gitがワークツリー全体をスキャンする必要をなくします。
• Commit-graph
• コミットウォークと到達可能性計算を高速化し、git logなどのコマンドを高速化します。
• Multi-pack-index
• 多数のパックファイルからオブジェクトを高速に検索することができます。
• Incremental repack
• 実行中のコマンドを中断せずにパック済のデータをより少ないパックファイルにリパックします。
Gitを最大規模のGitリポジトリに拡張するためのツール

View Slide

Scalarの始め方
16
https://git-scm.com/docs/scalar
https://github.blog/2022-10-13-the-story-of-scalar/
❯ scalar clone [email protected]:chromium/chromium.git
// git cloneとは違い”src”というディレクトリ下にダウンロードされる
❯ cd chromium/src
// 特定のディレクトリのみダウンロード
❯ git sparse-checkout set
// 全ディレクトリをダウンロードする場合
❯ git sparse-checkout disable
cloneから始める場合
git clone済の場合
❯ scalar register

View Slide

Scalar検証結果
17
https://github.com/chromium/chromium
①clone速度 ②ディレクトリ容量 ③git status速度
git clone 52分37秒 39.0GB 25.2秒
scalar clone 5分21秒 3.2GB 1.6秒
chromiumリポジトリにて検証
1,191,939 commits (11/12時点)
なぜScalarはこんなに速い？
• Partial clone機能を利用してオブジェクトの初期取得範囲を絞っている
• clone後もSparse-checkout機能を利用して必要なディレクトリを絞っている
• git管理下にあるファイルをFile system monitor機能により事前に計算している
実はScalarを利用しなくてもgitの機能を活用すれば同じことが出来る
Scalarは自動で大規模リポジトリ向けの設定をしてくれるツール
← ①と②に効いてる
← ③に効いてる

View Slide

Partial clone: 機能を利用してオブジェクトの初期取得範囲を絞っている
18
https://github.blog/jp/2021-01-13-get-up-to-speed-with-partial-clone-and-shallow-clone/
Partial Clone (Blobless）
❯ git clone --filter=blob:none
Partial Clone (Treeless）
❯ git clone --filter=tree:0
Shallow Clone
❯ git clone --depth= --single-branch --branch=
開発で利用するのは非推奨
非推奨
※CI/CDで最新のコミットをCloneする時には最速
• clone時はコミットとツリーのみに絞ってダウンロード
• checkoutしているコミットのブロブもダウンロードされるが—no-checkoutオプションで減らせる
• fetchすることで新しいコミットとツリーのみ取得（つまりpullするとHEADが変わるため注意）
開発で利用するのはこちらを推奨

View Slide

Cloneの種類ごとにダウンロードされる領域の違い
❯ git clone
Full Clone
HEAD
• 全てダウンロードするため、初期データ
取得時に時間がかかり、全てのファイル
を持つためのディスク容量が必要になる
• 開発者のgitバージョンを意識せずに利用
出来て、ほぼ全てのGitホスティングサー
ビスで利用可能
commit: ある時間のスナップショット
tree: ディレクトリ
blob: ファイルの中身
19
現在
過去

View Slide

Commit: ある時間のスナップショット
Tree: ディレクトリ
Blob: ファイルの中身
❯ git clone --filter=blob:none
Blobless clone
• コミットとツリーを全てダウンロードし、
checkoutしているコミットのブロブを取得
• つまりHEADより過去のBlobを取得しないため
比較的軽くなりやすい
• --no-checkoutオプションを使うことでHEAD
のBlob分の軽量化も選択できる
• fetchすることで新しいコミットとツリーを取
得し、HEADが変わるとブロブを取得する
• Scalarでcloneするとこちらが利用される
20
HEAD

View Slide

❯ git clone --filter=tree:0
Treeless clone
• HEADとコミットは全て取得する
• 過去のツリーとブロブは取得しない
• git log -- のようにファイル履歴のリク
エストを実行するとほとんど全てのコミットに
対してツリーのダウンロードが走ってしまう
• 開発者の利用は非推奨
• CI/CDで最新のコミットをCloneする時には最速
21
HEAD

View Slide

❯ git clone --depth= --single-branch --branch=
Shallow clone
• --depth=オプションによってコミット履歴
の数を絞ります（左図はN=1にしている）
• git fetchすると全てをダウンロードしてしまう
• logやmergeなどほとんどのコマンドが正しく動
作しない
• 利用は非推奨
22
HEAD

View Slide

Full Clone Blobless Clone
(Partial clone)
Treeless Clone
(Partial clone)
Shallow Clone
Cloneまとめ
• 利用推奨
• ScalarはBlobless Clone
• 対応してないサービス有
• 今後も通常利用できる
• 開発用途では非推奨
• CI/CDで利用するのは有
• 利用非推奨

View Slide

File system monitor: gitコマンドの高速化
24
https://github.blog/2022-06-29-improve-git-monorepo-performance-with-a-file-system-monitor/
• モノリポ等でGit管理下のファイルが多いとgit statusやgit addが遅くなる（ワークツリー全体を検索するため）
• File system monitor（以降FSMonitor）では検索のサイズを減らすことでコマンドを高速化できる
• git 2.37以降で利用可能
// Scalar Cloneすれば自動で立ち上がる
❯ scalar clone
// core.fsmonitor=trueであれば自動で起動する
❯ git config --local core.fsmonitor true
// 以下コマンドで直接起動や停止、状態確認ができる
❯ git fsmonitor--daemon [start|stop|status]
git status
git status
FSMonitor Daemon Process
OS
IPC
Thread
git add .
Received
FS Event
Queue
FS Event
Listener
Thered
Normalized
FS Events
File Syttem Change Notifications
From Operating System

View Slide

Scalar検証結果
25
https://github.com/chromium/chromium
①clone速度 ②ディレクトリ容量 ③git status速度
git clone 52分37秒 39.0GB 25.2秒
scalar clone 5分21秒 3.2GB 1.6秒
再掲
なぜScalarはこんなに速い？
• Partial clone機能を利用してオブジェクトの初期取得範囲を絞っている
• clone後もSparse-checkout機能を利用して必要なディレクトリを絞っている
• git管理下にあるファイルをFile system monitor機能により事前に計算している
実はScalarを利用しなくてもgitの機能を活用すれば同じことが出来る
Scalarは自動で大規模リポジトリ向けの設定をしてくれるツール
← ③に効いてる

View Slide

ブランチ戦略
26

View Slide

git-flowとは
27
https://nvie.com/posts/a-successful-git-branching-model/
• mainとdevelopという寿命がないブランチがある
• サポート用ブランチfeature、release、hotfix
• developブランチ
• origin/mainを次のリリースのために取り込み続ける
• 最新の開発変更点を反映した状態のメインブランチ
• リリースできる状態になったらmainへマージ
• featureブランチ
• 新しい開発に利用する
• developから分岐し、 developにマージ
• 命名規則: main、develop、release-*、hotfix-*以外にする
• releaseブランチ
• リリース準備（ビルド日時、バージョン番号）に利用する
• developから分岐し、 mainとdevelopにマージ
• mainマージ後にmasterにタグを付ける
• 命名規則: release-*
• hotfixブランチ
• 緊急の修正をdevelopと統合せずにリリースするために利用する
• mainから分岐し、 mainとdevelopにマージ
• 命名規則: hotfix-*

View Slide

補足情報: Technology Radar
28
私たちは、長期間のバージョン管理ブランチは継続的インテグレーションのような価値あるエンジニアリングの実
践に悪影響を与えると固く信じており、この信念が私たちのGitflowに対する嫌悪感の根底にあるのです。私たち
は、Gitの下での柔軟性を愛していますが、悪いエンジニアリングの実践を奨励するようなツールは嫌います。し
かし、Gitflow を使っているほとんどのチームは、ブランチを多用するワークフローを悪用する権限を与えられて
いると感じており、遅い統合を奨励しています（したがって、真の継続的統合は阻害されています）。
https://www.thoughtworks.com/radar/techniques/gitflow

View Slide

GitHub flowとは
29
git-flowの複雑性を解消したシンプルなフロー
http://scottchacon.com/2011/08/31/github-flow.html
ルール
• mainブランチにあるものはすべてデプロイ可能
• 新しいことに取り組むには、 mainから説明的な名前のブランチを作成する。
• ローカルでそのブランチにコミットし定期的に作業を同一のブランチ名でプッシュする。
• フィードバックやヘルプが必要なとき、あるいはブランチをマージする準備ができたと思うとき
は、プルリクエストをオープンする。
• 他の誰かがレビューしてサインオフした後、その機能をmainにマージすることができる。
• このファイルをマージして mainにプッシュしたら、すぐにデプロイできますし、そうする必要が
あります。
https://www.atlassian.com/blog/git/simple-git-workflow-is-simple

View Slide

GitHub flow例
30
https://docs.github.com/ja/get-started/quickstart/hello-world
①開発
（origin/mainから始まる）
②プルリクエスト作成 ③レビューを受けながら修正
（この時点で一部地域にデプロイするなども可能）
④いつでもリリース可能な状態

View Slide

GitLab Flowとは
31
https://docs.gitlab.com/ee/topics/gitlab_flow.html
「mainブランチはいつでも本番環境にデプロイできる」というGitHub Flowは
SaaSアプリケーションなどでは可能だが、不可能なケースもある。
不可能なケース
• App Storeの検証を通過した時点でリリースされるiOSアプリなどタイミングをコントロールできない
• 平日10時から16時まではデプロイメント可能という社内ルールがあり、それ以外の時間帯にもコードをマージ
する開発チーム
GitLab Flowの追加ガイダンス
• 各環境ごとのブランチを利用する（例: production, staging, pre-prod, development）
• どのコードが本番環境にデプロイされているのかを確認する場合はproductionブランチをcheckout
• hotfixはGitHub Flow同様にfeatureブランチをmainブランチにマージ後、 productionブランチへ
• ソフトウェアを外部に公開する場合には、ブランチ名を2.3-stableなどのようにマイナーバージョンを含める
• コミットメッセージは内容だけでなく意図を書く。なぜその変更を行ったのかを説明する。
など

View Slide

GitLab Flowの利用イメージ
32
A
origin/main
feature B
C
origin/staging
origin/production
D
E
F
G
H
①新機能を開発し、origin/mainへ
プルリクエストを作成
②origin/mainからプルリクエストを
作成し、マージされると新機能がス
テージング環境にデプロイされる
③新機能にバグが見つかったので修正し
再度origin/mainへプルリクエスト
④再度ステージング環境にデプロイし
最後の動作確認
⑤origin/stagingからプルリクエストを作成
しマージされると本番環境へデプロイされる
https://docs.gitlab.com/ee/topics/gitlab_flow.html
※実際はCとD、GとHはコミットを分けるべきではありません

View Slide

Trunk Based Developmentとは
33
https://trunkbaseddevelopment.com/
mainline
(or main or ‘trunk’)
開発者はビルドが通る状態を保ちながら、小さな修正をそのままmainlineにコミットする
• 短期反復型のアジャイルな開発手法を導入する
• 小さなストーリーやタスク
• ビルド時間が短くなるように工夫する
• ペアやモブでのプログラミングを用いる
• 開発者はPushする前にビルド、テストをする
• 大きなストーリーでは、小さなタスクがマージされ
てもフィーチャーフラグを利用するなどして機能を
表に出さないようにする
トランクベース開発を行うために推奨されること
特徴
• 大規模なマージ地獄から抜けられる
• 常にリリース可能
• 大きなストーリーや大規模開発では
• 短寿命のブランチを利用する
• プルリクエストを利用する

View Slide

Thank you!

View Slide

Git の最新アップデートから考える開発手法の潮流

Git の最新アップデートから考える開発手法の潮流

yuukiyo

More Decks by yuukiyo

Other Decks in Technology

Featured

Transcript