天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます

Git の最新アップデートから考える開発手法の潮流に参加してきた

aws-dev-live-show.connpass.com

こちらのイベントのアーカイブを視聴したので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

ソフトウェア開発する上で必ず立ちはだかる壁として「バージョン管理」があります。バージョン管理ツールの中でも今回は「git」にフォーカスを当てて考えていきたいと思います。

git は「clone」して「ファイルを編集」して「add」して「commit」、「push」するのが基本的な流れですが、チーム開発をしていると「merge」、「rebase」など少し理解が難しいものが出てくると思います。git がメジャーになってから 10 年以上が経ち、利用者が増えて満足度が高い声が聞こえる一方で「git 難しい、何も分からない」という声も聞こえてきます。

今回のセッションでは、最新の git のアップデート内容を振り返りながら「Monorepo」や「Trunk-based Development」など開発手法まで話を広げて解説、議論していきたいと思います。スペシャルゲストとしてアジャイルコーチ・アーキテクトをしているきょんさんをお招きして、「git の最新アップデートから考える開発手法の潮流」についてお話していきます。

スライド

speakerdeck.com

会の様子

以下、会で話されていたことを書いていきます。(スライドが公開されているので、スライドを見れば自明な部分は省略しています。)

Gitとの出会い

吉田さんきょんさんのお二人がGitにどう出会い、慣れ親しんでいったのか?という話を聞いていきました。

きょんさんはMercurialを元々愛用していたそうで*1MercurialからGitに変換するようなバックグラウンドツールを使いながら徐々にGitに慣れ親しんでいったということです。

吉田さんはSVNから入ったそうで、最初はわざわざファイルを選んでcommitする必要があるGitを手間に感じていたということですが、後々Gitの柔軟性の高さに驚き、今では手放せなくなっているというお話でした。

Git update 2022

Gitで2022年にupdateされた内容が紹介されていきました。

git stashに--stagedモードが追加

ステージングの変更だけをstashさせる--stagedオプションの追加ができるようになったということでした。

なお、git stash popしてしまうと、git stash pop --indexでaddした情報も併せて戻しておくと良いという話が出ていました。

OpenSSHのvalid-beforeとvalid-afterディレクティブが追加された(OpenSSH8.8以上が必須)

gitのcommitだったりTagはGPGキーで署名することができますが、2.34のアップデートでSSHキーでも署名することができるようになったそうです。

ただし、署名を使ってcommitした後にSSHキーをローテーションさせてしまった時、古い鍵で署名されたcommitが正しい署名であるかを確認できないという問題*2があったそうで、その対応策としてOpenSSHのvalid-beforeとvalid-afterディレクティブが追加されたということでした。

この対応によって、古い鍵で署名されたオブジェクトを無効化することなく、新しい鍵と古い鍵の有効期限を一緒にファイルで管理することでSSH鍵のローテーションができるようになったそうです。

Cloneに対するきょんさんコメント

吉田さんが4つのClone方法について説明してくれたあと、きょんさんがこのClone方法に対してコメントをしてくれました。

具体的には、monorepo文脈だと、CI上での巨大リポジトリの扱いがネックになる*3ため、TreelessでCloneするのは一つの選択肢になるというお話をしてくれました。(どの段階でFull cloneしてどの段階からCheckoutでやっていくのか?最初からTreelessでCloneするのか?という部分を自分たちが作りたいCIイメージに応じて作り替えていく)

git flowに対するきょんさんコメント

吉田さんがgit flowの全ルールについて説明してくれた後、きょんさんがコメントをしてくれました。

きょんさんはgit flowは少し使った後に使うのを辞めたということでした。理由としては、

  • 一個のバージョンで開発する前提で作られているため、カスタム版のようなものがいくつかある場合には向かない
  • developブランチが長い期間存続することになっているため、レビューがあまり捗らなかったり、本当に動くのか?が確認できず、人のマネジメント能力に拠るような仕組みづくりをする必要がある(git flowの運用力に開発が引っ張られるのが本末転倒感があった)

が挙げられていました。

Github flowに対するきょんさんコメント

git flow同様、Github flowについてもきょんさんからコメントがありました。

説明がしやすいのでコードレビュー文化を根付かせるために勧めたりすることはあるというコメントがありました。(ただし、きょんさんが所属している47機関はTrunk Based開発をしている)

Gitの強力さをもっと知ってもらうためのアドバイス

吉田さんは、ペアとかモブで達人にGitを習うのがいいのではないか?というお話が出ていました。

きょんさんも吉田さんと同じような意見を持ちつつ、今日やったような内容は最新のリリースノートを追っていく必要があるので、Github社のブログをたまに読むとかがやりやすいのではないか?ということでした。

会全体を通した感想

知っているコマンドもありましたが、コマンドを打った時に中身でどんなことが行われているのか?というところまでは全然知らなかったので、非常に学びが多くあるイベントでしたし、もっともっとお話が聞きたかったです。

吉田さんがGit大好きなのを隠しきれない感じが伺えたのもとってもよかったです笑

*1:当時は分散管理ツールのどれが流行るのかがわからないような状態だった

*2:正確には新しい鍵と古い鍵を両方アクティブにしないとダメだった

*3:コンテナ上でFull Cloneするとめちゃくちゃ重い