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.