Skip to content

DNET_GithubPullRequest

nishi_74322014 edited this page Sep 11, 2026 · 1 revision

Github - Pull Request関連

概要

GitHub の Pull Request 周りで気が付いたことのメモ。

Pull Request一覧

Filters

Issue(Github - Issue、Label、Milestone関連)と同様にFiltersを実行できる。

既定で以下が適用されている。

is:pr is:open
  • ソート
    ソートを選択してソートできる。
    • Newest
    • Oldest
    • Most commented
    • Least commented
    • Recently updated
    • Least recently updated

多分、Filters で組み合わせできると思う。

Label

Issue(Github - Issue、Label、Milestone関連)と同様にLabelを設定できるが、
Pull requestはIssueに対応付けるので、
Pull request側にLabelを張らない事が多い。

Milestone

Issue(Github - Issue、Label、Milestone関連)と同様にMilestoneを設定できる。

Pull Requestの送信方法

Repository間

  • Fork元のRepositoryに対してPull Requestを送信することができる。
  • Public RepositoryとPrivate Repository間ではPull Requestを送信できない(裏技)。

Branch間

  • Branch元のBranchに対してPull Requestを送信することができる。
  • Branchする時は、Branch元のブランチを選択・表示させた状態で、
    BranchのDropDownのFind or create a branchに存在しないBranchを入力する。

Pull Requestの作法

CONTRIBUTING.md

CONTRIBUTING.mdに記載されている貢献(コントリビュート)の作法に従う
Github - Markdown関連の「CONTRIBUTING.md」の該当節を参照)。

featureブランチ

  • Pull Requestを作成にはfeatureブランチを作成する必要があります。

    • featureブランチの修正後、都度Pull Requestを送ってレビューを依頼します。
    • featureブランチに異なるIssue(問題やエンハンス)のタスクの修正を混ぜてはいけません。
  • 複数のfeatureブランチ

    • Pull Requestのサイズが大きくなりレビューが困難になる場合は、
      • 複数のfeatureブランチを作成し、複数のブランチ間のPull Requestを送信します。
      • 複数のブランチ間のPull Requestに対して、レビューを行います。
    • そのブランチで、複数のPull Requestをマージして束ね、
      • Fork元のブランチに集約されたPull Requestを送付します。
      • 集約されたPull Requestには、レビューの為の個々のPull Requestのリンクを張ります。

Pull Requestのサイズ

  • レビューし易いサイズに分割
    Pull RequestのレビューのためにPull Requestのサイズを小さくします。

  • 1 Issue 1〜n Pull Request
    1つのPull Requestの中に複数のIssue(問題やエンハンス)のタスクが存在する場合、
    レビューがボトルネックになるので、問題やエンハンスのタスク毎にPull Requestを作成します。

  • 不要な修正もコミットしないで下さい。

    • IDEやEditorによりインデントが変更されるような修正。
    • 誤った修正を再度修正するような修正(スラッシングを避ける)。

Pull Requestの送信前

Pull Requestの送信前に(若しくはPushする前に)、
Pull Requestを送る先のブランチをPullする。

  • より良いプルリクエストのための10のヒント | Yakst
    https://yakst.com/ja/posts/1625
    • Pull Requestが古くなってきた時にスラッシングが起きる(長い議論のためであることが多い)。

Pull RequestでIssueをClose

Pull Requestの送信後

Pull Request送信後の送信元リポジトリの更新

Pull Request送信後に送信元リポジトリを更新した場合の動作は、

  • Pull Requestに更新が反映される。
  • Files changedに結果が反映されるには時間差がある。

となります。

従って、

  • (Files changedに反映されていないだけなので、)そのまま、mergeしてもよし、
  • レビュー等を急いでいるときはCloseして、再度、Pull Requestを投げてもよし。

です。

Pull Requestのコンフリクトの解消

Pull Requestのコンフリクトの解消

その他

参考

移行メモ

  • 元 Wiki の「概要」は空だったため、ページの位置付けを示す 1 行を補った。
  • 元 Wiki の「CONTRIBUTING.md」の見出しは同ページ内の存在しないアンカ (#w5998e01)を指していた。当該アンカは Github - Markdown関連 側の見出しのものであるため、 そちらへの参照に置き換えた。
  • 「Milestone」の「同様にと同様に」の重複を除去した。
  • 元 Wiki では見出しそのものが他ページへのリンクになっていた箇所 (「Pull Requestのコンフリクトの解消」「その他」配下)は、 GitHub Wiki では見出しからアンカが生成されるため、 見出しをプレーン・テキストとし、リンクは直下の本文(箇条書き)に置いた。
  • PukiWiki のページ内アンカ(#xxxxxxxx)は GitHub Wiki では再現できないため、 同一ページ内のアンカは見出しから生成されるアンカに張り替え、 他ページのアンカを指すリンクは「〜(ページ名 の該当節を参照)」の形に置き換えた。

Tags: 移行, GitHub, Pull Request, レビュー, featureブランチ, Issue, CONTRIBUTING.md, Fork

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

(未着手)

開発基盤部会 Wiki

移行管理: DONETODO

Clone this wiki locally