初めてのPull Request(プルリクエスト)

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

• はじめに
• オープンソースソフトウェアとは
• GitHub とは
• Rull Requestとは
• Pull Requestを送っていいのか？
• まずは fork する
• 作業をどこでするか？
• ローカルで作業する場合は clone する
• 作業用ブランチを作成する
• ブランチを切り替える
• 作業をする前に確認すること
• 作業をする
• 作業内容を確認しよう
• 差分を確認する
• ビルドができるか？
• テストを実行する
• コミットする
• push する
• Pull Request を送る
• 英語に自信がない場合
• Pull Request を出したらひたすら待つ
• 返事が来たら
• Pull Request を修正する
• Pull Request を rebase する
• 最後に
• Gitに関する書籍を探す

はじめに

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

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

オープンソースソフトウェアとは

ソフトウェアには、企業が作成して販売しているものもあれば、個人やコミュニティが作成公開し、無償で提供されているものもあります。

オープンソースソフトウェア(Open Source Software)とは、ソフトウェアのソースコードが無償で公開されていて、改良や再配布が誰に対しても行うことが許可されているソフトウェアであると定義されています。

オープンソースソフトウェアは OSS と略されます。

GitHub とは

GitHub とは ギットハブと発音します。

Github (https://github.com) は、GitHub, Inc によって運営されています。 GitHub とは、ソフトウェア開発のプラットフォームです。GitHub は、ソフトウェアのソースコードのホスティングサービスでもあります。

ソースコードの管理には、 Gitと呼ばれるバージョン管理システムが利用されています。Git は、 Linux カーネル のバージョン管理システムとして開発されたソフトウェアです。

GitHub は、個人が無償でも使うことができます。

GitHub は、2018年にテックジャイアントのマイクロソフトに買収されました。

Github には、OSSコミュニティや個人、企業などのさまざまな人たちが利用しています。

Rull Requestとは

GitHub には Pull Request という文化があります。それは、プログラムの修正・改善を送りあう文化です。

たとえば、githubで公開されていたOSSのソースコードをダウンロードしてきて、自分が利用している環境で、OSSのソースコードがコンパイルができない、とエラーに遭遇したとします。そのような場合に、自分でソースコードを修正して、コンパイルができるようになったとします。

この時に、自分の修正したソースコードを OSS のリポジトリに提供することができます。このときに行うのが、 Pull Request です。

Pull Request を送っても、即座に、リポジトリのマスターにそのまま反映されるわけではありません。 ソースコードのリポジトリに対して、修正したソースコードを Pull Request します。Pull Request が送信されたリポジトリのオーナーは、そのリクエストの内容を確認し、ソースコードなどの変更点に問題がなければ、マージを行い、リポジトリに変更を取り込んでくれるかもしれません。

Pull Requestを送っていいのか？

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

• Pull Request がウェルカムなリポジトリ
• Pull Request がお断りなリポジトリ

Pull Request を受け付けてないのに、送ってしまっては意味がありません。
まずは、受け付けているか確認することからはじめましょう。

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

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

まずは fork する

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

forkとは、 Unix の世界では、新しいプロセスを作成するときに fork() と呼ばれるシステムコールを利用しています。Unix のプログラムは fork によって、同じプロセスが２つに分離します。２つのプロセスの１つは親となり、もう１つは子となります。

GitHub の fork は、リポジトリを複製することを意味します。複製したリポジトリのオーナーは自分ですので、自由に編集できます。

作業をどこでするか？

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

• github 上で作業する
• github からローカルの PC などにクローンして作業する

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

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

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

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

ローカルで作業する場合は、リポジトリをローカルにクローンします。

git clone git@github.com:<あなたのアカウント>/<リポジトリ>

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

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

gitのリポジトリには、ブランチという概念があります。gitでソフトウェアを開発する場合には、ブランチを切り替えて、開発の作業を行うことになります。
リポジトリは初めから master ブランチを持っています。リポジトリの master ブランチを編集して、Pull Request をしてしまうとあとで面倒なことになります。必ず、作業用のブランチを作成して、作業ブランチから Pull Request を出しましょう。

以下のコマンドで作業用ブランチを作成します。

git branch hoge-work

ブランチを切り替える

以下のコマンドで作業用ブランチに切り替えます。

git checkout hoge-work

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

git branch

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

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

それはなにか？

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

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

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

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

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

作業をする

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

作業内容を確認しよう

作業を行ったら、変更内容を確認しましょう。

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

上記について、詳しく解説します。

差分を確認する

変更した内容について、差分(diff)をよく、見ましょう。以下のコマンドで変更された部分を表示することができます。何が追加されたか、何が削除されたか、といったことを確認できます。

git diff

diff を見て、目的の変更ができているか、よく確認しましょう。余計なことをしていないかも確認が重要です。もともと編集するつもりのないところまで、変更していないかも確認します。

ビルドができるか？

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

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

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

make

同様に、RustやGo言語,Javaなどビルドしてみると良いでしょう。

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

php -l foo.php

JavaScript であれば、以下のツールを使うのも良いでしょう。

• JSLint
• JSHint
• ESLint
• JSCS

テストを実行する

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

テスト(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 を送る

Gitに関する書籍を探す

Github で Pull Reuqest を送るためには、 Git に慣れているほうが楽に進められますので、Git の勉強をするのも有効です。

• Git をアマゾンで探す
• Git を楽天で探す
• Git をヤフーショッピングで探す

---