はじめに
開発チームを支援するプラットフォームエンジニアとして、Git ワークフローと規約を提示するケースを考えます。これらは開発の本質ではないので、プラットフォームエンジニアが支援する領域となり得ます。
この記事は、表題について理解を深めたいプラットフォームエンジニアや、プロジェクト初期のチームリーダーに向けて書きました。ぜひ最後までご覧ください。
Git ワークフローを提示する
GItHub Flow をベースにカスタマイズしていくのが基本線です。
なぜなら、GitHub Flow 唯一の競合である git-flow を積極的に採用すべきケースが少ないと考えられているからです。
具体的に、git-flow の問題点については以下が詳しいです。
ただし、一部 git-flow 用語を拝借して GitHub Flow に適用するケースもあるので、git-flow は一度学んでおくのがいいです。たとえば、featureやhotfixなどです。
Git にまつわる規約を提示する
GitHub Flow を前提に、さらに細かく規約を見ていきます。私が今までに見てきて悪くないと思った規約を具体例として掲載します。
コミットの規約
コミットに関する規約は、たとえば以下のようなものです。
コミットメッセージの先頭には13660: のようにチケットIDを付与する。
チケットIDというのは Redmine や Jira などのタスク管理アプリケーションのチケットに一意に割り当てられるIDのことです。後で変更背景などを簡単に追うことができます。ソースコードやコミットメッセージにすべての情報を書き切れるとは限らないので、チケットに飛べると便利なケースが多いです。
プッシュの規約
プッシュに関する規約は、たとえば以下のようなものです。
デフォルトブランチへのプッシュは禁止する。
これはほぼほぼ必須ですね。さらにマージ権限を偉い人のみに設定すれば、そうそうデフォルトブランチが壊されることはありません。しかし、ルールを規定すればその分動きづらくなるので、調子に乗って色々ルールを作らないように気をつけましょう。そのあたりのバランスを取るのが、我々ルールを整備する者の仕事です。
ブランチの規約
ブランチに関する規約は、たとえば以下のようなものです。
ブランチ名は{ feature|hotfix }/{ ticket id }_{ description }というふうに命名する。
{ feature|hotfix }みたいに分けると、Four Keys を計測するのに使えたりします。詳細は別記事で解説します。{ ticket id }_{ description }は言うまでもないかもしれませんが、後で情報を追うことができます。コミットの規約のところで解説したものと同様です。
リベースの規約
リベースに関する規約は、たとえば以下のようなものです。
masterの最新のコミットを作業ブランチに取り込む手段としてマージではなくリベースを使う。
このようなケースでマージを使うと無駄なマージコミットがどんどん積み重なっていきます。さらにそのマージコミットは「作業ブランチが古くなったので更新したよ」以上のことを伝えられません。そのマージコミットが残ることにあまり意味はないでしょう。
タグの規約
タグに関する規約は、たとえば以下のようなものです。
セマンティックバージョニングに従ってリリースタグを打つ。
こちらもほぼほぼ必須ですね。
さいごに
プラットフォームエンジニアはあくまで開発チームを支援する側なので、あまり出しゃばらず開発チームの事情を最大限汲み取って選択肢を提示するくらいの温度感がいいと思います。
また、Git にはフックという面白い機能もあるのでそのあたりにも触れたかったのですが、それはまたの機会に。
コメント