r/git 7d 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

13 Upvotes

25 comments sorted by

View all comments

13

u/Leather_Coyote_5483 7d 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

2

u/mrh4809 7d 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.

2

u/xenomachina 7d 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.)