2015/12/31 追記
GitHub の protected branches によって、Pull Requestのブランチにmasterからマージできる仕組みが導入されました。
Pull Request として出したブランチをrebaseするという操作は推奨されない方法な気がするので、KeepFFは終わらせました。
GitHub Webhookを利用し、プルリクにfast-forwardの状態を表示するKeepFFというWebサービスを作りました。
fast-forward の表示例
fast-forwardとは?
昔、mergeの説明の時にfast-forwardについて少し書いたので、どうぞ。
図で分かるgit-mergeの--ff, --no-ff, --squashの違い http://d.hatena.ne.jp/sinsoku/20111025/1319497900
なぜfast-forwardにすべきなのか
CIを使って検証済みマージ*1をしていても、non fast-forwardの状態でマージすると、メインブランチが壊れてしまう可能性があるためです。
壊れる例
masterとfeature/private_roomでそれぞれ下記のような変更をしていた場合、マージ前にプルリクのテストが通っていたとしても、マージ後のmasterのテストは失敗します。
- master:
user#post_comment text
からuser#post_comment comment: text, reply_to: user
にシグネチャを変更 - feature/private_room: 非公開のチャットルームで会話する機能
fast-forwardプルリクのメリット
fast-forwardのプルリクでCIのテストが通り、stagingでの動作確認も問題なければ、マージしてそのまま自信をもってデプロイできます。 これは、masterを頻繁にデプロイするGitHub Flowと相性が良いです。
Teatro
最後に、KeepFFと一緒に使うと便利なTeatroというWebサービスを紹介します。
Teatro
これは何?
各プルリク用にstaging環境を作ってくれるサービスです。
こんな感じでプルリクにコメントが書かれ、"Open stage"のリンクをクリックするとstaging環境が構築が始まり、少し待つとページが表示されます。
なぜか日本語の情報が少ないですが、OAuth認証とかも動きますし、便利ですよ。
*1:プルリクのテストが通ってからマージすること