最近は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

(末並さんばっかりだな)