-
Notifications
You must be signed in to change notification settings - Fork 0
DNET_GithubPullRequest
GitHub の Pull Request 周りで気が付いたことのメモ。
Issue(Github - Issue、Label、Milestone関連)と同様にFiltersを実行できる。
既定で以下が適用されている。
is:pr is:open
- ソート
ソートを選択してソートできる。- Newest
- Oldest
- Most commented
- Least commented
- Recently updated
- Least recently updated
多分、Filters で組み合わせできると思う。
Issue(Github - Issue、Label、Milestone関連)と同様にLabelを設定できるが、
Pull requestはIssueに対応付けるので、
Pull request側にLabelを張らない事が多い。
Issue(Github - Issue、Label、Milestone関連)と同様にMilestoneを設定できる。
- Fork元のRepositoryに対してPull Requestを送信することができる。
- Public RepositoryとPrivate Repository間ではPull Requestを送信できない(裏技)。
- Branch元のBranchに対してPull Requestを送信することができる。
- Branchする時は、Branch元のブランチを選択・表示させた状態で、
BranchのDropDownのFind or create a branchに存在しないBranchを入力する。
CONTRIBUTING.mdに記載されている貢献(コントリビュート)の作法に従う
(Github - Markdown関連の「CONTRIBUTING.md」の該当節を参照)。
-
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の送信前に(若しくはPushする前に)、
Pull Requestを送る先のブランチをPullする。
- より良いプルリクエストのための10のヒント | Yakst
https://yakst.com/ja/posts/1625- Pull Requestが古くなってきた時にスラッシングが起きる(長い議論のためであることが多い)。
-
Closing issues via commit messages - GitHub Help
https://help.github.com/articles/closing-issues-via-commit-messages/ -
Output_Log: GitHubでコミットとissue(課題)をリンクさせる方法
http://outputlog.blogspot.jp/2011/04/githubissue.html -
Git のコミットメッセージから GitHub 上の Issue を閉じる | 雪猫 ...
http://blog.snowcait.info/2014/09/22/closing-issues-via-commit-messages-on-github/
Pull Request送信後に送信元リポジトリを更新した場合の動作は、
- Pull Requestに更新が反映される。
- Files changedに結果が反映されるには時間差がある。
となります。
従って、
- (Files changedに反映されていないだけなので、)そのまま、mergeしてもよし、
- レビュー等を急いでいるときはCloseして、再度、Pull Requestを投げてもよし。
です。
-
より良いプルリクエストのための10のヒント | Yakst
https://yakst.com/ja/posts/1625 -
[初心者向け]こんなときどうする⁉︎ GitのTips25選! - Sweet Escape
http://keisuke69.hatenablog.jp/entry/2013/12/16/130110 -
Gitでやらかした時に使える19個の奥義 - Qiita
http://qiita.com/muran001/items/dea2bbbaea1260098051
移行メモ
- 元 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
このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。