Git: commit before merge?

I was advised to commit all my changes before running git pull and merge. Does it make sense ? What if I run pull and merge before committing my changes and commit them after the merge?

  • Can't Push to Git Repository
  • Check that git repository exists
  • git pull generates “fatal: No remote repository specified.” error
  • Is it possible to force git submodules to be updated?
  • How to integrate visual conflict resolution (P4Merge) into SourceTree
  • What is a bare repository and why would I need one?
  • Clean master branch but also detailed record of intermediary commits
  • What's the most proper way to remove an already deleted branch from tab-completion history?
  • Git stuck at deltafying objects
  • How to re-apply commits on top of unrelated branch?
  • ssh: Could not resolve hostname github.com + STATUS_ACCESS_VIOLATION at eip=68086014
  • Difference between subprojects and submodules in Git?
  • 4 Solutions collect form web for “Git: commit before merge?”

    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.

    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.

    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.

    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.

    Git Baby is a git and github fan, let's start git clone.