What are common antipatterns of using Git? [closed]

Answer 1

Rebasing a branch which has already been published or merged from (and then re-publishing that branch). Doing so will make everyone hate you as it will result in awful problems since you've just rewritten history and require those people who have merged from your pre-rebase branch to fix the problems introduced by your rebase manually.

Also see http://hades.name/blog/2010/03/03/git-your-friend-not-foe-vol-4-rebasing/ for details.

Answer 2

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 3

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 4

Migrating one big repository from SVN etc. to one big git repo is a definite anti-pattern. The way git is designed, you can't do partial checkouts and even commits can be slow. Better to modularise and use a repo per component. At the very least, repo per team. Definitely not repo per organization.

Answer 5

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 6

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).