はじめてgithubでプルリクエストして本家に取り込まれるまでを体験したのでメモ。

プルリクエスト対象

今回プルリクエストしてみたのは、 droparea というjQueryプラグインです。
簡単な2行ほどの修正をプルリクエストしてみました。

事前に読んでおくべきページ

まずはここらへんを読んで、作業の流れをイメージをしておく。

手順

cloneする

作業するディレクトリで、

$ git clone git@github.com:roundrop/droparea.git

本家をupstreamという名前で登録しておく

git remote add <つけたい名前> git://…
で、git://…のURLに名前をつけておくことができます(エイリアスのようなイメージです)。
本家のリポジトリはupstreamという名前にするのが慣例のようです。

$ cd droparea
$ git remote add upstream git://github.com/gokercebeci/droparea.git

これで、git://github.com/gokercebeci/droparea.git という長いのを打たなくても、upstreamという短い名前で指定できるようになりました。

作業用ブランチをつくる

今回はstartメソッドに引数を追加する変更を行う予定だったので、“add_args_to_start_method_spike“という名前のブランチをつくりました。

$ git branch add_args_to_start_method_spike

作業用ブランチに切り替える

gitはcheckoutでブランチに切り替えます。
Subversionのcheckoutとは全然ノリが違う。

$ git checkout add_args_to_start_method_spike

修正する

作業用ブランチで修正作業をします。
修正したらaddして、commitします。

ひとまず修正したspikeをpushする

spikeをpushします。
これをやるとgithubの自分のとこに登録されます。

$ git push origin add_args_to_start_method_spike

本家の変更(こっちの作業中に更新されているもの)を取り込む

今回は作業中に本家が変更されることはありませんでしたが。

  1. masterに移動(普段開発が行われているブランチに移動する。 masterじゃないプロジェクトもあるので要確認!
    $ git checkout master
    
  2. upstreamにmasterを同期させる
    $ git pull upstream master
    
  3. spikeに切り替えて
    $ git checkout add_args_to_start_method_spike
    
  4. rebaseすることで変更に追随する
    $ git rebase master add_args_to_start_method_spike
    

    ※rebase することにより、自分が加えた変更が、取り込んだ本家の変更の後に移動する

pull request 用のブランチを作る

  1. spikeに移動
    $ git checkout add_args_to_start_method_spike
    
  2. プルリクエスト用ブランチを作成
    _spikeを抜いた名前でプルリクエスト用ブランチを作成します。
    “git checkout -b <作成するブランチ名> でブランチの作成とそのブランチへの切り替えを一発でやれます。
    $ git checkout -b add_args_to_start_method
    
  3. コミットを1つにまとめる
    自分の修正作業で複数コミットしたとしても、プルリクエスト送るときには1コミットにまとめてきれいな形にしておく。
    $ git rebase -i master
    

    詳細は以下の引用を参照。

git rebase -iで全差分を1 commitにまとめるには、2個目以降のcommitを全部squash指定します。たとえば次のような内容がエディタに表示されたとしましょう。


pick 12ca2a5 感想を追記
pick bd66e17 コナミコマンドについてREADMEに追記(ネタバレ)

# Rebase bdd3996..bd66e17 onto bdd3996
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

このような場合、次のように修正してセーブ・終了します。


pick 12ca2a5 感想を追記
squash bd66e17 コナミコマンドについてREADMEに追記(ネタバレ)

# Rebase bdd3996..bd66e17 onto bdd3996
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

すると次に2個分を1個にまとめたcommitのログを書くよう求められますので、適当に書いてセーブしましょう。これでmyFeatureSpike上の複数commitがmyFeatureブランチ上では1 commitにまとまった状態になりました。

GitHubへpull requestする際のベストプラクティス – hnwの日記

プルリクエスト用ブランチをリモートへpush

$ git checkout add_args_to_start_method
$ git push origin add_args_to_start_method

ブラウザからプルリクエストする

  1. 対象ブランチを選んでおいて、pull requestボタンを押す
  2. タイトルと内容を書くフォームが出る
  3. タイトルですべてを言い表しているなら内容は書かなくてもいいような感じ

2012/03/05 追記

やりとりのスクショを追加