スポンサーリンク

このドキュメントの内容は、以下の通りです。

はじめに


OSS に Pull Request (プルリクエスト) を送ってみたいけど、送っていいのか困っている方向けに書きました。
かつ、プルリクエストの送り方がわからない方向けに、やり方も書いてみました。

Github のお陰で、OSS に貢献するのも簡単になったのではないかと思います。
普段、OSS を使っているばかりだけれど、何らかの貢献がしたいな、と思われている方もいるのではないかと思います。

Pull Requestを送っていいのか?


Pull Request を送っていいかどうかは、確認が必要です。
せっかく、修正や新しい機能を実装しても、受け取ってもらえないと勿体ないです。
リポジトリごとにポリシーが違うので、リポジトリをよく読む必要があります。

  • Pull Request がウェルカムなリポジトリ
  • Pull Request がお断りなリポジトリ
Pull Request を受け付けてないのに、送ってしまっては意味がありません。
まずは、受け付けているか確認することからはじめましょう。

お断りな理由はいろいろあるのでしょうが, github のリポジトリは単なるミラーの場合があります。
例えば、メーリングリストにパッチを送ってね、というのもあります。

Github の場合は、 リポジトリの Pull requests を見れば、Pull Request が対応されるのか確認することができます。

まずは fork する


Pull Request が受け付けられそうだ、ということがわかったら、まずは fork です。
github の Fork というボタンをクリックすれば、リポジトリが Fork されます。

作業をどこでするか?


fork したあとに、作業をする場合に、以下の選択ができます。

  • github 上で作業する
  • github からローカルの PC などにクローンして作業する
github 上でやるほうが、 git コマンドことをあまりよく知らなくても、良さそうなので、実は、 github 上でやるほうが簡単ではないかと思われます。エディタやコマンドラインツールでゴリゴリなにかをやりたい方は、ローカルにクローン(clone)して作業する方が、効率的だったり、便利だったりするのではないでしょうか。

github 上でやる場合は、一文字だけ修正したいとか、些細な修正であれば、 github 上 (ブラウザ上) でやるほうが、楽ちんかもしれません。

あとは、趣味の問題だと思います。

ローカルで作業する場合は clone する


ローカルで作業する場合は、ローカルにクローンします。
git clone git@github.com:<あなたのアカウント>/<リポジトリ>

github でやる場合は、clone は不要です。

作業用ブランチを作成する


master ブランチを編集して、Pull Request をしてしまうとあとで面倒なことになります。
必ず、作業用のブランチを作成して、作業ブランチから Pull Request を出しましょう。

以下の作業用ブランチを作成します。
git branch hoge-work

ブランチを切り替える


作業用ブランチに切り替えます。
git checkout hoge-work

branch コマンドで、現在のブランチを確認できます。
git branch

作業をする前に確認すること


ここまで準備ができれば、作業開始、となるわけですが、その前に、確認しておくべきことがあります。

それはなにか?

そう、コーディングスタイルです。
コーディングスタイルが合ってないと、あとで、指摘されて、修正が必要になります。
もし、一文字だけ修正したいといったタイポ(typo)を直したいだけなら、コーディングスタイルを気にする必要はありません。

どのようなポリシーなのか、確認する必要があります。
一方で、ソースコードを読んでいると、ポリシーが一体どっちなのか、わからないこともあります。
もし調べられるなら、多い方に合わせる、とか、今回の作業対象にしようとしているファイルに合わせるとか、そういった対応が必要です。

コーディングスタイルがまとまっていれば、最初にざっと目を通しましょう。

たとえば、以下のようなことを守って、ソースコードを編集します。

  • スペースの入れ方
  • インデントはスペースなのか、タブなのか
  • 命名規則
  • goto の使い方
  • 戻り値のポリシー

作業をする


clone して、ブランチを作って、ブランチを切り替えたら、作業開始です。
上記で述べた通り、コーディングスタイルに気をつけて、編集しましょう。

作業内容を確認しよう


作業をしたら、変更を確認しましょう。

  • 差分を見る
  • ビルドができるか
  • テストが通るか

差分を確認する


差分(diff)をよく、見ましょう。
git diff

ビルドができるか?


C言語 や C++言語などのコンパイル型の言語の場合は、コンパイルが通るか、確認しましょう。
ビルドが失敗するものを Pull Request しても、無駄なので、ビルドができるかは、確認してから commit/push/Pull Request しましょう。

だいたい make すれば、良いのではないかと思いますが、対象のソフトウェアのビルド手順に従って下さい。だいたい、リポジトリに書いてあると思います。

make する前に、 configure とか、そういったコマンドを叩く必要があるケースもあります。

make

コンパイル型の言語ではなく、スクリプト言語の場合もシンタックスチェックぐらいはしておくべきです。
PHP なら、php コマンドでチェックできます。
ひょっとすると Makefile の中に、シンタックスチェックをするためのターゲットがあるかもしれませんので、確認してみてもいいですね。

php -l foo.php

テストを実行する


ビルドが通ったら、テストです。シンタックスチェックはテストを実行すれば、テストでシンタックスチェックもできてしまうかもしれませんね。

テスト(Unit Test とか) の実行方法もリポジトリごとの手順に従えば良いのですが、 Makefile があれば、ひょっとすると test というターゲットがあるかもしれません。

make でテストが実行できるようになっているのであれば、以下のコマンドでテストができます。

make test

make test が通ったからといって、テストが完了したかどうかは、テストの出来によりますし、今回の作業の中で、ひょっとすると、テストケース自体を追加しないと、テストにならないケースもあるでしょう。

テストが通ったからといって、テストにならないこともありますが、テストをしてから、コミットしましょう。

ソースコードに誤りがあって、それを直した場合は、そもそもテストがされてなかった、ということかもしれません。

サイドエフェクトも考慮して、必ず、テストは実行しましょう。

コミットする


コミット(commit)するときは、コミットのコメントの言語に注意しましょう。
英語でコミットログを書いているか、日本語か、確認してからコミットしましょう。

git commit -a

push する


コミットして、いよいよ、準備ができたら github に push します。

ブランチを指定して、 pull request を送ります。

git push origin hoge-work

Pull Request を送る


クローンした自分のリポジトリを開くと、push したブランチが、おそらく表示されます。
そこから、 New Pull Request が送れます。

コメントを記載できるので、何を目的としているのか記載します。
目的が明確であれば、あとは差分(diff)を見れば、解ってもらえることも多いのではないでしょうか。
差分見れば、わかるから、コメントは適当で良いという意味ではありませんが、差分がコメントを補完して理解してもらえることも実際にある、ということです。

英語に自信がない場合


英語でコメントを書かないといけない、英語に自信がないと、Pull Request を出しにくいかもしれません。
簡単にやったことを書けばいいんです。英語がイマイチでも、コードで伝わることもあります。
まったく自信がない場合は、Google 翻訳とかを使って、翻訳すれば良いでしょう。

Pull Request を出したらひたすら待つ


Pull Request を送ると、そのうち、レビュワーがやってきて、見てくれるでしょう。
レビュワーは、他の国にいる場合、時差があることもあります。

なかなか、返事が来なくても、心配せずに、普段の生活をして待っていましょう。
そのうちレビュワーがきてくれます。

返事にレスをつけたりしても、次のレスがくるまでに時間がかかることもあります。
1日1コメントずつ書き合うになるかもしれませんが、気長にキャッチボールしましょう。

返事が来たら


問題の有無にかかわらず、なんらかのコメントがつくのではないでしょうか。
問題がなければ、そのまま、レビューが進んで、修正せずに、マージされるかもしれません。

もし、Pull Request 自体を修正したほうが良い場合、どういう作業をしたかによるでしょうけど、たとえば、以下のようなコメントがくるかもしれません。

  • インデントがおかしい
  • ここ変数にしなくていいんじゃないの
  • ここはもっと簡単になるんじゃないの
コメントの意図がわからない場合は、コメントにレスをつけて、質問しましょう。

Pull Request を修正する


一度、Pull Request を送った場合に、Pull Request したソースコードをアップデートしたい場合は、 Pull Request を送ったブランチを更新すれば、自動的に Pull Request にcommit/push すれば、 Pull Request に反映されます。

修正作業をしたら、以下のコマンドで、push しましょう。

git commit -a
git push origin hoge-work

必要があれば、レビュワーのコメントに github で、なおしたよ、といった返信をしたら良いのではないでしょうか。

Pull Request を rebase する


Pull Request を修正していく過程で、コミットが増えていきます。
レビューが終わった段階で、そのままマージ・クローズされることもあるかと思いますが、rebase してほしいということもあります。

git rebase を使うと、複数のコミットをまとめることができます。
git log でコミットログを確認します。

git rebase コマンドをたたくと、エディタが実行されるので、squash を指定して、コミットをまとめます。
すべてのコミットに squash を付けてしまうと rebase できないので、最初のコミットはそのまま残しておきます。

AからCまでのコミットをマージしたい場合には、 rebase では X を指定します。
Aを指定して rebase すると B と C がまとまります。
  • C
  • B
  • A
  • X
git push するときは、 -f (fource) で強制的に push します。
これをやると、pull request のレビュー結果がなくなってしまったりしますので、 rebase してね、と言われてからやるのが良いでしょう。
git log
git rebase -i コミットID
git push -f origin hoge-work

最後に


Pull Request を送るのは、緊張するのかもしれませんが、以下のことに気をつけて送れば大丈夫じゃないでしょうか。

  • Pull Request を受け付けているか、作業する前に確認する
  • 必ずブランチを作って、Pull Request を送る
  • コーディングスタイルがあれば、それに従う
  • コンパイル型の言語は、ビルドをする
  • スクリプト言語ならシンタックスチェックをする
  • ユニットテストなどがあれば、変更後にテストを実施する
  • 何がしたいのか明確なコメントをつける
  • 英語が苦手でも、翻訳ツールで英語を書けばよいし、翻訳して読めば良い
  • 時差などがあるので、反応がなかなか来なくても気にしない
  • 心のハードルを勝手に作らず、気にしないで Pull Request を送る

スポンサーリンク
スポンサーリンク
 
いつもシェア、ありがとうございます!


もっと情報を探しませんか?

関連記事

最近の記事

人気のページ

はてなの人気のブックマーク

スポンサーリンク
 

過去ログ

2018 : 01 02 03 04 05 06 07 08 09 10 11 12
2017 : 01 02 03 04 05 06 07 08 09 10 11 12
2016 : 01 02 03 04 05 06 07 08 09 10 11 12
2015 : 01 02 03 04 05 06 07 08 09 10 11 12
2014 : 01 02 03 04 05 06 07 08 09 10 11 12
2013 : 01 02 03 04 05 06 07 08 09 10 11 12
2012 : 01 02 03 04 05 06 07 08 09 10 11 12
2011 : 01 02 03 04 05 06 07 08 09 10 11 12
2010 : 01 02 03 04 05 06 07 08 09 10 11 12
2009 : 01 02 03 04 05 06 07 08 09 10 11 12
2008 : 01 02 03 04 05 06 07 08 09 10 11 12
2007 : 01 02 03 04 05 06 07 08 09 10 11 12
2006 : 01 02 03 04 05 06 07 08 09 10 11 12
2005 : 01 02 03 04 05 06 07 08 09 10 11 12
2004 : 01 02 03 04 05 06 07 08 09 10 11 12
2003 : 01 02 03 04 05 06 07 08 09 10 11 12

サイト

Vim入門

C言語入門

C++入門

JavaScript/Node.js入門

Python入門

FreeBSD入門

Ubuntu入門

セキュリティ入門

パソコン自作入門

ブログ

トップ


プライバシーポリシー