You should never use "git add ."

[chrillebile]

By using git add ., the user will have no control over what's added and changes/files that should not be added could be accidentally added to commits without knowledge. Therefore it's especially not smart to teach a new git user to use git add . instead git add <filename> should be used.

There could be a level where we teach the user that using git add . is not a good idea. Maybe by using git add . and committing before we realize that we accidentally added a password file we didn't want to add.

[blinry]

Thanks for that comment, @chrillebile! I really like the idea of having a level that shows why it's not a good idea. So far, with out time travel analogy, a "git add .;git commit" card was our simplest way of making a "capture the whole current environment" action. But maybe teaching git add and git commit -m from the start would be better.

[chrillebile]

Instead of git commit -m, use git commit -v. It's not very good to use git commit -m, then the user might commit something they don't want, but also you won't be able to write good commit messages. By using git commit -v the user will both be able to write good commit messages and see what changes a commit contains.

[BenBE]

I even prefer git add -p instead of plain git add, which gives quite fine control over the environment you are going to commit. While I personally prefer git commit -m I can see the merit why teaching to use the editor-based interface is preferable. But using git commit -v feels a bit redundant; maybe hint on its existence, but not give it the main focus?

[codeling]

I also prefer git add -p, and immediately tried it out, and it seems to make the terminal window stuck (I cannot enter anything else there until I play a card).