実践!Pull Request対応

Ginatra というものがあります。SinatraとGritでできたGitリポジトリビューアです。Githubクローンというよりは、進化版gitwebといった感じ。
機能は良いのですが、いかんせん見た目が今一歩。これをforkして、Twitter Bootstrapを使って簡単によさげな見た目にしていたわけです。
marutanm/ginatra · GitHub
見た目のほかには、erbだったのをhaml化したりとか、ちょっとルーティング変えたりとか。
そうこうしていたらPull Requestがきたのです。なぜか本家のほうではなく、こっちに。なんとも喜ばしいですね!!
せっかくなので、Pull Requestがきたときにどう対応するか、まとめてみましょう。

Auto merging

一番かんたんなのは、 Merge Buttonを使うことですね。
f:id:marutanm:20110927203212p:image

画像の右下にあるのが、それ。これを押すとPull Requestをマージして、クローズまで自動でやってくれます。
コミットログもよきにはからってくれます。ファッキン便利ですね!!
もちろん、Pull Requestに含まれるコミットがどんな変更なのかは事前に確認しましょうね。もちろん、github上で見られます。

The Merge Button · GitHub

pull and push

上記ボタンはGithubが提供してくれる機能ですが、Git単体でリモートリポジトリのコミットを取り込む手段があります。それがgit-pullです。
Pull Requestの内容を確認、問題なければpullします。そしてpushすれば完了ですね。結果的には上記と同じことなので、せっかくgithubを使っているならMerge Buttonを使ったほうがシンプル簡単でいいですね。

fetch and merge (and push)

場合によっては、コミット内容に問題がありそうで素直にPullできないことや、手元で動作確認したいことがあります。そんなときはひとまずfetchし、その後でよろしくmergeしてやりましょう。
コマンドがよくわからなくても、問題なし。よくあるi印をおすとgithubが教えてくれます。
f:id:marutanm:20110927210847p:image

新しくブランチを切って、そこにマージ対象(Pull Requestされたもの)をpull。確認なりしたあとで、masterからmergeしてやります(そしてgithubにpush)。
こんな感じ。

# masterからdocunext-masterブランチを作成、同時にチェックアウト
$ git checkout -b new-branch master
# githubからpull
$ git pull remote/repos.git master
# masterに戻ってマージ、githubにpush
$ git checkout master
$ git merge new-branch
$ git push origin master

fetch and mergeと題しましたが、正確にはブランチをきってpullしていますね。

さて、単純にmergeしたくない場合はどうしましょう?適切にコミットが分割されていればgit-cherry-pickなりできるのですが、必ずしもそうではありません。hunk単位でmergeしたい、どうする?
とりあえずmergeしちゃいましょう、--no-commit指定で。

$ git merge --no-commit --no-ff new-branch

これで、準備完了。あとは、コミットしたくない点をunstageなり何なりしてcommitしましょう。
ちなみに、今回の場合はfast-forwardでマージできてしまうので--no-commitだけ指定だと自動的にコミットされてしまいました。そこで--no-ffも併せて指定して、マージだけをするようにしました。

さて、うまいことマージできたら普段通りにpushしましょう。githubはマージコミットを認識して自動的にPull Requestをクローズしてくれます。便利ですね!

--no-ff
    • no-ffはマージコミットを作成するかどうかの指定なのですが、普段どうするかはリポジトリの方針次第ですよね。今まではあまり気にせずgitまかせでmergeしていたのですが、トピックブランチで機能追加した場合はマージコミットを残したいですが、トピックブランチとするほどではない細かい修正なんかはfast-forwardで一本道にしたいですね、なんとなく。

fast-forwardマージが可能なときに、--no-ff指定あり/なしでマージをしてみると違いはすぐに理解できると思います。git-reset --hard HEAD^ なんかですぐにマージ前の状態に戻せますし。

まとめ

Pull Requestをもらえるとか、とても喜ばしいことですよね。ささやかな修正でもいいので、どんどんコミットを送り付けて互いに幸せになれるといいですね!!(リポジトリによっては指針があって、テスト通したりとか必要なことはもちろん予めやらなくてはなりませんけれども)
せっかくもらったPull Requestには最大限に敬意をはらいつつも、自分にいちばん都合がいいようにマージしたいですね。
gitそしてgithubという素晴らしいツールを最大限に利用し、望ましい形にコミットログを残せるよう、うまいことやりましょう。