これはなに？
GitHub で Pull-Request を送る際のオススメの流れ
この記事では書かないこと
- コードの書き方
- プロジェクト固有の流儀
- クローズドなプロジェクトでの流れ
- OSS の場合とそこまで変わらないので、参考にはなると思います。
- Pull-Request 作成後の流れ
前提
hubコマンドがインストールされていること
流れ(初回)
1. GitHub レポジトリを見つける
がんばる。
2. git cloneする
下記コマンドで clone 出来ます。OWNER と REPO はそれぞれ対応する値に書き換えます。
ghq などのツールを使用するとレポジトリの管理が楽になりますが、必須ではありません。
$ git clone git@github.com:OWNER/REPO.git
なお、この時点では GitHub 上でレポジトリを clone する必要はありません。
大本のレポジトリ(以降 upstream とします)を clone しましょう。
3. CONTRIBUTING.md などを確認する
そのプロジェクト固有の規約などが存在する場合があります。 そのような規約の多くは、以下に書かれていることが多いでしょう。
README.mdの Contribution セクションCONTRIBUTING.mdISSUE_TEMPLATE.md/PULL_REQUEST_TEMPLATE.md- この2つは
.github/下に存在する場合もあります。
- この2つは
4. git checkout する
変更を行う前に、新しいブランチを作成しそこにチェックアウトします。
$ git checkout -b branch-name
ブランチ名に厳格なレポジトリはそこまで多くないので、ある程度雑な名前でも問題が無いことが多いでしょう。
5. コードを書く、コミットする
コードを書きます。コミットします。
なお、コミットが一つしか無い場合、予め Pull-Request の description をコミットメッセージに書いてしまうと便利です。
6. rebase する
コードを書くのに時間がかかった場合、clone してきた時よりも upstream が更新されていることがあります。 このような場合は、その変更を予め取り込んだ上で Pull-Request を出すとより親切でしょう。
変更を取り込むためには、git rebaseが使用できます(mergeを使用しないのは、趣味です)。
デフォルトブランチが master の場合、以下のコマンドで rebase を行うことが出来ます。
$ git fetch origin $ git rebase origin/master
コンフリクトしたらがんばりましょう。 また、rebase 後にはテストを実行し直しておくと良いでしょう。
7. fork する
fork にはhubコマンドが便利です。
$ hub fork
なお、既に fork 済みの場合でも2重に fork されることは無いため、fork したか覚えてない場合などもとりあえずhub forkしておくと便利です。
8. fork したリモートレポジトリに push する
USER には自分の GitHub のユーザー名を入れます。
$ git push -u USER
9. Pull-Request を作成する
GitHub の Web UI から、該当のレポジトリを訪れるのが便利でしょう。
hub pull-requestコマンドでも作成できますが、Web 上から diff を確認しつつ Pull Request を作成する方をオススメします。
10. マージされる
色々コミュニケーションが必要な場合も多いですが、がんばります。
流れ(2回目以降)
1. git fetchする
$ git fetch origin
2. git checkout する
$ git checkout origin/master $ git checkout -b branch-name
以下は初回の5以降と同じです。
