[[📒Productivityを上げるために大切な100のこと]] No58. 🥉 ---- 今回は開発の話になる。 2021年では、[[Git]]を使わずに開発している人や団体の方がレアだろう。[[VCS]]として1つの完成系とも言える[[Git]]はまさにデファクトスタンダードと言える。 [[Git]]には[[SVN]]など従来の[[VCS]]に比べて、ブランチが扱いやすいという特徴がある。これはツールとして考えればメリットだが、**ブランチを積極的に使うことが[[プロダクティビティ]]を上げるか**というと、==答えはNoだ==。 ## ブランチのデメリット 数多くのブランチがある状態はすなわち、**複数のタスクが同時並行で進行している**ということだ。この並列処理のような状態は一見効率的に見える。しかし、どうだろう..[[マルチタスクは効率が悪い]]という事実を顧みると、ブランチを多用した開発にも同じことが言えるのではないだろうか。 私が今まで参加してきたプロジェクトでは、多くのブランチを作成することにより以下の問題に遭遇していた。 - 開発するブランチを勘違いすることによるトラブル - マージするブランチを勘違いすることによるトラブル - 削除するブランチを勘違いすることによるトラブル - マージのときに発生したConflictを不適切に解消したことによるトラブル つまり、ブランチの生存期間や数が多いことにより、本来ブランチが得られる恩恵以上のデメリットを享受しているのだ。これは、==人間はブランチを作成すればするだけ、同時に複数のタスクを進めることができる==という勘違いによるものだと思っている。 もちろん、絶対に相互干渉しない場合などいくつか例外もある。だが、大抵の場合はそうでないだろう。 ## ブランチの作成と生存期間を厳しく管理する このデメリットに対するアプローチは簡単だ。逆のアクション、つまり**ブランチの数や生存期間を減らせばいい。** たとえば私の場合、以下のような制約で開発することが多い。 - **特別な事情がなければ==4日以上==ブランチを生存させない** - 3日で対応できないものは、Issueのスコープを狭くしたり諦める - **必要がなければブランチを==作成しない==** - 1人で開発しているとき - 2人以上で並行して開発することがない場合 - 開発開始と終了のタイミングで意思疎通すれば可能 - ブランチを作成するメリットより、デメリットが上回る場合 [[Gitflow]]や[[GitHub Flow]]のような[[📒Gitのブランチ戦略]]は適した状況で使うと効果が大きい。だが、その本質を理解せずに習慣的な理由だけでブランチを作成するのであれば、一度`master`のみで開発してみるのもアリだろう。見失っていた開発の楽しさやリズムを再び実感できるかもしれない。