contributing/workflow/pr_review_guidelines

[giscus[bot]]

contributing/workflow/pr_review_guidelines

From a high level, the ideal life cycle of a pull request looks like the following: A contributor opens a PR that fixes a specific problem (optimally closing a GitHub issue or implementing a propos...

https://docs.godotengine.org/en/latest/contributing/workflow/pr_review_guidelines.html

[dustdfg]

Looks like this article is about what to do. But I want to tell about Github feature which will easier life for those who do reviews and will make IN barrier a bit smaller. Before today I needed to manually add persons clone of repo as remote, fetch it checkout to branch I need... But today I learned that Github provides refs directly to PR's. Running git ls-remote will show you them

...
f8c156d40bccbcdc78930baecdf02d2fd15df97b	refs/pull/99102/merge
7fcf3c491d2c11e8c8ef8f3ea360cceff9d3539b	refs/pull/99107/head
08f7fe36754ac4609a18be8e5ae383b91331bae8	refs/pull/99107/merge
ce608dcbf7a8e49a9f6b7f1c6d6d3be9f587275a	refs/pull/99108/head
...

You can fetch them git fetch origin pull/<ID>/head and checkout then to FETCH_HEAD or fetch them to named branch git fetch origin pull/<ID>/head:<branch_name>

If you want to test how it will behave after merge on top of master you can use merge instead of head in the ref.

For myself personally I added to my git config following aliases:

[alias]
	pr-head = "!git fetch origin pull/$1/head:pr-$1-head && git checkout pr-$1-head #"
[alias]
	pr-merge = "!git fetch origin pull/$1/merge:pr-$1-merge && git checkout pr-$1-merge #"

Which could be than called as git pr-head 4567 which will create and checkout pr-4567-head branch in one command. Hope it was useful for you