In creating a PR GitHub created a new ref to track the HEAD of that feature branch.We forked a new feature branch from another branch.It left refs/pull/1/head though, as that can be used to recreate the PR at a later time if we choose to restore the branch. When I deleted the PR’s branch from the GitHub UI, it also deleted the branch single-commit-pr. At that point it created a new final merge commit, 3a0f58c, and deleted the merge branch. In this case we can see that when we created the PR, GitHub created dde00c3 as the merge branch this existed until we merged the PR. Single-commit PR with no conflicts merged into target branch.Ī single-commit PR merged into trunk trunk refs/pull/1/merge single-commit-pr 2191af2 f1ea7f1 refs/pull/1/head dde00c3 3a0f58c A single-commit PR merged into trunk You can also jump to the conclusions if you want a summary of what this all means. This post is a bit off-the-cuff, but I hope that by the end of the first or second scenario some of the why and what behind our explorations will start to clear up. ![]() We’ll start simple and end with a conflict and see how the pointers behind the scene track updates in both the target and feature branch. We’re going to construct a series of PRs to establish different scenarios where GitHub is interacting with the PR branch. To that end what a PR is is more or less a view of how a chosen target branch will be once a given changeset has been merged into it, of how a PR will impact the project once it’s done. There’s a catch when conflicts exist though, which we’ll discuss later. The merge branch provides a preview of how the target branch will look after merging the PR. It’s not necessarily the branch from which the PR forked in fact, we can have PRs targeting other PRs and we can have PRs forked from other PRs which target the main branch.Ī PR’s “merge branch” is briefly mentioned in the GitHub Actions docs, but to the best of my searching isn’t defined in their docs beyond a passing mention that diffing views are different when comparing branches than when reading a PR. For many people this is usually master, main, or trunk, but it can be any available branch. It’s the name of the branch into which the PR will merge when it’s merged. The “target branch” is what I often call the base branch. Namely it creates refs/pull/NUMBER/head (which tracks the HEAD of the branch under development) and refs/pull/NUMBER/merge (which previews a merge into the target branch). A branch can be reused later on after it’s merged and deleted, but PRs cannot be deleted.īehind the scenes, GitHub creates its own branches during the life of a PR. Still, a PR mostly refers to a single branch during the time it is developed, and it can only point to one branch. For one, branches are transient while PRs leave a trace of their activity. You may have already known this, but PRs are a separate concept than a branch. Read on to dive in – this is a rather lengthy post because we build up a repo step by step to examine different scenarios that are possible in different PR situations. In this post we’re going to explore the hidden “merge branch” that tracks a PR’s development and see how GitHub uses that merge branch to provide diff views and previews of how the PR will impact the project once merged. Pull Requests involve some “magic” I have taken for granted for a long time, but there are some interesting details behind the curtain. ![]() Recently while I was working on some continuous-integration (CI) test suites for the WordPress Block Editor (Gutenberg) I had to wrestle with some of the details of what happens behind the scenes in a Pull Request (PR) on GitHub and thought I’d share what I learned here in this post.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |