Try:

git mergetool

It opens a GUI that steps you through each conflict, and you get to choose how to merge. Sometimes it requires a bit of hand editing afterwards, but usually it's enough by itself. It is much better than doing the whole thing by hand certainly.

As per Josh Glover's comment:

[This command] doesn't necessarily open a GUI unless you install one. Running git mergetool for me resulted in vimdiff being used. You can install one of the following tools to use it instead: meld, opendiff, kdiff3, tkdiff, xxdiff, tortoisemerge, gvimdiff, diffuse, ecmerge, p4merge, araxis, vimdiff, emerge.

Below is a sample procedure using vimdiff to resolve merge conflicts, based on this link.

1. Run the following commands in your terminal

   git config merge.tool vimdiff
   git config merge.conflictstyle diff3
   git config mergetool.prompt false
   

   This will set vimdiff as the default merge tool.

2. Run the following command in your terminal

   git mergetool
   

3. You will see a vimdiff display in the following format:

     ╔═══════╦══════╦════════╗
     ║       ║      ║        ║
     ║ LOCAL ║ BASE ║ REMOTE ║
     ║       ║      ║        ║
     ╠═══════╩══════╩════════╣
     ║                       ║
     ║        MERGED         ║
     ║                       ║
     ╚═══════════════════════╝
   

   These 4 views are

   • LOCAL: this is the file from the current branch
   • BASE: the common ancestor, how this file looked before both changes
   • REMOTE: the file you are merging into your branch
   • MERGED: the merge result; this is what gets saved in the merge commit and used in the future

   You can navigate among these views using ctrl+w. You can directly reach the MERGED view using ctrl+w followed by j.

   More information about vimdiff navigation is here and here.

4. You can edit the MERGED view like this:

   • If you want to get changes from REMOTE

     :diffg RE
     

   • If you want to get changes from BASE

     :diffg BA
     

   • If you want to get changes from LOCAL

     :diffg LO
     

5. Save, Exit, Commit, and Clean up

   :wqa save and exit from vi

   git commit -m "message"

   git clean Remove extra files (e.g. *.orig). Warning: It will remove all untracked files, if you won't pass any arguments.

You are trying to merge in a commit that makes a change to a file that has been deleted in the working tree

You have encountered a merge conflict. It means that Git cannot automatically determine how to merge the two branches. Git is asking you to do the merge manually, and gives you some help along the way by telling you what files it cannot automatically merge, and what changes specifically in these files that it has trouble with.

Run git status. It will output a list of what files are unmerged. These files will contain conflict markers that look similar to this:

foo

<<<<<<< HEAD
BAR
=======
bar baz
>>>>>>> foo

qux

This means that HEAD (or, the commit or branch you are currently on) has changed a line to BAR, and the branch foo has changed the same line to bar baz.

Edit each of these conflicts to your liking, making sure that you have no more conflict markers left. For example, if you preferred the BAR version in the above example, you would simply edit the file so that it looked like:

foo

BAR

qux

Save each file and add it as you go.

# (edit <file>)
git add <file>

There are tools available that do the file editing part for you, some find them easier to use than to edit the files manually.

When you are done, run git status to make sure that you have no more unmerged files. Then, run git commit to finish the merge if you are happy with the result.

Git - Basic Branching and Merging provides some more information about merge conflicts.

A different and often* saner way to go about this is to first rebase the other branch (in this case sidebar) on top of the branch you are merging it into (in this case master):

git checkout sidebar
git rebase master

You will likely still have conflicts, but fixing them here is sometimes easier. The procedure is the same as described above, edit the files, add them, commit. When done, run git rebase --continue to continue the rebase procedure.

Then, finally you can merge the branch with no conflicts:

git checkout master
git merge --no-ff sidebar

The --no-ff is optional; with it you will get a merge commit to denote that you merged a branch, without it your history will be linear with no merge commit.

A benefit of rebasing before merging is that there will never be merge conflicts in the actual merge, meaning that the merge commit never introduces a change other than what is already introduced by the commits in the branch being merged. This makes the history easier to understand.

A downside to rebasing is that commits are applied on top of a new state of the code. This has the implication that you need to check each commit to see that it still does the right thing. It is a good idea to spend a little time doing this in order to avoid future surprises.

* Avoid or at least use caution when rebasing branches that have merges. Rebase eats merges. It is also a good idea to avoid rebasing another person's commits. The author of a change is usually the person who knows best how to properly resolve any merge conflicts caused, so if possible, conflict resolution is best delegated.