Git: commit before merge?

Question 1

Committing before pulling is not always advisable -- you should consider stashing your work instead.

A better way to think about this is in terms of your staging area. Ideally, you'd like it to be clean before you attempt to merge in remote changes (remember, git pull = git fetch + git merge).

git commit is one way of accomplishing this, but it will alter your history--thereby polluting it if you're concerned about leaving your repo in a constantly working state.

git stash, on the other hand, was built for use cases just like this.

Use git stash when you want to record the current state of the working directory and the index, but want to go back to a clean working directory.

source: http://git-scm.com/docs/git-stash

You workflow would then look something like this:

$ git stash
$ git pull origin master
$ git stash pop stash@{0}

This will allow the pull to execute without issues, vocally warn you when applying your stash has resulted in conflicts.

Question 2

Uncommitted changes are always bad:

Either your changes are good, then commit them
or they are bad, then discard them.

Uncommitted changes are completely unknown to git. Therefore git cannot help you in any way if anything goes wrong and you risk loosing you work in case of problems.

You avoid many problems if you simply make sure you don't have any uncommitted changes whenever you are doing any git operation like the pull in your case.

Question 3

If you try to merge changes on files that have modifications, git will just refuse to do it. That is why committing first is a good idea. If you don't do it in that order, it will either merge fine (if the files you changed were not involved in any other commits that are being merged), or nothing will happen, and git will tell you that your merge can't be done.

Question 4

If you do a commit before you pull you can go back to that point if something goes wrong with the pull/merge. You don't have to do it, just good practice.