Git 合理的なブランチ戦略
crocosの中のひと
Gitを使った開発
Git移行について考える
svn up = git pull
svn ci = git push
という考え方はやめる。
Gitに移行するということは、svnに対応するコマンドを
おぼえることではない。Gitを最大限活用する開発フローを
考える。
- ローカルで気軽にコミット
- ローカルで気軽にブランチを切る
- 賢く、高速なマージ
それを活かしたブランチの戦略を考えるべきである。
Gitのブランチ戦略とは
どのようにブランチを切るか
- 日々の開発
- リリース
- 緊急対応
などをこなすか
A Successful Git Branching Model
http://nvie.com/posts/a-successful-git-branching-model/
Master 常に最新の安定したソースコード カタマリごとにmergeされてる
Hotfix developの完成を待たずにmasterの修正をしたい(緊急BugFix)
Release リリース前の確認を行う。必要(Bugfixなど)があれば修正する リリース前の最終確認
Develop 日々の開発を行う(masterより多くのコミットが存在する)
Feature 複数の異なる機能を並行して開発する。
っていう流れ。
Gitのために、よく考えられたブランチ運用モデル。
様々に運用方法に、柔軟に対応可能。
A Successful Git Branching Modelを実現するツール
gitflow
git-daily
別に必ずしもこの通りやらなければならないということはない。
これを参考に自分の開発チームにアレンジしたらいいんじゃないだろうか。
git-daily
いちいち番号をつけたりしない。
日々でリリースブランチを作る。
Pull Request
コードの変更
複数人で開発するものであれば、
「他人が書いたコード」を変更しなければならないタイミングが必ずある。
1. 依頼タイプ
Bさんがとある修正についてAさんにお願いする。
お願い→修正→差し戻しのコストがかかる。
2. 完全分離増殖タイプ
とあるサービスについてAさんBさんが別々に修正する
誰もそのコードに責任を持たなくなるので避けたい
3. 勝手に変更タイプ
Aさんの修正についてBさんが勝手に修正する
3 は、車輪の再発明やコードの不整合が起こりやすいので避けたい。
4. Pull Request
PRというコミュニケーションを取ることで、齟齬や差し戻し、再発明を極力
避けることが出来る。
ブランチ戦略にPRを組み込む
毎度merge前にレビューをしてもらうことで、差し戻しやバグの発生を抑える。
コードレビューを細分化することで、
- 変更のコンテキストが明確になる
- 小さなpatchなので、レビューのコストが下がる
PRのなにがよいか
- パッチのやりとりが可視化され、オープンで、記録がのこる
- 該当のコードの責任を持つ人がいる
- 変更されるコードをもとに議論が出来る
- 小さなpatchで質の高いレビュー
- リファクタリング
GitHubをじゃかじゃか使おうよ。
ツーマンセル(ペアプロではない)で、チーム内レビューを行う。
ブランチを多段にし、patchを小さくすることで、レビューのコストを下げる。
というか、ブランチが巨大になるなら、多段ブランチを検討したほうがよいでしょう。
PRをすることで、進行しているプロジェクトや他人のコードも把握できるようになる。
コピペ元ごと殲滅する機会が出来る。
うまくやるコツ
- リリースを出来るだけ細かくすること(大きなdiffはコスト高い)
- 小さめのチームに分割する(コードレビューする機会が増える)
- GitはSVNの互換ではないので、開発フローを構築から見直すべし
- で、上記のモデルはそのまま適用されるべきものではないので、ノウハウを共有してアレンジすること
