Avoiding Git Merge Conflicts using Rebase Option
When multiple developers work on the same project, they’ll usually be changing a shared master development branch at overlapping intervals. This overlap occurs because developers create parallel branches for work, and then merge those branches in when features are complete. The branches they create for their work all start off as identical copies of the master branch, but as the master branch changes over time, the code on an unmerged branch looks less and less like the current code on master. When it’s time to integrate their changes into the main codebase, this inevitable divergence can cause lots of challenges that can introduce bugs, create bottlenecks, or even bring development to a complete halt.
Resolving conflicts is hard at the best of times.
Take an example of two people working on the same file. Developer A commits and pushes their changes to the master branch. Developer B makes changes to the same file locally and then attempts to pull Person A’s changes. This will now result in a conflict because they both made changes to the same file.
Resolving merge conflicts
To resolve a merge conflict, you must manually edit the conflicted file to select the changes that you want to keep in the final merge. There are a couple of different ways to resolve a merge conflict:
Resolving a merge conflict on GitHub
If your merge conflict is caused by competing for line changes, such as when people make different changes to the same line of the same file on different branches in your Git repository, you can resolve it on GitHub using the conflict editor.
Resolving a merge conflict using the command line
If you have a merge conflict on the command line, you cannot push your local changes to GitHub until you resolve the merge conflict locally on your computer. If you try merging branches on the command line that have a merge conflict, you’ll get an error message.
Git pull usage
The git pull command first runs git fetch which downloads content from the specified remote repository. Then a git merge is executed to merge the remote content refs and heads into a new local merge commit.
In this scenario, git pull will download all the changes from the point where the local and master diverged. In this example, that point is E. git pull will fetch the diverged remote commits which are A-B-C. The pull process will then create a new local merge commit containing the content of the new diverged remote commits.
In the above diagram, we can see the new commit H. This commit is a new merge commit that contains the contents of remote A-B-C commits and has a combined log message. This example is one of a few git pull merging strategies.
A --rebase option can be passed to git pull to use a rebase merging strategy instead of a merge commit. The next example will demonstrate how a rebase pull works. Assume that we are at a starting point of our first diagram, and we have executed git pull --rebase.
In this diagram, we can now see that a rebase pull does not create the new H commit. Instead, the rebase has copied the remote commits A — B — C and appended them to the local origin/master commit history.
Finally, let’s configure it for future Pull
The --rebase option can be used to ensure a linear history by preventing unnecessary merge commits. Many developers prefer rebasing over merging, since it’s like saying, "I want to put my changes on top of what everybody else has done." In this sense, using git pull with the --rebase flag is even more like svn update than a plain git pull.
In fact, pulling with --rebase is such a common workflow that there is a dedicated configuration option for it:
git config --global branch.autosetuprebase always
