When working on a team project, merge conflicts are invariably going to happen. Anybody who has been working with Git long enough knows that they are to be lived with but certainly not appreciated. However, the last thing you want to do is deal with merge conflicts on a local git branch that you rebase from a shared Git repo and then deal with those same merge conflicts again when you go to merge your branch into your local master.

My team's workflow goes like this. We have a central project GitHub repo that we've all forked. We clone down our forked repo and work from that. I create a local branch to work on some new feature or bug fix. I do a bunch of work (git committing frequently) and then when I'm ready to share, I do a git pull --rebase upstream master which rebases the latest commit on the shared project repo. This is invariably the hard part since I have to understand and make decisions about the code my partners have written that may conflict with what I have in local files. Once I've rebased, I do a git push origin <branchName> and then from my GitHub repo (the one that resulted from forking the team repo), I do a pull request (PR) and another team member reviews and merges in my PR. That's all fine and dandy (although generally never is find and dandy).

Merging local branch onto local master with merge conflicts

My next step would be to merge my local branch that I've been working on and now has my latest code onto my local master branch. We always want master to have the latest good code. My best case scenario is that it merges fine and doesn't scream at me that there are merge conflicts. However, that doesn't always happen. But I've just spent an hour (sometimes) rebasing my teams work onto my local branch and now I have to do the same again with my local branch onto my local master. Here are some techniques to help you avoid this problem and solutions if you do come up against it.

Option 1: Merge back into master before rebasing

After you commit and are ready to rebase the group repo's commit onto your own, remember to first switch to master and do a git merge <branchName> to merge your branch onto local master. This will likely help you avoid many merge conflicts after you rebase. The problem is I often forget to do that before I rebase. And you might too. On to option 2.

Option 2: Rename your branch to master

In reality, your branch now has your best and most up-to-date code and furthermore, after rebasing you have a history of all the commits on the shared group repo. If trying to merge your branch onto master looks like it will be another half hour or more, consider renaming your branch to master. Here's how to do that:

git branch -m master old-master   //-m to rename; we are renaming master to old-master
git branch -m branchName master   //rename your branch to master
git push origin master -f         //push new master to origin master with force

If you want to recreate your branch again to do more work on it, just create and checkout that branch again with git checkout -b branchName.

Option 2: git merge --ours (USE WITH CAUTION)

This second option was recommended in this StackOverflow post and uses the--ours flag to ignore any changes in master that would conflict with changes in the branch. But as the post states, "it has the potential for problems when you have more than one stream of development". I recently experienced that myself when trying to merge my local branch onto local master. When I started to fix merge conflicts on master, I noticed that it was starting with the initial commit history, all the way back at the start of the project. It had somehow rewound history and didn't recognize the shared commit history between master and the branch. So, USE WITH CAUTION.

Option 3: reclone your project and copy files over

This is only an option if somehow git gets corrupted in the process. It involves re-cloning your repo (not the team's repo) and copy the files over from the branch on your original local repo to your newly cloned local repo's master branch. git add and commit and you are done.

So, before you punch your computer the next time you run into git issues merging a local branch back into local master, consider one of the above options.