25

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?

Chris R
  • 17,546
  • 23
  • 105
  • 172
ottodidakt
  • 3,631
  • 4
  • 28
  • 34

6 Answers6

20

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

Jakub Narębski
  • 309,089
  • 65
  • 217
  • 230
  • 2
    Also "git gui" as GUI for "git add --interactive". You can select hunks and lines of code visually. – Vi. Oct 06 '10 at 13:21
  • `git gui` is a 100x easier way to do this. Even though I normally like the command line and that's all I used for a long time, I still use a gui for basic commits, and gitk to visualise the log. – rjmunro Jan 29 '13 at 16:59
  • You can add multiline git commit messages. If you want to do so from the command line open with quote like git commit -m " – Chris McCowan Sep 28 '18 at 17:56
9

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'?"

Daenyth
  • 35,856
  • 13
  • 85
  • 124
8

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.

ThiefMaster
  • 310,957
  • 84
  • 592
  • 636
7

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.

Andrew Grimm
  • 78,473
  • 57
  • 200
  • 338
Chris Moschini
  • 36,764
  • 19
  • 160
  • 190
  • Good tip, but what is the antipattern? – u0b34a0f6ae Sep 29 '09 at 17:02
  • 2
    Not using git stash, of course. – innaM Sep 29 '09 at 17:13
  • 5
    This is as opposed to creating a branch. A typical sc provider like svn would make you create a new branch visible to everyone on the repository. In a widely used repository this can be unwelcome and disruptive, and now you've got to think of a good clear branch name... . And then check in, Switch back to trunk, and finally your 10 second fix can begin. All of that, or just git stash. – Chris Moschini Oct 06 '09 at 14:43
  • You don't need to check in and switch back, you *could* just create the branch remotely, switch to it, and checkout trunk somewhere else. – detly Jul 14 '10 at 03:21
  • 4
    git stashes can be lost. Branches are much more stable and visible. And when you have a branch, you can commit multiple times instead of relying on a single blob as your two days of work, 'cause really, you should never work for 2 days without any commits. – Kzqai Aug 25 '11 at 16:25
  • 2
    git stash is particularly appropriate when you're likely to simply continue the work being stashed on the new branch. But I'd consider having months of stashes accumulated to be an antipattern itself. As would stashing without giving names/comments to the stashes -- just in case you don't get back to it. – Bob Kerns Oct 09 '12 at 16:06
  • 1
    In this case, I would have created a new local branch at the beginning of the 2 days. And 2 days of work would represent a lot of commits on that branch. Rather than stash, I sometimes commit with a log message like [temporary commit] knowing I can fix it with `git commit --amend` or `git rebase -i` later. – rjmunro Jan 29 '13 at 17:02
  • The timelines discussed here are subjective to your workflow; if you need to set code aside quickly for an experiment, urgent change etc, git stash is oft overlooked, especially by those new to git. – Chris Moschini Jan 30 '13 at 07:58
5

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

Community
  • 1
  • 1
detly
  • 29,332
  • 18
  • 93
  • 152
3

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.

ottodidakt
  • 3,631
  • 4
  • 28
  • 34
  • +1 on this, although I would focus on the fact that Git submodules provide built-in support for [Component engineering](http://en.wikipedia.org/wiki/Component_engineering), rather than on possible Git limitations with large repositories (I haven't experienced those you mentioned). – André Caron Mar 17 '14 at 15:47