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 cvsimport - No CVS folders which causes cvsexportcommit to fail
  • How to ignore directory globally in Git?
  • git pull merges no files if any of the deltas are conflicted (need manual merge)
  • meaning of -‌- in git checkout
  • Rollback to previous commits to find when bug was introduced
  • Can I perform `git pull` without password prompt but `git push` with password prompt?
  • git add .

    git commit -am "message"
    

    anyway?

    or even instead:

    git add -A
    
    git commit -am "message"
    

  • How to git clone an SVN repository where all branches are located in root?
  • Can't start a GIT build on Teamcity
  • Connection refused on my git's depot
  • How can I get multiple Jenkins builds to work from one local git repo?
  • Automatic deploy on commit
  • git: 'credential-cache' is not a git command
  • 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”

    anyway?

    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.