Git Tricks: Avoiding merge when dealing with remote conflicts

TL;DR: git pull --rebase

The scenario is common: You finish the changes on a codebase, all commits are ready to be pushed. You run git push and an unexpected message appears: "! [rejected]". The reason: "Updates were rejected because the tip of your current branch is behind its remote counterpart. Integrate the remote changes (e.g. hint: ‘git pull …’) before pushing again.".

You follow the message and run git pull. Instead of pulling all changes to your local machine you are asked to confirm a merge commit message…

First of all… Why this is happening?

This happens because, after you've pulled, someone pushed changes to the same branch you're working on:

Your local work conflicts with the commits added to remote-branch

By confirming the merge commit, all the work on the remote branch will be merged on your local work. After this, you will be able to push your changes, making your-local-work coincide with the tip of remote-branch:

With a merge commit, your local work is now the more up-to-date tip of the branch

Is there an alternative to merge commit?

Yes, there is. To avoid the merge commit you need to rewrite your local history.

To do this, instead of just pulling the remote changes, you need to rebase them: git pull --rebase. By doing this, all of the commits from your local branch will be placed after the ones in the remote branch:

All of your local work is placed after all the remote changes

After this, you just need to push your changes. Your local work will become the tip of the remote branch.

The advantages of this approach is that you don't need a merge commit and a fork on the branch history will not be created. Also, notice that nothing on remote was rewritten, so you'll not need to use--force to push your changes.

Want to learn more about Git and other stuff related to development? Follow our Goiabada Blog and enjoy a delicious mix of software development, design, and business.