Gitのワークフローについての私のスタンス

Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基本的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。

ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。

Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてないところもありますし、他のメンバーとの意見の違いもあるかもしれません。会社として画一的に統一する必要もないと考えています。あと、僕個人的には、最近はレビューをサボりがちで良くないとも思っています…。

ベースブランチ名など

• mainブランチ
  • 必要に応じてdevelopブランチを並走
  • 古いリポジトリはmasterのままにしているものもあるし、積極的にrenameしないといけないとは思っていない。気が向いたらrenameしても良いかな、くらい
• ベースブランチからfeatureブランチを切って開発完了したらマージ
  • オーソドックスなスタイル
• 社内プロダクト開発でリリースタイミングをコントロールしたい場合はmainと並走するdevelopブランチを作る
  • developブランチをベースブランチとしてfeatureブランチを切る
  • developブランチをmainブランチにマージすることがリリース
    • developからmainへのpull requestの自動作成
      • git-pr-release の利用
    • mainブランチのコミットが進むと自動で本番deployされる
• main, develop等のベースブランチへの直pushは基本しない
  • 些細な変更でもpull requestを作る
• OSSだとdevelopブランチを作らず、タグをリリースとする
  • release commitを作り、それにタグを打つようなワークフローを組んでいる
  • 社内プロダクト開発でもタグをリリースとしたいが、そのためにはGitHubにtag request的な機能が欲しい

コミットコメントとpull request

• 正直コミットコメントはそこまで丁寧に書かなくて良いと思っている
  • もちろん丁寧に書くに越したことはない
  • ここはかなり開発者によってばらつきがあるので、そこの違いにストレスを溜めても仕方がないと思っている
  • その代わりpull requestの説明及び粒度の調整はしっかりやる
• pull requestに説明をちゃんと書く
  • ここを整えないと当然レビューが進まずなかなかマージできない
    • 最低限ここをちゃんとしなければならない、というインセンティブにもなる
      • コンセンサスを取りやすい
    • コミットコメントはpull requestの「補足説明」くらいの位置づけの感覚
      • もちろん「補足説明」としては有用なのでここをちゃんと書いておけばリードタイムが良くなるのは間違いない
  • pull requestのリードタイムを短縮することこそが大事
    • ここでいうリードタイムとはfeatureブランチが切られてからマージされるまでの時間
      • ここを改善してスループットを上げることが開発速度に直結する
    • なので、自明な変更だったらpull requestのテンプレを全部きちんと埋めたりしなくても良いこともある
      • スクラムでも「成熟したチームのユーザーストーリーは短くなるし、時には雑さが許容されることもある」という話があって似ている
  • GitHubへのロックインやgit履歴自体の独立性を損ねることは気にしていない
    • いざとなったらpull requestの内容もAPIで抜いてこれるし、移行もできるでしょう

pull requestのマージ

• マージコミットを作る方針(=GitHubの通常のマージ/--no-ff)
  • ベースブランチに入るコミットが一つだけになる
    • revertもしやすい
  • squash and mergeでもべースへのコミットは一つになるが情報量が落ちてしまう
    • レビューしたときはコミット情報は残ってたわけだし
    • OSS等社外に見せるものなら整えた方がいいかもしれないが、社内の場合、泥臭いログ含めて残っていた方が問題調査に役立つこともある
• なので、頑張ってgit logを一本にすることにはこだわらなくて良い

pull requestの粒度

• pull requestの粒度には気をつけるべきだが、pull request = one commitを目指すのが理想だとは思わない
  • 寧ろcommit粒度はもう少し細かくても良い
• 粒度を小さく留める
  • ブランチに1日分の作業量以上積み重ねているのにpull requestを出せなかったら黄色信号。2日分以上溜めてしまったら立ち止まったほうが良いかもしれない
• 大きめの機能開発でも、作業を分割し、一つのpull requestはそれくらいのサイズに留める
  • それらのpull requestもマージされたら本番にはリリースできるように作る
    • 例えば、先に機能用の新規DBテーブルだけを作ってdeployしてしてもユーザーには気づかれない
  • 機能を隠しておきたい場合はフラグなどで制御する

履歴改変

• 私は積極的にはやらない。無理にコミットをまとめたり整え直す必要はない
  • rebase -i したいならどうぞ。歴史改変絶対に許さない、とは思っていない
• pull requestの粒度が大きめで、差分全体を読んだだけでは分かりづらい場合などに、コミット毎に見て欲しい場合などがある
  • そういうときにコミット一つ一つを整えるためにrebaseすることは私もある
• レビューワー等読み手の負担を考えてコミットをきれいにするのは間違いなく良い心がけ
  • ただ、頑張りすぎる必要もない

featureブランチのpush

• 作り始めたらすぐにpushしてDraft pull requestも作るのが望ましい
  • チームメンバーから何をやっているかが見える
• 作りかけをCIに怒られることを恐れない
  • 寧ろ早いうちに間違いに気づけるので推奨

ベースブランチへの追随

• rebase developでもmerge --no-ff developでもお好みでどうぞ
  • 私は昔は常にmergeしていたが、今はrebaseすることも増えた
  • force pushを怖がらなくなったため
• ベースブランチへのマージ前に追随することを必須にする必要はないと思っている
  • たまにヒヤリとすることもあるのでそこはプロジェクトのスタンス次第

force push

• 使って良い。昔は禁止したほうが良いと思っていたがそうは思わなくなった
  • ただ、今は --force-with-lease があるのでこれを絶対に使う
• 当然自分だけが開発しているfeatureブランチに対してのみ使う
• 「後でamend/rebaseするかもしれないから」とfeatureブランチをpushせず手元で温められる方が嬉しくない

レビューとマージ

• 社内プロダクト開発においてはpull requestを出した当人がマージボタンを押す
  • これは意見があると思うが個人的にはこだわりのスタイル
  • 「自分が押したマージが本番に出ていく」という体験をしてもらう
  • コードベースへの当人のオーナーシップの醸成
• レビューを通して開発した当人が安心してマージボタンを押せる状況を作り出す
• 「リードエンジニアにレビューしてもらってマージしてもらう」はアンチパターン
  • 暗黙の権威が生まれ、勾配も拡大する一方となる
  • レビューしてもらえたから大丈夫だろう、と担当者が油断する
  • レビュワーの好みにコード全体が偏る
  • さらにはレビュワーが過剰に直させる、みたいなことも起きがち
  • →コードベースが「リードエンジニアのコード」から脱却できない
• レビューはコードを「チームのコードにする」プロセス
  • そのコードについてわからない人がレビューしても良い
    • むしろしたほうが良い
  • レビューを通してチームのレベルアップを図るのは良いが、教育のプロセスではない
• レビューは最速で取り組むべき
  • しかし実際のところ難しいし、ボトルネックになりがち
  • ちゃんとレビューできる人を増やすのがとにかく大事
  • リードエンジニアレビュースタイルだとそこが大きなボトルネックになる

モブプロをすればレビューは不要か？

• そうは思わない
• モププロが有効な開発手法であることは認める
  • 前職ではやったことはありましたが、Natureではモブプロは今の所やっていません
• 比較的わかりやすい開発項目であればレビューをしないという判断をしても良いとは思う
• ただ、同じ場にいて同じコンテキストで開発をしていると「同じ罠にハマる」可能性がある
  • 同じ見落としをしてしまい、バグを生む可能性がある
• 第三者的な、コンテキストを共有していない視点でのレビューがあった方が安心

最後に採用情報

このエントリをここまで読んで、Nature社内のワークフローのイメージが湧き、私たちと一緒に働きたいと思ってくださったあなた、採用応募してくださると嬉しいです。まずはカジュアルに話を聞いてみたいということであれば、Twitter @songmu までDMしてください。お待ちしています！

https://nature.global/careers/