pockestrap

Web Programmer's memo

GitHub で Pull Request を送る際の流れ

これはなに?

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.md
  • ISSUE_TEMPLATE.md / PULL_REQUEST_TEMPLATE.md
    • この2つは.github/下に存在する場合もあります。

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以降と同じです。