What are common antipatterns of using Git?

Question

As a Git newbie, I realized that I have been using it as if it were Subversion. e.g. always working on master, not committing locally before pulling changes etc. This often results in avoidable manual merge situations. What are other common antipatterns of using Git?

Answer 1

Not using git stash

Scenario: You're working on feature A. It's taken you about 2 days, and you're about a day from completing it. You've gotten good code written, but there's more to do. Your boss shows up and says "Hey I need Feature B right now. Should take 10 seconds."

Sure - 10 seconds to write it, 2 days of work lost. Or 2 hours trying to comment out and hack all the code you wrote for the past 2 days to get everything back to a working state.

git stash is here to save the day. Just type git stash at the command line, at the root of your project, and all your recent changes go in the "stash," which is a stack of changes. Now you're back to where you were 2 days ago, but your work isn't lost. You make the 10 second change, check it in, then type git stash pop to get your changes back (and remove them from the stack).

As may be evident, if you're having a TERRIBLE day you can stash multiple times, although obviously the more you do so, the less fun merging may be when you finally git stash pop them all. If you manage to accumulate a lot of stash over months of work you have git stash list to look them over, git stash pop and git stash drop to pick and choose which ones are worth bringing back and which are best to just toss, and git stash clear if you only stash awful ideas.

Answer 2

Big ball of changes

When you are writing commit message, and you don't know what to put in single line summary of changes, it does probably mean that you put too many independent things in a single commit. Better to split commit into smaller, using "git rebase --interactive", and/or "git add --interactive" and friends (like "git stash --keep-index" to test stashed changes).

Having single issue per commit will help tremendously when trying to find bug using "git bisect".

Answer 3

This is more general than git-specific, but I've seen many many projects with commit messages like "bugfix" or "fix foo" or "stuff". Don't do that, instead use meaningful commit messages like "component fiz: Fix foo bug[\n\nExtra info]" and "Whitespace cleanup". You'll thank yourself when you inevitably look at your commit history later and don't need to say "What the hell did I mean when I committed 'stuff'?"

Answer 4

As someone who used SVN a lot before recently starting to use Git more and more, I can say my worst habit is doing git commit, git push, git commit, git push, git commit, git push...

In other words, always pushing after every commit, like I'm still using SVN.

After the initial training required to drop that habit, my workflow is loads faster. One of the built-in boons of Git is the fact that a local commit is so much faster than a remote commit. Another boon is that failing to do near-constant remote commits is probably not going to take your leg off later (especially if it's a small team, even if it's a big team).

For me, this is where there is no real analogy in SVN (that doesn't invoke Jakub Narębski's "big ball of changes" anti-pattern).