By default, git pull
will merge changes into your branches. When your Pull Request will be merged, you will end up to this:
Doing git pull --rebase
will rebase your branch on top of upstream branch. When your Pull Request will be merged, you will end up to this:
It makes history much more readable. You clearly see where start your branch and what is in feature branches. It makes also interactive rebase or git bisect much easier.
Top comments (5)
Hi Thibaut, I recommend
git pull --rebase=merges
to preserve the "bumps" of local merges or better yet, do it automatically atpull
by configuring it by default:git config --global pull.rebase merges
.Oh gosh, I wish I had knew this option sooner 😀
I try to avoid local merge. If you have a local merge, it means you have a dependency on another branch, so it means a feature branch has lived too much time on its own and should have been merged sooner. But yeah, theory and practice...
Hello have doubt regarding git rebase .
I have two branches one main and another my feature branch .
I made 3 commit on feature branch at 1pm 2pm and 3pm respectively, now I did the 4th commit on main-dev at 4pm , When I am on feature branch and running git rebase main-dev , on top of 4th commit my 3 commits are there absolutely as expected , but here comes the problem as soon as I am running git push my feature branch is getting diverged and then getting merged into feature again .
Can you help here , why it is happening.
Below screenshot for reference
Hi,
That's unexpected, indeed. Do you use command line or a GUI FrontEnd like SourceTree or GitKraken ? GUI Frontend tends to do some extra stuff behind the scene.
You can try to do it fully by hand:
Ensure your tree is as expected (with gitk or any gui tool), and then
Now you should have the expected behavior.
Hope this help 😊
Note: "git pull --rebase" is a shortcut for "git fetch; git rebase origin/main"
Thanks , adding
--force
while pushing after doing rebase helped me in getting expected result.