reinvented wheels

車輪の再発明勉強法を実践するブログ

GitHubを用いた開発フロー(GitHub Flow)のまとめ

GitHubを用いたチームプロジェクト進行の有名なベストプラクティスの一つとして、GitHub Flowという手法がGitHubのstaffであるScott Chaconによって主張されています(GitHub Flow – Scott Chacon)[1]本エントリはこの記事を自分なりに解釈したまとめです。

GitHub Flow?

GitHubのPull Requestを利用した、簡潔なブランチ運用ルールによるチームでの開発フローのこと

GitHub Flowにおける6つのルール

  1. マスターのブランチにあるものは全てデプロイ可能にしておく
  2. 何に取り組んでいるのか自明な名称のlocalブランチを切って開発を進める
  3. (上記のブランチに対して)定期的に同名のリモートブランチへpushする
  4. 必要なときはいつでもPull Requestを出してチームにレビューを求める
  5. マスターへのmergeは必ず上記のPull Request reviewを通してから。
  6. masterが他開発ブランチをmergeしたらすぐdeployする。

git-flowの問題点

git-flow[3]という標準化されたブランチ運用ルールが既に確立されていますが、Scottによれば以下の様な問題点があるそうです;

  • ルールそのものが複雑。一般的な開発チームに必要とされる以上に複雑。
  • 基本的にCUIで処理される必要がある。
    • (デザイナー等GUIgitクライアントから操作しづらい等の問題？）

つまり、ルールがわかりづらいことそのものが開発コストになるということだと思います。

GitHub flowにおけるブランチ運用ルール

1.masterブランチ: リモートのmasterは常にdeployできる状態を保つ

  • JenkinsなどによるCI管理を積極的に使い、ビルドの清潔を保つ。
  • masterに問題があったときはrevertか、修正mergeで対応されるべきで、rollbackされるべきではない
  • deployedというデプロイ専用ブランチを作っても良いが、普通は行わない。運用ルールはシンプルであればあるほどよいので。
  • また、masterに新機能がmergeされた時はすぐにdeployされるべき。
    • GitHubではHubotを使ってデプロイしている。　

masterを壊すのは絶対ダメ

If you push something to master that is not tested or breaks the build, you break the social contract of the development team and you normally feel pretty bad about it.

2. 開発ブランチ: featureの機能開発は、自明な名称の別ブランチを作って行う

  • featureごとに、最新のmasterからブランチを切って開発を始める。
  • 自明で簡潔な命名を心がける。 ex:new-oauth2-scopes,user-content-cache-key, submodules-init-task or redis2-transition

意識的にこうしておくことで、開発の進捗がブランチ一覧で一目瞭然に

https://img.skitch.com/20110831-x5nyqid885aqnp7t2au5ckw929.png (cited from [1])

さらにgit fetchがそのままTODOリストになる

$ git fetch
remote: Counting objects: 3032, done.
remote: Compressing objects: 100% (947/947), done.
remote: Total 2672 (delta 1993), reused 2328 (delta 1689)
Receiving objects: 100% (2672/2672), 16.45 MiB | 1.04 MiB/s, done.
Resolving deltas: 100% (1993/1993), completed with 213 local objects.
From github.com:github/github
 * [new branch]      charlock-linguist -> origin/charlock-linguist
 * [new branch]      enterprise-non-config -> origin/enterprise-non-config
 * [new branch]      fi-signup  -> origin/fi-signup
   2647a42..4d6d2c2  git-http-server -> origin/git-http-server
 * [new branch]      knyle-style-commits -> origin/knyle-style-commits
   157d2b0..d33e00d  master     -> origin/master
 * [new branch]      menu-behavior-act-i -> origin/menu-behavior-act-i
   ea1c5e2..dfd315a  no-inline-js-config -> origin/no-inline-js-config
 * [new branch]      svg-tests  -> origin/svg-tests
   87bb870..9da23f3  view-modes -> origin/view-modes
 * [new branch]      wild-renaming -> origin/wild-renaming
  • 開発ブランチと同名のremoteブランチを作成して、定期的にpushする。
  • 開発ブランチがremoteにpushされたらCIツールにテストを実行させ、開発レポジトリも常にcleanにできるよう保つとgood

Pull Requestをopenするタイミング

Pull Request: GitHub上でチームでブランチを比較・議論できるGitHubの1機能のこと (git本来のコマンド等ではありません)

  1. 開発ブランチが完成しmasterへのmerge準備ができた時
  2. 現在の開発ブランチのコードについてチームからフィードバックが欲しい時
    • pull request != 完成報告、ということがポイント！

Conclusion

GitHub Flowはブランチの運用方法をシンプルにすることによって、なるべく頻繁にチーム内でのコミュニケーションを取ること、を重視しているようです。 「masterだけは清潔に」、「開発ブランチ名は明確に」、「困ったらすぐPR」。早速実践してみたいと思います。 原典自体は２０１１年に出たもので、割と古い部類のようです。 GitHubを利用した、類似の開発フローがあったらぜひ教えて頂けると嬉しいです。

References