問題とアプローチ (2019-10-25T15:20 追加)

表出している問題と、ここでのアプローチを書いておきます。

ブランチファースト（造語）

「ブランチファースト」はこのエントリでの造語です。コードベースに変更を加える際に「まずブランチを作成する」から始めることを指します。作業単位でブランチを作成、ブランチでコードを変更してプルリクエスト、レビューを経てメインライン（ master ブランチ）に反映までがブランチファーストのスコープになります。よくあるスタイルだと思いますし、ブランチだけ作成して変更せずプルリクエストを作成する拡張もありますね。

プルリクエストを挟まずにメインラインにマージするものは含みません。 ……名前微妙な気がしてきた。

表出しているがちな問題

マージに時間がかかっている
マージミスが起こりがち
マージしたらテストが通らない（個々のブランチは通るのに）
フィーチャーブランチの生存期間が長い
フィーチャーブランチが乱立している
リリースブランチにしかないスクリプトが忘れられがち
ボーイスカウトルール的なリファクタリングが重量プロセスになる
プルリクエストが滞留している
プルリクエストのレビューは変更部分以外にコメントしづらい

アプローチ

全員がメインラインに直接 commit して push しよう

と言うことで続きをどうぞ。

フィーチャーブランチをやめてみた

フィーチャーブランチ。タスクブランチとかいろんな呼び方があると思うけど、特定の作業毎に作るブランチ。チケットやissue単位で作るブランチもこれに該当します。

フィーチャーブランチを作るとメインラインとの間でマージが必要になる。メインラインにフィーチャーブランチをマージする際の負荷を制御するために、メインラインからフィーチャーブランチへのマージを頻繁に行っておくとかあるけど、フィーチャーブランチを作るから発生する作業にみえるんです。やること増やしちゃってないかなって。

リリースブランチをやめてみた

リリース作業を行うためのブランチ。開発できたものを取り込んで、リリースのための作業をして、えいやとリリース。リリース先はステージング環境だったり、プロダクション環境だったり。環境ごとにリリースブランチを作って、今どんなソースがリリースされてるかわかる。

OKなるほど。タグでよくないかな。

メインラインとリリースブランチに差があることがある。その差分をメインラインに入れれないのはなんでだろうって見てみると、リリース用の設定だとかスクリプトとか。他にもフレームワークなどがメインラインに入れづらい設計だったりすることもある。かもしれない。少なくとも私はリリースブランチがなかったら不可能というのは記憶にないです。

メインラインとリリースブランチが一致すると、ほんとタグがわりに使ってるだけになる。無駄にブランチの形してるから、リリースのたびにマージが発生する。FastForwardで済むんだけど、リリースの記録とか残したいし、で --no-ff したりする。いやほんとタグでいい。

リリースのための設定やスクリプトであってもメインラインに置いて、リリース以外の時も使えるものってあったりするので、メインラインに置いて目に入りやすくしておくのがいいかな。

使いたくなるのはわかる

ブランチ。使いたくなるのはわかるつもりです。私も「ブランチが軽量に使えるGit超便利！」とか思ってました。

ブランチって機能があるし、どこでも使ってるし、それなりに上手くいってる（上手くいくってなんだ？）ように見える。なんちゃらフローとか実績のあるブランチ戦略もある。 ~~ブランチ戦略って言葉格好いい。~~ 使うには十分な理由かもしれません。

ブランチを使うことで作業が独立して行えて、変更差分のレビューがしやすい。なるほどわかる。

けど。けどね。

ブランチを使うと背負いこむこと

ブランチを使うと作業がブランチに閉じます。閉じるのがいいって話があるのかもしれないけれど、例えばフィーチャーブランチならそのフィーチャーと関係のないリファクタリングがしづらくなります。

例えば名前変更、パッケージ変更なんて顕著ですね。フィーチャーブランチの効果の一つに「差分がわかりやすくなる」と言うのがあるので、フィーチャーブランチの中でその手の作業をするのは抵抗が生じてきます。

この例だと、

フィーチャーブランチの外でリファクタリングのフィーチャーブランチを別に作成
リファクタリングのフィーチャーブランチで作業してメインラインにマージ
メインラインからフィーチャーブランチにマージ

のようなステップを踏むことで、フィーチャーブランチはフィーチャーに閉じれます。うまくいくように見えますが、全体に渡る大規模な名前変更の場合、3のマージのコストが高くなりがちです。その場合にマージを諦めてフィーチャーブランチを破棄してやり直すと言う手が取れますが、なかなか捨てづらいようでマージ頑張るのをよくみます。で、破棄しやすいようにフィーチャーブランチの生存期間を短くするルールが作られて、これはこれでいいと思うんですが、ルールでがんじがらめになっていくのはあまり好きじゃない。

と言うか名前変更のためにこんなステップ踏みたくないし、これを終えるまでフィーチャーブランチの中は違和感ある名前でやることになる訳だし、フィーチャーブランチで作業してる中で見出した名前変更を単独で適用するのもなんだかなーとか……。

ともかく、ブランチを作るとマージのコストとリスクを背負いこみます。マージはメインライン origin/master からローカルブランチ master へのマージ以外でやりたくない。

つまり、プルリクエストをやめてみた

プルリクエストとマージリクエストと。 : ここでは「プルリクエスト」と呼びます

プルリクエストのような差分だけに注目するレビューが無駄とは言わないのですけど、いつも必要な訳でもないと思うんです。

差分レビューの欠点の一つはボリュームが大きくなったらみづらくなる、場合によっては見なくなること。変更差分が大きいほどしっかり確認する必要があると思うんですが、差分が小さい時だけ見るのを促進する仕組みには疑問を感じています。

もう一つは差分を含めた全体のレビューがしづらいこと。差分だけだと見づらいぎこちなさは気づけませんし、プロダクトとしては個々の差分より全体に価値があると思うのですよ。そして差分で出ていないところへのコメントもつけづらい。コードのリンク併用で書けばいいんだけど、そういう特別な対応が必要になるんですよね。

なので とっととメインラインに入れてしまって、必要ならそこから直してしましょう でいいと思う。

「それだとどんなことするかわからない」とかお声が聞こえてくる気がします（実際言われたこともある）が、それって何をするかわからないメンバーを既にチームに入れてるってことですよね。コードだけ取り繕ってる場合ではないのでは……。

チームに入ったばかりだとかでお互い様子見してるときは「閉じた安全な環境」としてブランチ＋プルリクエストもいいと思います。でも最初のうちだけかな。ブランチ＋プルリクエストをやってるうちは、プロダクト全体への責任感なんて出てきづらいと思う訳です。ペアプロでもモブプロでもなんでもして、早くメインライン直接触ってもらえるようにする。で、コードのどこでも自分の意思で触っていい、触ってダメなら戻せばいい、とかやってるうちに「ちょっと名前わかりづらいかな」とかをカジュアルにリファクタリングできるようになってくるかなーと。

この辺り、根底には「できるようになってからやりましょう」ではなく「やってることしかできるようにならない」という考え方があります。失敗しても死なないんだから、準備はそこそこにしてやっちゃえばいいと思うんだ。

例えば、作りかけがコミットできなくなると言う話

抽象化によるブランチでなんとかなるはずです。橋の架け替えとか、ストラングラーパターンとか。色々手はあります。

「いろんなところを一度に変えなきゃいけないからブランチが適切」はたぶん変更箇所を局所化するリファクタリングを先に行うのが適切なんですが、コストがかかるのも事実。でもそう言うのに挑むことで付く設計力とかもあると思います。ブランチファーストはそれを阻害してるんじゃないかなって。

「レガシーコードからの脱却」にも記述があるので引用しておきます。

コードがシステムに統合されると、リスクはほぼゼロになる。コンポーネントが別ブランチになっていてリリース前に統合される場合、リスクは統合されるまでわからない。ブランチを使う代わりに、フィーチャーフラグを使用して、使う準備のできていない機能を無効にしよう。

7章プラクティス３継続的に統合する/ 7.7 実践しよう/ 7.7.2 リスクを減らす7つの戦略 / ブランチを避ける

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

作者: David Scott Bernstein,吉羽龍太郎,永瀬美穂,原田騎郎,有野雅士
出版社/メーカー: オライリージャパン
発売日: 2019/09/19
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

もちろん、適切な場合には使う

ブランチがあっているものもあります。なので禁止したいわけじゃない。ブランチファーストになっているのに違和感があって、必要な時だけ使うのがいいなと思ったのでやめてみたと言う話です。禁止したいわけではありません。作り捨ての実験とか。複数バージョンをメンテナンスしなきゃいけないとか。抽象化によるブランチの設計コストが全く見合わないとか。他にも色々あると思う。「ブランチが適切」となる場合もあります。適切なら素直に使うのは当然のお話。