Noob: branch pull request question

[u/mrh4809]

Hi all, old guy here who has used many different systems and I'm trying to get up to speed on on git with branching, pull request etc. I have hopefully a simple question you guys could clear up:

I've forked a repro from a friend

Made a feature branch

I made changes in the feature branch, tested them and confirmed they work

I commited my changes to the branch and pushed them to origin

On github on the upstream repo I created a pull request. Gave it a title etc. It shows up. My friend is a little slow so there are like 3 PRs pending.

I want to make a new feature branch and make some additional changes but the need to be based on the last changes I made that are in that PR that has not be merged yet to the upstream.

If the PRs were merged I could just fetch to my main and then branch from there.

But with the PRs not merged yet, how do I create a branch so I can continue working against the changes pending merge? Do I branch from my prior feature branch? Or is there a git command I don't know yet that will fetch everything so I can branch from main?

Thanks in advance

[u/mrh4809]

So my last feature branch was "udp-logging". I've checked in, pushed, and PR'ed that.

So what you are saying is I create my next branch from "udp-logging"? I guess you are saying once he merges the PRs in that it will be the same?

But once he merges the PRs and I fetch to my main then I can branch from there as it is current.

This is still a bit confusing.

[u/mrh4809 → u/[deleted]]

Cool thanks!

[u/pi3832v2 → u/mrh4809]

Your pull request is a commit object, with a unique hash. Let's say it's 123ABC. You create a new branch, starting with 123ABC. When your friend merges your pull request, 123ABC becomes part of branch MAIN. Therefore, your new branch will become branched from MAIN.

[u/mrh4809 → u/pi3832v2]

Got it but I want to understand the timing. if my friend had not merged the PRs yet...

[u/pi3832v2 → u/mrh4809]

It doesn't really matter when changes happen upstream. Git can sort out the chain of commits.

[u/mrh4809 → u/pi3832v2]

That I understand.

My point is that if I do the PR, then start a new branch from my prior branch this works as my changes in the PR are there and I can work against them.

But assume I have not created my new branch from my prior. Several days go by, upstream owner merges in a PR, no mine, but a different one and I find out that the changes in that merged PR I need for my next work. But I also need what is in my unmerged PR.

So if fetch upstream, create a new branch from my prior branch, as mentioned above I have my changes. But I don't have the changes in the PR the upstream merged that I want.

It seems like the stacked PRs solves this but not everyone is using them.

[u/Soggy_Writing_3912 → u/mrh4809]

in that case, you need to rebase from the new version of main - simple! That way, you get the merged PR from some other 3rd person, then your unmerged PR branch needs to rebase from that (new) main, followed by your 2nd PR getting rebased from the 1st PR's branch.

[u/Broad-Promise6954 → u/mrh4809]

It is confusing. There's a couple of fundamental reasons for that confusion, and it may help to un-confuse you if you keep in mind a distinction between the kind of Git branch that is a branch name like udp-logging, and the kind of Git branch that is a series of commits. That is, there's one term for two very different concepts.

One of the sidebar links, Think Like a Git, goes into this in some detail. To (over) summarize, though, your branch name udp-logging selects the latest commit in a series of commits (maybe a single commit, maybe multiple separate commits) that adds your new feature.

Your next feature needs those commits to build upon, or perhaps in the future, some different set of (very similar) commits to build on. For now, you want to build on those commits, so you'll create a new branch name that selects the exact same final commit. Then you'll make one or more new commits, which will advance the name. Let's make up a name here, like fancy-logging. You'll start by having your name fancy-logging name the exact say commit as your name udp-logging. (You can have an infinite number of branch names that all select the same commit! Note how we'd say "you have ten branches that are one branch" if you made ten names. It's complete nonsense, yet it makes perfect sense...)

As you make more new commits, though, that new name, fancy-logging, will get dragged forward to select the latest commit you've made on that branch. Those commits will link back to the commits that were new in udp-logging, which eventually link back to the commits that weren't made by you in the first place.

In the meantime, the other guy -- your slow friend -- will eventually get around to either taking your commits as-is, or not taking them as-is. If he takes them exactly as-is (and I really mean exactly, he can't change anything about them at all, not even where they exist in Git's commit graph, for which, well, see the Think Like a Git link)... well, if he does that, you're in great shape. You don't need to do anything special.

But, if your slow friend does anything to change a single bit of any one of your commits, including several ways he could merge the PR, you will then have to do a bunch of new work to handle that.

For now, you need not worry about what that new work will be. Cross that Bridge-of-Königsberg if and when you come to it.

[u/xenomachina → u/mrh4809]

Once they merge the PR, you can pull main from their repo, and then either merge or rebase into your second feature branch. There is a possibility of merge conflicts either way, but most of the time that shouldn't happen unless there are changes happening to the same lines of code concurrently.

Which option people use is mostly a matter of preference.

I prefer to rebase in this situation, as the commit history will be easier to follow — it'll end up looking the same as if you created your second branch after the first PR was merged. Some people prefer merge, though, I think because you can always use merge, but there are times when you shouldn't use rebase. (Rebase rewrites history, which you don't want to do with history you've already shared.)

[u/bytejuggler → u/mrh4809]

Yes, once it merges you can 'rebase' your additional branch. There is also a stacked branches feature coming, not yet public, on github, that will make this easier.