Understanding when to use git commit -m and git commit -am

My main question here is whether iti makes sense to just always do git commit -am instead of git add . followed by git commit -m?

I understand that -am indicates that it will add all changes from modified TRACKED files. So in a situation where I did not add any new files, it would make sense to just run git commit -am instead of git add, but would it be considered best practice to just do:

  • Git Azure deployment missing files from content directory (MVC4 project)
  • Git - get all commits and blobs they created
  • Using git pull to track a remote branch without merging
  • IntelliJ IDEA GitHub integration creates the repository, but gets “couldn't authorize” error trying to push
  • Using git, how do I ignore a file in one branch but have it committed in another branch?
  • git hook for legit commit message (#123 good message)
  • git add .

    git commit -am "message"


    or even instead:

    git add -A
    git commit -am "message"

  • 'Git Command Not found' in the custom action for SourceTree
  • Can't push to the heroku
  • Git add lines to index by grep/regex
  • Merging 2 branches together in GIT
  • How do I preserve DIRECTORY file mode or permission in git?
  • Include submodule commit messages with “git log”
  • 3 Solutions collect form web for “Understanding when to use git commit -m and git commit -am”

    would it be considered best practice to just do:

    git add .

    git commit -am “message”


    No, there is no such “best practice”. As long as you do not want to include any untracked files, git add + git commit -m and git commit -am will do exactly the same.

    There are two situations where you need to to use git add:

    • if you want to include untracked files, and
    • if you do not want to commit everything that changed

    The second point in particular is the reason many people recommend against always using commit -a:
    After working on code for a while, you often have several different types of changes in your working copy (the bugfix you were working on, some unrelated renaming, some temporary changes for debugging…). commit -a risks putting too much into one commit – in these cases selective use of git add is better.

    But if you are certain you want to commit everything you changed, go ahead and use git commit -a.

    If you keep your .gitignore current, then git commit -am is a perfectly adequate way to do things. It is a shortcut for git add -uA <nopattern> ; git commit -m "message".

    This is git, best practice is subjective. I prefer to add files manually so that I get a chance to review changes as I go, but you might not need that.

    I have committed enough code accidentally by doing -am that I generally avoid it these days. git add -u will stage the same changes as the git commit -a and then you can do a git diff --cached to make sure you want to commit them. Some of my colleagues even go so far as to always do git add -p so they have to look at every diff before it’s even staged.

    If I know the changes I’ve made are small then i’ll still use git commit -am for convenience, but it may be worth getting out of that being the default habit.

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