2014-04-02 WIPブランチをPull Requestする運用をためした
最近はWIP(work in progress)ブランチをGitHubにPull Requestするようにしている。
GitHubのPull Requstの仕様としてブランチ名で追跡している(?)ので、後からブランチにコミットを追加してもきちんとPull Requestページにも追加されるし、git rebase
などでコミットをひとつにまとめても問題ない。
そこで作業中(WIP)のブランチをとりあえずPull Requestするのがこのやりかた。
Pull Requestを作業完了してから実施すると、途中で指摘すれば修正できたけど作りきってしまったものをいまさら修正できないといった状況になることがある。コーディングに限らず、一般的な話としても、作業前や作業中に進捗を報告したほうが良いのと同じ理屈で、作業中のものでもPull Requestしておけば、それが見える可能性が増える、と。
例を書いてみる。git-flowにしたがっているとして。
issue番号でブランチをつくる。
git flow start feature 123
空コミットをつくる。
git commit --allow-empty
forkしてあるリポジトリにpush。
git push origin feature/123
GitHubでPull Requestする。Pull Requestには[WIP]などの目印があった方が良いかも(そのままmasterやdevelopにマージされるとログが汚れるので)。
で、作業。ガンガンコミットしてガンガンgit push
する。git push
すると、それがPull Requestに追加されていく。
作業を完了し、レビューもOKとなったら、コミットを整理し、git push -f
してPull Requestに反映させる。
git rebase -i develop
git push -f origin feature/123
GitHubでPull Requestをマージする。
まだ、検証中で、ひとによってはgit push -f
を嫌がられたりしてる。別Pull Requestを用意した方が安全だろうけど、WIPブランチのPull Requestの処理が面倒なので、このフローが楽じゃないかと。
作業途中を見せるのは大切だし、最終的なコミットログを美しく保つことは大切だと思うので、この運用フローは結構良いんじゃないかと思う。
参考
- http://qiita.com/a-suenami/items/129e09f8550f31e4c2da
- http://www.slideshare.net/asuenami/wip-pr
- http://a-suenami.hatenablog.com/entry/2013/12/06/235644
(末並さんばっかりだな)