-1

So we are using GitFlow working schema.

I have a branch named feature/foo, I just finished my ticket there and I created a Pull Request, that branch (feature/foo) is going to be merged with our head branch develop

So now, I need to continue working in other features but I need the work I just did in feature/foo, so I create a new branch from develop

git co -b feature/foo2

and merge changes from the previous branch I did changes on:

git merge feature/foo

Now I make my changes there, but when I try to create a Pull Request of feature/foo2, all the commits and files from the previous branch appeared as well.

What is the best way to approach this? What can I do differently?

Daniel_Enqz
  • 71
  • 7

2 Answers2

1

What is the best way to approach this?

If it were me, I'd just leave it and move on. As soon as the first PR is completed and feature/foo gets merged into develop, your second PR should be able to be updated such that the changes from the previous PR will disappear1. However, if you have a rebase or squash merge strategy on your PRs, and the first branch is re-written, even though the changes will fall out of the PR, the commits will not. If you don't want to see those commits in the 2nd PR, after the first is completed you could do a "fancy" rebase of feature/foo2 to update it:

git fetch
git rebase feature/foo feature/foo2 --onto origin/develop
git push --force-with-lease

Note in the above command you want to use your local copy of feature/foo and the remote copy of the develop, which is why it's specified as origin/develop.

What can I do differently?

Some options that might apply to you:

  1. You could skip working on a feature that depends on something that isn't merged into develop yet and pick something else.
  2. You could take action to get the first PR completed faster. (Perhaps try to meet with the reviewer(s) and get it reviewed and completed immediately.)

Side Note: when you must start working on a feature that depends on another branch not yet completed into develop, assuming that other branch is up to date (especially if you use a rebase workflow), then you could just branch off of the previous branch instead of the multiple command approach you presented. Instead of:

git switch -c feature/foo2 origin/develop
git merge feature/foo

you could simply do:

git switch -c feature/foo2 feature/foo

1This is implementation dependent, but many PR tools automatically update the PR when the source branch changes, and also offer a mechanism for updating the PR when the target branch changes, though you might have to pick an option such as "Restart Merge" or similar.

TTT
  • 22,611
  • 8
  • 63
  • 69
0

When you create your PR you can specify a base branch where the PR will be merged into.

If you specify the base branch as feature/foo, the diff that will be shown will be the diff between feature/foo2 and feature/foo.

EmilioPelaez
  • 18,758
  • 6
  • 46
  • 50
  • Thanks! And for example, what happens if I have a lot more branches that I need to continue working? Like I need feature/foo, feature/foo1, feature/foo2 to be merged into my current branch (feature/foo3). Then, as you are referring, what would be my base branch? – Daniel_Enqz May 26 '22 at 22:23
  • Plan ahead. Git is quite forgiving but planning how you’re going to do you work can save you from dealing with big merge conflicts. – EmilioPelaez May 26 '22 at 22:26