おそらくはそれさえも平凡な日々

あらすじ

ikachanを導入しようとした所、AnySanがssl未対応だったのでpullreq送ろうとしたらすでに同僚のmix3先生がpullreqしていて、mix3++であった。しかし、masterブランチからpullreq送るのは良くないよねってことで練習のためにtopicブランチを切ってpullreqを送り直してもらうなどした。早く取り込まれるといいね。

以下説明。

% git config —global push.default simple

本題とはあまり関係ないんですけど、この設定をしておくと % git push したときに分かりづらい挙動にならないので設定しておくと良いと思います。Git2.0からはこの動きがdefaultになるようです。

ブラウザでforkしてそのリポジトリをcloneする

そのまんまですね。以前forkしていてそのリポジトリが古くなってた場合は追随する方法もありますが、わからない場合は消してforkし直しましょう。

% git checkout -b feature/hogehoge ってやってbranch作る

masterで作業せずにすぐブランチを切ります。branch名は、機能追加はfeature/、ドキュメンテーションはdoc/、バグフィクスはfix/とかつけておくとわかりやすくて良いんじゃないかと最近思っております。

変更してコミットする

なるべく1commitにまとめましょう。少なくとも、作業の試行錯誤が見えるような汚いcommit logを残さないように。

コミットメッセージはなるべく英語で書きましょう。

% git push origin feature/hogehoge として修正をpushする

ここでおもむろに % git push とかすると以下の様なエラーが出ます。

[Songmu]$ git push
fatal: The current branch feature/hogehoge has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin feature/hogehoge

% git push —set-upstream origin feature/hogehoge するといいよ！て書いてあるのでありがたくコピペして実行するとちゃんとリモートブランチが作られます。

ブラウザからpull request

そのまんま。これもまたなるべく英語でメッセージを書きましょう。相手が日本人でも、なるべく公開の場では英語でやり取りして、IRCとかで日本語で相談するのがいいんじゃないかなーと最近思います。

あとはmergeされるのを待ちましょう。残念ながらrejectされてしまうこともあるかもしれませんがめげないで頑張りましょう。

落穂拾い

pullreq後、作者から修正要望がついた場合は？

修正内容をブランチにcommitしてpushすれば大丈夫です。もう、ブランチからオプション無しのgit pushするだけでremoteに反映されるようになっています。

pullreqがmergeされるなり決着がついた場合は？

今後あまり継続的にpullreqを送らないのであれば、forkしたリポジトリを消してしまっても良いでしょう。しばらくたってpullreqを送りたくなったらまたforkすれば良いのです。

今後もforkしたリポジトリを本体に追随させていきたい場合は？

fork元のオリジナルのリポジトリを登録する。

% git remote add upstream git://github.com/...

masterブランチで定期的に追随して自分のリモートにもpushする。

% git checkout master
% git pull upstream master
% git push

複数の機能や項目をpullreqしたい場合は？

個別にブランチを切って、別々にpullreqを送りましょう。

pull requestが取り込まれる前にその機能を使いたい場合は？

複数pullreqを送っていてその両方の機能を手元では使いたいとかそういう場合は、oreoreブランチを作ってそこにbranchを両方マージして使ったりしています。