こんにちは
所属プロジェクトでGit運用するためのルールを作成しようという話があったので、
せっかくなのでそこで決まったことをアウトプットしようと思い、こちらでまとめることにしました。
ブランチ戦略
GitHub Flowに近い形で運用をしていました。
何故、GitHub Flowを選択したかというと以下の理由です。
- 少人数チームだったので比較的開発メンバーと容易にコミュニケーションがとれたため(Slackを活用)
- CIを用いた自動テストとプルリクエストのレビューを行っていたため、品質の保証はある程度出来たため
- 新規開発かつPOCのプロジェクトなこともあって、フローがシンプルであっても問題ないため
GitHub Flow自体のメリットについては以下の記事を参考ください。
参考：
https://qiita.com/trsn_si/items/cfecbf7dff20c64628ea
ブランチプレフィックス
| ブランチプレフィックス | プレフィックスの意味 | マージ元ブランチ | マージ先ブランチ |
|---|---|---|---|
| master | 最新のサービス。 | - | - |
| feature/{issue番号}_概要 | 新規機能開発用ブランチ | master | master |
| fix/{issue番号}_概要 | バグ修正用ブランチ。既存のものを直す時に使う。） | master | master |
大きな機能の開発について
feature/XXX-master とし、そこからさらに小さくブランチを切る運用をしていました。
手順
- feature/XXX-master 作成
- 例えばモック用ブランチとして feature/XXX-mockup 切り分け
- feature/XXX-master <- feature/XXX-mockup feature/XXX-mockupが完成した段階で、feature/XXX-masterにマージ
- feature/XXX-hogehoge を feature/XXX-master にマージを繰り返し、 feature/XXX-master を完成させる
- (master) <- feature/XXX-master
最初に空コミットする
ブランチを切ったらまず以下のコマンドを実行していく
$ git commit --allow-empty -m "{issue番号}-作業開始"
※ --allow-empty を使えばステージに差分が乗ってなくてもコミットできます。
コミットコメントの書き方
以下プレフィックスをつける
| プレフィックス | 意味 | プロダクションコード変更 |
|---|---|---|
| chore | 依存パッケージなどの追加、アップデート | なし |
| feat | 機能追加 | あり |
| fix | バグ修正 | あり |
| style | コードの見た目の修正 | なし |
| test | テストの追加や修正 | なし |
| refactor | リファクタリング | あり |
| remove | 不要な機能・使われなくなった機能の削除 | あり |
| doc | ドキュメントの更新 | なし |
| partial | 部分的な機能追加 | あり |
| tada | 大きな機能の追加 | あり |
| ci | CIの修正・改善 | なし |
| lint | Lintエラーの修正 | あり |
| performance | パフォーマンス改善 | あり |
| lock | 新機能の公開範囲の制限 | あり |
| security | セキュリティ関連の改善 | あり |
| wip | 人に引き継ぐときなど、途中経過の実装 | なし |
コメントには、なぜここを変更したかがわかるような内容をいれる
例
- feat: 問い合わせ機能の検索機能追加
- fix: 文言修正
- remove: modelに移行
参考：
https://qiita.com/numanomanu/items/45dd285b286a1f7280ed
https://qiita.com/mfks17/items/e68adc058e1a9e519807
- リベースを意識したコミット単位に。 コミットコメントに関連のある変更のみをaddする。
issue
issueをどういうときに作るか
- 意見提案の場として少しの気づきでも積極的に書いていく（issueからはじめよ）
issueのタイトルの付け方
{プレフィックス}{どこの画面}に{機能名}の実装
- プレフィックス(
[管理者画面][軽微]..) - ラベル（ 既存の
[優先度高][優先度低][バグ]を含め、[議論用]も活用。当然、増やすのもあり ）
をうまく使って緊急度、優先度を表現する
プルリクエスト
タイトルの付け方
#issue番号 やったこと
Draft: #issue番号 やったこと
Draft:を使う基準
- 開発途中だけどプルリクエストにしたいもの
- まだマージして欲しくないもの
概要の書き方
自動入力機能を作ってテンプレートを作るのがオススメです。
概要例(タイトル)
- git/github運用ルール機能を実装しました
概要例(詳細)
- [DONE] マイグレーション(マイグレーションMRのリンク)
- [DONE] モック(モックMRのリンク)
- [DONE] 検索機能 ←これ
- [] 保存機能
- [] テスト
レビューコメントプレフィックス
プルリクエストのコメントを、どう対応して欲しいのかがわかりやすいのでプレフィックスをつける。(参考)
対応優先度
must > nits > imo > tips
使用例
- must: こうしないとセキュリティ上問題があります
- nits: この処理はcontrollerではなくmodelに書くべきっぽい
- imo: こうするとN+1にならずに書けるよ。処理が複雑なのでコメント書いておいて欲しい
- tips: こういうメソッドも同じ処理になる
- question: ここの仕様これでしたっけ？
※ プレフィックスのあるコメントには必ず返信する
※ その開発したことに関連する議論はissueかMRのコメントに残しておく。(slackで「コメントしたので確認してください」などに留めておく。)
実装者は nits や imo に対し
- 対応しないと判断したときは「〜〜という理由で今回は対応しません」
- 対応したらcommitのハッシュをつけて 「ffec3a97 で対応しました！」
とコメントに記して、レビュアーにどうすることにしたかは伝え、全てのコメントに返信するようにする。
プルリクエストのマージルール
- レビュアーを1人決め、アサインする。
- レビュアーはコメントをして、以下の条件で
Approveボタンを押す。 -
Approveボタンが押されたら、実装者がマージする。
Approve条件
- 自分がした全てのプレフィックスコメントに実装者からの対応がある
- 対応に納得し本番に組み込んでもいいと思える
最後に
ここまで書きましたが、あくまでこれは私が所属したプロジェクトでは上記のように運用したというものであって、
もしかすると他の運用方法の方がもっと効率よくパフォーマンスを出せたかもしれないです。
ただ、Git運用についてはスタンダードと言えるものは存在せず
- プロジェクトの属性(メンバーの経験年数、人数規模、プロジェクト内容)
- 受託/自社サービス
などの要因で変わるものだと思ってます。
そのため、プロジェクト開始時期にメンバーと相談しながら、PMやLEが決定していくのがいいかと思います。
また、運用してみて問題が出た場合には初期の運用案に拘らず柔軟に変更を加えることも大事です。
(運用方法にこだわりすぎたあまり、遅延が発生し、炎上したプロジェクトは私も見てきました。)
これを見た方が、少しでも参考になれば幸いです。