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?

  • Git pull asks me to write merge message
  • How do I get the tags a commit belongs to?
  • What's the jgit equivalent for “git merge-base --fork-point branchA branchB”
  • How to push local Git repo to newly created Google Code project?
  • Bitbucket git repository printed strange colored flower after push. WTH?
  • I can't select Microsoft Git Provider
  • permission denied for certain git path
  • Locally find all unmerged branches of origin
  • GIT tracks changes occurred BEFORE it was installed
  • How do I intentionally detach HEAD in git?
  • git: list all files with owner/identity at first commit (or rather, the first user to commit the file)
  • How to restrict access to master branch on 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.