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

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

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

rights reserved. Amazon Confidential and Trademark.

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

rights reserved. Amazon Confidential and Trademark. 本日のテーマ 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コマンド、ツールの紹介

rights reserved. Amazon Confidential and Trademark. 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とは、英国のスラングで「腐った人間」や「馬鹿」、「間抜け」などと訳される

rights reserved. Amazon Confidential and Trademark. 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/ https://github.blog/2022-06-27-highlights-from-git-2-37/ https://github.blog/2022-10-03-highlights-from-git-2-38/

rights reserved. Amazon Confidential and Trademark. 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=<stop|drop|keep>） 9. sparse indexのコマンドサポートが追加（reset, diff, blame, fetch, pull, ls-remote） 10. git sparse-checkoutのinitが非推奨になり`git sparse-checkout set`を追加 https://github.blog/2022-01-24-highlights-from-git-2-35/ https://man.openbsd.org/ssh-keygen.1#ALLOWED_SIGNERS

rights reserved. Amazon Confidential and Trademark. 11 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）の同期バグ修正 https://github.blog/2022-04-18-highlights-from-git-2-36/

rights reserved. Amazon Confidential and Trademark. 12 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に変更されたものがデフォルトになりパフォーマンスが向上 https://github.blog/2022-06-27-highlights-from-git-2-37/ 2.37（6/27）

rights reserved. Amazon Confidential and Trademark. 13 https://github.blog/2022-10-03-highlights-from-git-2-38/ 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）

rights reserved. Amazon Confidential and Trademark. 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リポジトリに拡張するためのツール

rights reserved. Amazon Confidential and Trademark. 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 <path> // 全ディレクトリをダウンロードする場合 ❯ git sparse-checkout disable cloneから始める場合 git clone済の場合 ❯ scalar register

rights reserved. Amazon Confidential and Trademark. 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はこんなに速い？ https://github.com/microsoft/scalar • Partial clone機能を利用してオブジェクトの初期取得範囲を絞っている • clone後もSparse-checkout機能を利用して必要なディレクトリを絞っている • git管理下にあるファイルをFile system monitor機能により事前に計算している実はScalarを利用しなくてもgitの機能を活用すれば同じことが出来る Scalarは自動で大規模リポジトリ向けの設定をしてくれるツール ← ①と②に効いてる ← ①と②に効いてる ← ③に効いてる

rights reserved. Amazon Confidential and Trademark. 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 <URL> Partial Clone (Treeless） ❯ git clone --filter=tree:0 <URL> Shallow Clone ❯ git clone --depth=<N> --single-branch --branch=<branch> <URL> 開発で利用するのは非推奨非推奨 ※CI/CDで最新のコミットをCloneする時には最速 • clone時はコミットとツリーのみに絞ってダウンロード • checkoutしているコミットのブロブもダウンロードされるが—no-checkoutオプションで減らせる • fetchすることで新しいコミットとツリーのみ取得（つまりpullするとHEADが変わるため注意）開発で利用するのはこちらを推奨

rights reserved. Amazon Confidential and Trademark. Cloneの種類ごとにダウンロードされる領域の違い ❯ git clone <URL> Full Clone HEAD • 全てダウンロードするため、初期データ取得時に時間がかかり、全てのファイルを持つためのディスク容量が必要になる • 開発者のgitバージョンを意識せずに利用出来て、ほぼ全てのGitホスティングサービスで利用可能 commit: ある時間のスナップショット tree: ディレクトリ blob: ファイルの中身 https://github.blog/jp/2021-01-13-get-up-to-speed-with-partial-clone-and-shallow-clone/ 19 現在過去

rights reserved. Amazon Confidential and Trademark. Cloneの種類ごとにダウンロードされる領域の違い Commit: ある時間のスナップショット Tree: ディレクトリ Blob: ファイルの中身 ❯ git clone --filter=blob:none <URL> Blobless clone • コミットとツリーを全てダウンロードし、 checkoutしているコミットのブロブを取得 • つまりHEADより過去のBlobを取得しないため比較的軽くなりやすい • --no-checkoutオプションを使うことでHEAD のBlob分の軽量化も選択できる • fetchすることで新しいコミットとツリーを取得し、HEADが変わるとブロブを取得する • Scalarでcloneするとこちらが利用される 20 https://github.blog/jp/2021-01-13-get-up-to-speed-with-partial-clone-and-shallow-clone/ HEAD

rights reserved. Amazon Confidential and Trademark. Cloneの種類ごとにダウンロードされる領域の違い commit: ある時間のスナップショット tree: ディレクトリ blob: ファイルの中身 ❯ git clone --filter=tree:0 <URL> Treeless clone • HEADとコミットは全て取得する • 過去のツリーとブロブは取得しない • git log -- <path>のようにファイル履歴のリクエストを実行するとほとんど全てのコミットに対してツリーのダウンロードが走ってしまう • 開発者の利用は非推奨 • CI/CDで最新のコミットをCloneする時には最速 21 https://github.blog/jp/2021-01-13-get-up-to-speed-with-partial-clone-and-shallow-clone/ HEAD

rights reserved. Amazon Confidential and Trademark. Cloneの種類ごとにダウンロードされる領域の違い commit: ある時間のスナップショット tree: ディレクトリ blob: ファイルの中身 ❯ git clone --depth=<N> --single-branch --branch=<branch> <URL> Shallow clone • --depth=<N>オプションによってコミット履歴の数を絞ります（左図はN=1にしている） • git fetchすると全てをダウンロードしてしまう • logやmergeなどほとんどのコマンドが正しく動作しない • 利用は非推奨 22 https://github.blog/jp/2021-01-13-get-up-to-speed-with-partial-clone-and-shallow-clone/ HEAD

rights reserved. Amazon Confidential and Trademark. 23 Full Clone Blobless Clone (Partial clone) Treeless Clone (Partial clone) Shallow Clone Cloneまとめ • 利用推奨 • ScalarはBlobless Clone • 対応してないサービス有 • 今後も通常利用できる • 開発用途では非推奨 • CI/CDで利用するのは有 • 利用非推奨 https://github.blog/jp/2021-01-13-get-up-to-speed-with-partial-clone-and-shallow-clone/

rights reserved. Amazon Confidential and Trademark. 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 <URL> // 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

rights reserved. Amazon Confidential and Trademark. 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はこんなに速い？ https://github.com/microsoft/scalar • Partial clone機能を利用してオブジェクトの初期取得範囲を絞っている • clone後もSparse-checkout機能を利用して必要なディレクトリを絞っている • git管理下にあるファイルをFile system monitor機能により事前に計算している実はScalarを利用しなくてもgitの機能を活用すれば同じことが出来る Scalarは自動で大規模リポジトリ向けの設定をしてくれるツール ← ①と②に効いてる ← ①と②に効いてる ← ③に効いてる

rights reserved. Amazon Confidential and Trademark. 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-*

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

rights reserved. Amazon Confidential and Trademark. 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

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

rights reserved. Amazon Confidential and Trademark. 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などのようにマイナーバージョンを含める • コミットメッセージは内容だけでなく意図を書く。なぜその変更を行ったのかを説明する。など

rights reserved. Amazon Confidential and Trademark. 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はコミットを分けるべきではありません

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

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

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

More Decks by yuukiyo

Other Decks in Technology

Featured

Transcript