Pull Requestをするためのまとめ
こんにちは、tatsyです。
GithubでPull Request (以下PR) を送る機会があったので、参考にしたページなどをまとめておきます。
Pull Requestのやり方
PRの基本的な流れについては以下のページがとても詳しく解説してくださっています。
GithubでForkしてからPull Requestをするまでの流れ
気持ちがはやりすぎてFork後にbranchを作り忘れないようにすれば、おおむね問題なくPRまではいけると思います。
Pull Requestを送る前の確認事項
PRを送る前には以下の注意事項をチェックしたほうが、いろいろと良いと思います。
1. テストをちゃんとする
これは慣れないうちは結構大変なのですが、Github上で公開されていて、それなりにコミッターのいるプロジェクトだと、必ずコードはテストされています(今さら言う必要ないかもですが)。
ですので何か機能を追加してPRする場合には、自分が足した機能がちゃんと動くかテストしておきましょう。
多くの場合は既存のテストに少しコードを追加するだけで大丈夫だと思います。
また、Code Coverageなどを取っているプロジェクトであれば、ForkしたrepositoryでもTravis CIなどを使ってテストを実行して、Coverageを取っておきましょう。
その際、Coverageが大きく低下することのないように、なるべく100%近くのCoverageを目指すとよいのかなと思います。
2. コーディング・ルールの確認
多くのプロジェクトにはコーディング・ルールが存在しているので、自分のコードがそのルールに従っているかどうかを確認します。
例えば
- 関数定義やif文で使う’{‘は続けて入力するのか、改行して入力するのか
- タブの幅
などなどです。
Node.js等の環境ならJSLint等を使って定義されているルール・チェッカーを利用すると簡単にコーディング・ルールがチェックできます。
3. commitをsquashしてまとめる
意外と見落としがち(？)なポイントですが、1回のPull Requestを送るのにcommitが大量にあると、なんかカッコ悪いですし、変更を追うのも大変です。
ですので、git rebase -iをつかってcommitをまとめておくと親切です。中にはPRする前にbranch上のcommitを1つにまとめるように指示しているプロジェクトもあります。
squashの詳しいやり方は下記のページなどが参考になります。
ただ、あまり大きなPull Requestはそもそも送らないというのもマナーかもしれません。
まとめ
かなりざっくりとしたまとめですが、何かのお役に立てれば幸いです。