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?

  • How to clone a Github Gist via SSH protocol?
  • git pull from Github to live server with multiple developers
  • How git branches and tags are stored in disks?
  • linux PS1 - display branch name only inside a git repo
  • Option to push disabled in Visual Studio Code
  • can't connect to github via ssh
  • Can Git ignore files that has the same content but updated timestamp
  • Why does Git treat this text file as a binary file?
  • git: finding which merge brough commit into the current branch
  • Git: How to update/checkout a single file from remote origin master?
  • git push gets “Everything up-to-date” after committed
  • What is the git(1) equivalent of “cvs export”?
  • 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.


    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.