PR (Pull Request)

Category
Published
Updated

Pull Request（リポジトリ共有式）

GitHub初心者はForkしない方のPull Requestから入門しよう - QNYP Blog

Pull Request (PR) には 2 種類ある

  1. 他の人のリポジトリを自分のGitHubアカウントにFork（コピー）してきて、変更を加えて、それを元のリポジトリに取り込んでもらうようにリクエストを送信する（Fork式）
  2. 同じリポジトリを共有して、その中だけで行うPull Request（リポジトリ共有式）

＊リポジトリ共有式 / Fork式 は便宜上の呼称（正式名称ではない）

  • リポジトリ共有式は、Fork式に比べると操作が簡単でわかりやすく、多くの人にとってはこちらの方が日常的に使いやすい
  • GitHub社も社内の開発では、リポジトリ共有式Pull Request を使うことが多いらしい

GitHubでは誰もgithub/githubのフォークを持っていません。同じレポジトリのブランチ同士でプルリクエストを行なっています。

  • GitHub Flow
    • リポジトリ共有式のPull Requestを中心にした開発スタイル

日頃からリポジトリ共有式Pull Requestを使っていく

  • 自分でPull Requestを作って自分でマージする習慣をつける
    • 自作自演ならぬ自プルリ自マージ
  • 普段から実践し、Pull Requestを送る側・受ける側の両方に慣れておく

大まかな手順

  1. リモートリポジトリをクローン
  2. ローカルで、Pull Request用のブランチを作成してpush
  3. GitHub上で、Pull Requestを作成
  4. GitHub上で、Pull Requestをマージ

Pull Request 実践

メンバーの動作

  • リモートリポジトリからクローン
% gcl https://github.com/htksn-git/pullreq.git
% cd pullreq
  • PR 用のブランチ作成
  • ファイル編集
  • プッシュ
% gck -b test

% echo "# Hello, Pull Request" > README.md

% ga.
% gc 'README.md を編集'

% gps origin test 
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Writing objects: 100% (3/3), 292 bytes | 292.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
remote: 
remote: Create a pull request for 'test' on GitHub by visiting:
remote:      https://github.com/htksn-git/pullreq/pull/new/test
remote: 
To https://github.com/htksn-git/pullreq.git
 * [new branch]      test -> test
  • ファイル変更やブランチが反映されているか、GitHub のリポジトリを確認
  • Compare & pull request ボタンを押すと、Pull Request作成ページに移動
  • Pull Request作成ページでは、リクエストを送信する相手（通常はリポジトリの管理者）に、どういった変更を加えたのかを説明する内容を記入する
  • Create pull request ボタンを押して、Pull Request を送信
    • これで PR が完了

管理者の動作

＊あくまで今回の流れを確認するためのもので、実際は下記の流れと異なる

  • （管理者として PR の変更内容を確認するため）ローカルに適当なディレクトリを作成する
  • fetch で変更を取得
  • ブランチを確認
  • チェックアウト
  • ファイルの中身を確認
  • 念の為、メインブランチのファイルの中身も確認
% mkdir pullreq-admin
% cd pullreq-admin 

% gi
% grao https://github.com/htksn-git/pullreq.git

% g fetch 
% gbr -a
  remotes/origin/main
  remotes/origin/test

% gck -b test origin/test 
branch 'test' set up to track 'origin/test'.
Switched to a new branch 'test'
~/pullreq-admin (test =)

% c README.md 
# Hello, Pull Request
- edit test

% gck main 
% c README.md 
# Hello, Pull Request
  • 問題がなさそうなら Merge pull request ボタンを使ってマージを実行
  • マージを実行すると、GitHub上でトピックブランチからメインブランチへのマージが行われる
  • マージ済みのブランチを削除する Delete branch ボタンが出現する
    • 通常は元のブランチは不要になるので、遠慮なくボタンを押す
  • リポジトリのトップページを見ると、マージした変更が反映されている

リポジトリ共有式 Pull Request の注意点

  • リポジトリ共有式を行えるということは、そのリポジトリのプッシュ権限を持っているということ
    • リモートのmasterブランチに直接pushできる、ということ
  • 複数人開発でリポジトリ共有式を使う際の注意点としては、誤操作や独断によるmasterブランチへのpushをしないこと
# NG
git push origin main

# OK
git push origin topic-branch

裏を返せば、リポジトリ管理者から見てそういうことをしなさそうに思ってもらえたら、プッシュ権限を与えてもらえるかも、と言えます。

英語？日本語？

俺の考えるコミットメッセージの書き方 - komagataのブログ

  • オープンソースプロジェクトの場合、コミットログ、コメント、Issue などは全て英語で書くことがほとんど
  • 日本語を使っている仕事のプロジェクトでは、日本語を使うところが多いが、コミットログは英語を使うなど、プロジェクト毎のルールがあるのでそれに従う

レビュー依頼する前に気をつけること

GitHubでPull Requestを送ったあとのコメントのやり取りで気をつけること

  • GitHubでPull Requestを送ったあと、コメント欄でやり取りをしながらレビューを進める
    • Pull Request > Files changed
  • この際にコメントが Pending となっている場合、自分以外の他者にはその内容が見えていないので注意
    • Start a review をクリックしてコメントを投稿するとPendingになる
  • そこからさらに Finish your review → コメント → Submit review で公開される