I'm facing an issue while working with Git. I followed these steps:
Create a new brunch B1
git switch -c B1changing a file in the projectgit add . && git commit -m "B1"git push origin B1. Create pull request in GitHub(B1)Create a new brunch B2
git switch -c B2changing a file in the projectgit add . && git commit -m "B2"git push origin B2. Create pull request in GitHub(B2)Merged the pull request of branch B1. On GitHub I click "create a merge commit" HEAD is on the last commit in B2
Pulled changes into branch B2 using rebase:
git pull origin main --rebaseorgit rebase main. Head pointer pointer is set to commit in B2Pushed my branch to the remote server:
git push origin B2![rejected] B2 -> B2 (non-fast-forward)error: failed to push some refs
If I follow the instructions git pull origin B2 and git push origin B2. I noticed that commits from branch B1 are included in my pull request for branch B2. How can I avoid including changes from B1 in the pull request for B2 after merging B1 into main?
The idea is to understand how to use git with a rebase strategy.
[upd]: as an option I can use git push origin B2 --force in this article https://git-scm.com/book/en/v2/Git-Branching-Rebasing
Any advice or guidance on resolving this issue would be greatly appreciated!
The problem is that your step 4 was wrong. You should have said
pullwithout--rebase(this code assumes your HEAD is B2):Or even better, you could have rebased B2 onto main (this code assumes your HEAD is B2):
Basically what you did was to rebase the new part of main onto B2. That's exactly backwards. The new part of main is the commits from B1, so now you've added B1 onto the end of B2, as you have rightly observed.
Another possibility, best of all in my opinion, would be to omit step 4 entirely. That's what I would have done. If you are about to push B2 into a pull request and you do not anticipate any merge conflicts, your step 4 gains you exactly nothing.