Git is a blessing, isn't it?
Absolutely yes, if used properly.
The general workflow that we follow in the project development is like
If you have observed the above flowchart, there is a red line drawn from the master branch to the merge commit and that is intentional.
Most of the time, many developers work on the same project and on different issues, and while we work, the master branch could have been updated with other's change and the master branch could have new commits. So let's update the diagram.
OK, updated the diagram. But what is the issue?
The issue is, there are possibilities of getting conflicts and we have to resolve either by merging the master branch to your branch or rebasing your branch with the master.
Now let's get this straight why I choose to rebase over merge
No extra merge commit
Master's history remain clean and linear
So when we merge master to our branch, we need to resolve the conflicts, and then it adds a new merge commit.
While in rebasing our branch is first updated with master and then our commits will be applied one by one.
If you are working on a complex task, you might need more time and the master branch will not wait for you, so I suggest to rebase your branch regularly(daily) and if there are conflicts resolve it, Otherwise at creating a pull-request or merge-request of a big task, conflicts may haunt you.
Top comments (8)
I also like this approach.
I'm quite curious btw. What do you usually do when you've already made a Pull Request for this branch and it got reviewed but then they request you to update your branch.
Do you still do a
git pull --rebase origin master?Do you do a
git push --forceafter?me personally, if there's a update thing on PR, I simply run:
fix any conflicts, then:
note: I'm using zsh shell with oh-my-zsh which has aliases:
And at last I haven't setup on my new machine, but will do soon:
alias rbm = gcm && ggpull && git checkout <current branch> && git rebase master(rebase branch to master)The there's a interpolation you can use for getting current branch :) I think I'll have to modify above, but should give general idea.
Thanks @cyberhck for sharing
Yujin, I currently use Bitbucket. It gives the option to rebase directly on PR diff view
So it's a bit easy if we don't have any conflict but if there are conflicts then we have to manually rebase with the target branch as @cyberhck mentioned in his comment
Oh, cool! I didn't know Bitbucket has that feature.
I personally don't like bitbucket but thanks for sharing
Indeed.
I like to run this on my feature branch to sync up with master
And I also build rebasing into my push flow, since I push regularly anyway. As a git alias
This works great for master too if you do trunk-based development for your own projects.
By the way, in case you if do get a merge commit like this...
If you then later do a rebase on master, the unwanted commit will actually be removed.
Thanks Mike, your comment is really helpful
I worked as a configuration management specialist (and release manager) for several years and there not many things we so wholeheartedly despise like someone tampering with the commit history of a repo. When you have concurrent changes in the same code range you will have to resolve them manually anyway. Git has a feature called merge tracking that prevents you from remerging changes that were already applied. You'll lose that intelligence when manipulating the history like that. And by the way a git log is not a novel, it doesn't need to be clean. It should give information about each and any change made to the code :)