以下, GitおよびGitHubを運用する上でのポリシーの試案.
基本的にはGitHub Flowに従うが, 部分的にGitLab Flowの要素をとりいれる. 目的は, 開発者のハードルを下げることと, リリース管理者が複数環境でコードを確認する負担を軽減すること.
https://gist.github.com/Gab-km/3705015
https://about.gitlab.com/2014/09/29/gitlab-flow/
常に存在する主要なブランチはmasterとdevelopである. masterは常にdevelopの後方にいる. 理想はmasterとdevelopが同期している状況である(GitHub Flow).
-
masterブランチはいつでも全ての環境においてリリース可能である. - 基本的に
masterには直接コミットしない. - 新しい何かに取り組む際は, 新しく課題を立てて, 必要であれば説明的な名前のブランチを
developから作成する. - コミットメッセージの最初に関連する課題番号を付与する(例:
git commit -m "#24 Fix a typo"). - 作成したブランチにローカルでコミットし, サーバー上の同じ名前のブランチにも定期的に作業内容をpushする.
- フィードバックや助言が欲しい時, ブランチをマージしてもよいと思ったときは,
developブランチへPull Requestを作成する. - Pull Requestを出した後はそこで他の作業はしない(レビューに対する修正は可). 必要であればここから派生したブランチを作成してそこで作業する.
- 他の誰かがレビューをして機能にOKを出してくれたら, コードを
developへマージすることができる. -
developブランチへのマージは特定の環境においてリリース可能であることが確認されていればして構わない(例: Travis CIがパスしている). -
developブランチが全ての環境においてリリース可能であることが確認された時点で,masterブランチをそこまで進める. つまり, リリース管理者はdevelopブランチだけを監視していれば良い. -
developが何らかの環境でリリースできない状態である場合には, バグとして課題を立てる. - リリースは
masterブランチの任意の時点においてタグ付けすることで行う. これはリリース可能かどうかというよりも, 時期と進行中の課題によって決定する.
以下, ハリセン:
- いずれの課題にも割り当てられていないか, 課題に関連するコミットも作業コメントもない人はハリセン.
- Pull Requestを出したブランチが特定の環境においてビルドできなければ, Pull Request出した人にハリセン.
-
developが特定の環境においてビルドできなければ, 最後にコミットした人にハリセン. -
masterが全ての環境においてビルドできなければ(リリース可能でなければ), リリース管理者にハリセン. -
developが特定の環境以外でビルドできなくても, 誰の責任でもない. 課題を立てて皆でがんばる.
デメリット:
- プロダクション用のブランチを
masterから分岐することができない. リリース可能にみえてその実バグがあった場合,developの先頭までいかないとリリースできない.