r/git • u/mrh4809 • 11h ago

Noob: branch pull request question

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

5 Upvotes

86% Upvoted

13 comments sorted by

5

u/Leather_Coyote_5483 11h ago

“Do I branch from my prior feature branch?”

Exactly, once the first feature branch gets merged then your second branch will be based on main

“My friend is a little slow so there are like 3 PRs pending.” made me laugh

1

u/mrh4809 11h ago

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.

3

u/Leather_Coyote_5483 11h ago

Honestly I’ve been looking for more info online and I realize I don’t know branches as well as I thought I did, I’d rather let someone more experienced answer because I’d probably confuse you with my mistakes. The issue is depending on how the first feature branch goes into main (merge commit or fast-forward will work cleanly, vs squash merge which will require you to rebase your second feature branch on main) the answer won’t be the same

2

u/mrh4809 11h ago

Cool thanks!

1

u/pi3832v2 11h ago

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.

1

u/mrh4809 10h ago

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

1

u/Broad-Promise6954 ancient 9h ago edited 9h ago

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.

1

u/xenomachina 6h ago

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.)

1

u/Dienes16 6h ago

People ITT are not wrong, but explaining too much detail is probably not helpful to you right now.

You can simply: 1. Create your new branch from your previous unmerged one 2. Once the previous branch has been merged, rebase your new branch onto origin/main

Yes, depending on how your previous branch was integrated, this is could also be done with a merge, or it might end up being a no-op. But in any case, the result will be the same in all cases when you just do a rebase.

1

u/Ambitious_Lion_5902 5h ago

Github recently published a new feature, stacked PRs. This solves exactly the issue you are facing IMO. I've used the feature for a few weeks now, and it has worked well for me.
Ref:
https://docs.github.com/en/pull-requests/how-tos/stacked-pull-requests

1

u/Ambitious_Lion_5902 5h ago

Works pretty well once you get the hang of it. When all PRs in the same stack are approved, you can merge them all at once.

1

u/Ambitious_Lion_5902 5h ago

The Github CLI has good commands to use, like rebasing the entire upstack if you make some changes to the lower stacks works really well.
https://docs.github.com/en/pull-requests/reference/stacked-prs-cli-commands

1

u/jibbit 4h ago

> a command I don't know that will fetch everything

this bit immediately jumps out, do you want to explain a bit? it honestly doesn't make sense as it stands

> how do I create a branch so I can continue working against the changes pending merge?

moving commits to different branches is a very normal operation in git. something you do throughout the day without thinking about it.. so if you want to carry on working, but can hold off making a second PR, you can just carry on working then move them onto a branch based on master when it makes sense to do so.

on the other hand, if you want to make two PRs, where the second is conditional on the first being accepted... you want what github calls a Stacked PR - you branch your second branch off your first and make sure you set its 'base' to the first when you make the pull request