GitHubを用いた開発フローについて書いてみる

GitHub

職場ではGitHub Enterpriseを使ってるんだけど、僕が今まであんまりチーム開発っぽいことをしていなかったせいか、gitを使っているといってもpush機能付きのsvnを使っているみたいな感じだった。gitで使うコマンドといえばadd, diff, commit, push, pull, mergeぐらいでpull requestを使ってなかった。

でも、最近はチーム開発をするようになったこともあり開発フローも整備し始めたのでその辺をちょっと書いてみる。

GitHubを用いた開発フローといえばgit-flowとGitHub Flowが有名だけれどもどっちも使ってない。

僕が開発しているのは社内システムでバッチアプリなんだけど、git-flowは適用するには複雑すぎるように思えた。GitHub Flowはシンプルなので適用しても良かったけど、普通のOSS開発と同じフローの方が良いかなと思って採用しなかった。普通のOSS開発だったらfork元のリポジトリに権限無いからforkしてpull request送るんだけどそれにあわせた。

開発はGitHub issueを作るとこから始めてる。フローはこんな感じ。

  • GitHub issueを作る。例えばここではissue番号を10とする。
  • 本家からforkした自分のリポジトリにブランチを作成する。feature-10という感じでissue番号を入れる。
  • ブランチで開発を進める。issueとコミットを関連づけるためにコミットコメントに#10のようにissue番号を入れる。
  • ブランチをpushしてpull requestを送る。
  • pull requestをブラウザからauto mergeする。fork元の開発が進んでいてauto merge出来ない時はrebaseしてgit push -fしてる。その辺はpull request後にupstreamに更新が入ったのでrebaseしてconflictを解消してpush -fする話 - wyukawa’s blogと同じ感じです。
  • mergeしたらブラウザからfeature-10を削除
  • ローカルのfeature-10をgit branch -d feature-10およびgit remote prune originで削除

この辺のやり方はAzkabanのhow to contributeを少し参考にしている。Azkabanの場合はブランチ名までは規定してないけれどもブランチ名で悩むよりかは決まってたほうがいいかなと思ってissue番号込みのものにしている。この辺はクラス名が連番なSIer方式と似ているかも。

このやり方だとissueを見たときにissueとpull requestが混ざって表示されるというデメリットがあるんだけど、まあいいかなと思ってる。

issueを使わずにWIP pull request方式を使えばそれを避けることが出来るんだけどね。

ツールとしてはSourceTree, git-completion.bash, git-prompt.shを使ってる。サーバー上で開発するのでそこではSourceTreeは使えないんだけれどもローカルPCにSourceTree入れてコミットグラフを確認している。

まあ、そんな感じです。