前提
過去のチームといまのチームでどうやっているかの話
master以外なら force push 可能なことが条件
コミットコメント
一行で概要
WhyやHowを書かせる。
WhereやWhatはいらん、diffを見ればわかる。
(必要なら)詳細
なんでここにこういうことをした？
という細かい説明。
時間に追われてdirty hackをせざるを得なかったのならここにも書いて欲しい。
書かずに変なことしたら俺がハリセン
issueだのメモだのへのリンクでもいい
諸注意
日本語OK
英語オンリーにするとみんな面倒臭がって little change for debug とか平然と入れる
詳しく書かせたいし読むのに苦労したくないので日本語を許す
コミットのタイミングと粒度
粒度はできるだけ細かく。
１コミット単位でレビュワーがお前何がしたかった？をみるため。
レビュー中にレビューが入った部分は歴史改変せずにそのままcommitしてpush。レビュワーが差分見るときに困る。
当然歴史が汚くなるので(特にレビュー指摘分のコミット)merge前に歴史改変して綺麗にすること。
ブランチ名
issue-XXX/(大分類名)/ブランチ名 で命名
issue-123/chat_timeline/extract-url_link みたいな感じ
issueに書くこと
Readyの条件
Doneの条件
背景、前提、どのUXやfeatureの充足を目的とするか
留意事項、注意すべきこと
Pull Requestに書くこと
PRの大雑把な目的
issue のリンク
PRの前提条件
PRで実装、変更、改廃した機能
PRの懸念事項
PRでやりたかったこと(目的)とどうしたか、なぜそうしたか、どのように実現したか
ほかにレビュワーに見て欲しいこと(この書き方ダサくない？もっといいやり方ない？ここどう思う？)
PRを作ったらチャットシステムに簡単な説明付けて依頼
@レビュワー URLリンクがタイムラインに貼られた時の概要展開機能のPRです。レビューお願いします
https://github.com/hoge/fuga/pull-request/123
こんな書き方したらハリセン
@レビュワー https://github.com/hoge/fuga/pull-request/123
merge
git fetch
git rebase origin/source_branch
git checkout source_branch
git merge --no-ff feature_branch
git push origin source_branch
merge --no-ff は必須。切り戻しが楽になる。
良い子のお約束条項
- PRを長時間放置するレビュワーはハリセン
- レビュワーが長時間放置せざるを得ない体勢を作ったリーダーもハリセン
- 着手せず長期放置したissueは信用するな。チェックしろ。特にreadyとdoneの条件が信用できない。必要なら再度issueを作り直せ。
- ブランチは一度切ってから長時間放置するな。鮮度が落ちないうちにmergeしろ。できないならreadyの判断か優先度判断したサイドの能力に問題がある。
- ブランチ切ったからにはデプロイまでしなければいけないという考えは誤りだ。未知の懸念を発見したら手を挙げる勇気を持て。我々はすべてを先に見通す全智の能力は持たないが、新たに見つけた課題に対処する勇気と賢さはあるはずだ。