読者です 読者をやめる 読者になる 読者になる

by shigemk2

当面は技術的なことしか書かない

Git x Pull Request ~ チーム開発最終奥義 #phpcon2012

PHPカンファレンス 2012

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のなにがよいか

  • パッチのやりとりが可視化され、オープンで、記録がのこる
  • 該当のコードの責任を持つ人がいる
  • 変更されるコードをもとに議論が出来る

GitHubをじゃかじゃか使おうよ。

ツーマンセル(ペアプロではない)で、チーム内レビューを行う。

ブランチを多段にし、patchを小さくすることで、レビューのコストを下げる。
というか、ブランチが巨大になるなら、多段ブランチを検討したほうがよいでしょう。

PRをすることで、進行しているプロジェクトや他人のコードも把握できるようになる。
コピペ元ごと殲滅する機会が出来る。

うまくやるコツ

  • リリースを出来るだけ細かくすること(大きなdiffはコスト高い)
  • 小さめのチームに分割する(コードレビューする機会が増える)
  • GitはSVNの互換ではないので、開発フローを構築から見直すべし
  • で、上記のモデルはそのまま適用されるべきものではないので、ノウハウを共有してアレンジすること