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の詳しいやり方は下記のページなどが参考になります。

rebase -i でコミットをまとめる

ただ、あまり大きなPull Requestはそもそも送らないというのもマナーかもしれません。
 

まとめ


かなりざっくりとしたまとめですが、何かのお役に立てれば幸いです。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください