2009/01/14 (水)
■ github で人のコードをいじる「前」にforkする必要はない

git/github を使い始めてほぼ1週間ぐらい。よくできた分散SCMだなぁ、とおもう。とくに rebase とか stash なんか、svk でももちろんできるけどこういう機能が最初からついてるのは素敵。
で、github にプロジェクトをおいておくと fork ボタンがあってすぐに fork していじって commit/push して pull request ってのが素敵なわけだけど、とくにコミットもしないのにとりあえず fork だけしておく、っていうのがたまにみかけるのだけど、それって必要ないよね、って話。(や、別にやるなということではなく、単に勘違いしてやっているのもあるのではないか?と思ったりするので)
Rails on the Run - How to use github and submit a patch とかで、「とりあえず "fork" ボタンをおして fork したレポジトリをつくりましょう」とか書いてあるのでそれが原因なのかもしれないけど、git でとってきたプロジェクトにローカルパッチをあてるのに fork は必要ないです。
git clone git://github.com/miyagawa/remedie.git cd remedie # ファイルを編集 git ci ...
ローカルにある git の作業用ディレクトリは push されるまで remote (origin) とは関係ないので、パッチをあてていくら commit してもまったく問題ない。し、git://github.com/... で clone しているのでそもそも push することはできない。
You can't push to git://github.com/user/repo.git Use git@github.com:user/repo.git
ちなみにこうやってパッチをあてた状態で remote からとってくるときは git pull でなくて git pull --rebase したほうが精神的にいいかもしれない(--rebase はローカルのパッチをいったんなかったことにしたあと pull で最新版にして再度アプライする)。
で、このローカルの変更を master に反映したい(してもらいたい)ときにはじめて、github 上で fork ボタンをおして fork をつくり、git remote add myfork git@github.com:username/remedie.git で remote に追加、git push myfork master で fork に対して push、でもって pull request を送るという手順がいいんじゃないかなとおもう(origin, myfork という名前が気に食わなければ .git/config を編集するなりして upstream, origin という具合に変更すればいいんすかね)。
まぁ fork ボタンを押すことで元の作者に「fork したよ」というメッセージが伝わるので、自分に対するモチベーション/プレッシャーをかけるという意味では先に forkしてしまう、というのもアリかもしれませんがね。