Git: you really should use it. Really.
I’m always looking for anything that can make me more productive and help me develop software the way that I want to. I’m going to make it easy for you and give you some low-hanging fruit that can make software development easier — use Git for source control.
But you say, “It’s just source control, what’s the big deal?”
I said this once too. Most of us at some point used TFS or SVN or some other source control system that works like that. These allow you to check out, check in, branch, and merge, and I always held my breath when branching and merging. I never thought that there could be anything more than that.
Git enables you do to a lot more than that, and it doesn’t get in your way. It does what I want, and it does it fast.
Here are some ridiculous things that I or people I have worked with have been able to do with Git that I couldn’t have done with TFS or SVN:
- Merged a release branch that we had been working on for a few weeks back into the trunk… in just a few seconds
- Reverted a few selected files from a previous commit
- Screwed up a big merge… and then reverted it so that I was back where I was before the merge… in about 1 second (git reflog)
- Switched my code back to a release that we made 3 weeks ago… again, with virtually no waiting
- Accidentally deleted a local branch that I had committed to the trunk… and then undid the delete and got the whole branch back (with all of the commits still intact) (git reflog, again)
- Changed the commit message of something I had already committed (git commit –amend)
- Pulled a single commit from the middle of another branch into the current branch (git cherry-pick)
- Squished two commits that I had in a local branch into one commit (with a new commit message) before I merged it into the trunk (git rebase -i)
- View the commit tree (with all branches and merges displayed graphically) (gitk, gitg, gitx, etc.)
- Pull a commit from another repository into my repository, showing me as the committer but the original developer as the author (github pull requests)
- Renamed files and directories… and git figured out on its own that I had done the rename and recorded it as such
I know some people are scared of Git because they don’t want to have to learn something new and confusing. The reason that I say that Git is low-hanging fruit is that it’s not that hard to learn (after all, it’s just a source control system, right?). If you want do the things that you do daily with TFS or SVN, all you’re really doing it checking in, checking out, looking at commit history, reverting commits, and maybe branching and merging. Those things are easy to learn, and then you can learn the advanced tricks that let you do the really awesome stuff.
Git will also change the way you work because now you can do things that you couldn’t easily do before. The biggest benefit of Git for me is that branching and merging is very easy and switching between or merging branches is almost instantaneous. As a result, I create a branch for every new feature that I work on, or every time that I want to try something that I’m not sure is going to work. I could never do this before because branching and merging was too slow and I didn’t completely trust that it wouldn’t become a merge nightmare. Also, if you’re using TFS, creating a branch means it has to copy the entire source tree into a new folder (as you could imagine, this takes awhile). Now that I can create a branch instantaneously or switch between branches very quickly, there’s no reason not to create one. So when someone comes over and wants me to try something on my machine, I can switch from the feature branch I was working on back to the trunk, do what I need to do, and then switch back to what I was working on.
Also, because I can have a local branch, I check in all the time. Then when I’m ready to go merge it into the trunk, I can squish and alter all of the commits to have nicer commit messages, combine ones that don’t need to be separate commits, and make it nice and clean. I kept it nice and clean in TFS and SVN too, but if I wanted to do that I couldn’t check in as often. I don’t like when my source control system prevents me from doing what I want to do.
If you still had an excuse, you have even less of an excuse because EdgeCase has an awesome Git tutorial up at http://gitimmersion.com. It’s broken up into a bunch of short, easy to read pages so that it’s not overwhelming, and you can look in the table of contents to go directly to something that you’re interested in.
Oh, by the way, Git is free. Setting it up is as easy as getting an account on a site like Github or Unfuddle (OK, those aren’t free if you want to have private repositories with multiple committers) or setting up a folder share on Windows. Can’t say the same for TFS.
Again, if you’re skeptical, I encourage you to invest an hour going through the Git Immersion tutorial and see what you think. I can’t think of anything else that will give you so much benefit for so little investment.
If you’re at a place when you don’t have a say in which source control system to you use, check out git-svn or git-tfs.
Done anything else awesome with Git that I didn’t touch on? Please leave a comment!
Really good points. It’s important to think about the size of the team as well. Once you get more than one developer working on a single code base, Source Control is absolutely necessary; Git is top-of-the-line here.
You also need to consider the length of your coding iteration. Is this a one week iteration – so the code base hasn’t changed much? Git shines here as well as with longer iterations.
People seem to get nervous when the iterations are “too” long and rightfully so. With longer iterations, the code base could change more and cause an increase in merge issues. So you really have to consider your source control strategy in the totality of the project its self – New build, versus defects/enhancing an Existing code base, etc.
Is there a tool to convert subversion repositories to Git? All our code is in subversion. Losing the check in history is not an option.
@Greg,
git-svn will do that, it will create a local repository with all of the commits that are stored on the remote svn server, but at that point you could take the local repository and just push it to a pure Git repository instead.
Hmmm… git does *not* figure out renames by itself for me — I have to use git mv instead of, e.g., bash’s mv (or patch it up myself with git add/git rm). EdgeCase’s tutorial indicates the same: http://gitimmersion.com/lab_20.html
What am I missing?
@craig
It logs renames like a file system, as a drop and create. The difference is that git’s versioning is not by the file, so it really stops mattering. The content is the same so the hash of the change set contents are the same. So at the end of the commit of the stage of either way, the changeset and the way that you roll it back or see what happened are the same.
Thanks for the list Jon! I’ve been pretty curious about Git for a while. We’re looking at setting up source control for development. Based on your feedback, as well as lots of feedback I’ve seen prior, this looks like a great option.
I’m not afraid to learn new things like Git, I’m afraid of the learning curve. But I keep telling people, I’m a smart guy. So, I guess I can figure it out!
@Aaron,
I really don’t think that there is much of a learning curve at all. It’s really easy to do the basic stuff that you do with TFS or SVN. Learning the more advanced stuff is a little trickier, but that’s all stuff that you wouldn’t have even been able to do before anyway, so that’s just the icing on the cake.
@developingchris, maybe that’s why I’m not seeing it: I almost never change a filename without changing the contents, often in the same operation. I’ll see what happens if I don’t do this.