DEV Community

Cover image for Fed up with Git conflictsđŸ˜€?: Rebase regularly and chill!
Maulik
Maulik

Posted on

Fed up with Git conflictsđŸ˜€?: Rebase regularly and chill!

Git is a blessing, isn't it?

Absolutely yes, if used properly.

The general workflow that we follow in the project development is like
Alt Text

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.
Alt Text

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.
Alt Text

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.

Discussion (8)

Collapse
yujinyuz profile image
Yujin

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 --force after?

Collapse
cyberhck profile image
Nishchal Gautam

me personally, if there's a update thing on PR, I simply run:

gcm && ggpull && git checkout <my-branch> && git rebase master
Enter fullscreen mode Exit fullscreen mode

fix any conflicts, then:

ggpush --force
Enter fullscreen mode Exit fullscreen mode

note: I'm using zsh shell with oh-my-zsh which has aliases:

  • gcm = git checkout master
  • ggpull = git pull origin
  • ggpush = git push origin

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.

Collapse
maulik profile image
Maulik Author

Thanks @cyberhck for sharing

Collapse
maulik profile image
Maulik Author

Yujin, I currently use Bitbucket. It gives the option to rebase directly on PR diff view
Bitbucket

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

Collapse
yujinyuz profile image
Yujin

Oh, cool! I didn't know Bitbucket has that feature.

I personally don't like bitbucket but thanks for sharing

Collapse
michaelcurrin profile image
Michael Currin

Indeed.

I like to run this on my feature branch to sync up with master

git pull --rebase origin master
Enter fullscreen mode Exit fullscreen mode

And I also build rebasing into my push flow, since I push regularly anyway. As a git alias

git sync
# ie
git pull --rebase && git push
Enter fullscreen mode Exit fullscreen mode

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...

git checkout feature
git pull origin master
# commit to merge origin/master into branch
Enter fullscreen mode Exit fullscreen mode

If you then later do a rebase on master, the unwanted commit will actually be removed.

Collapse
maulik profile image
Maulik Author

Thanks Mike, your comment is really helpful

Collapse
vgoebbels profile image
Dr. Volker Göbbels

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 :)