What is Git?
Git is a directory content tracker (i.e. it lets you keep track of the contacts of directories as they change over time). It was developed originally by Linus Torvalds (creator of Linux) in 2005.
What do we use it for?
Until a couple of weeks ago, we were using Subversion for keeping track of our source code. We’re now about a third of the way into converting everything to git (a surprisingly straightforward process, thanks to the git-svn utility).
So git is our source code manager of preference these days. Whenever someone makes a change to one of our applications or dependencies, they check the change into the central repository via git, and the other developers can then merge those changes into their own repositories. Git makes much of this insanely easy, compared to Subversion.
Why do we like it?
Branching and merging are the features we originally fell in love with. Whenever we start development on a new feature, we create a “branch” of the code. Work done in this branch will not affect the “main” branch (called “trunk” in subversion, and “master” in git), so it is a good way to make significant changes without affecting what our users actually see.
Branching and merging in Subversion are painful. If you’ve never used it, you don’t know what I mean. If you have, you do. Branching and merging in git, though, are wonderfully, blissfully straightforward. For those two reasons alone git is worth the switch for us, though there are lots of other, more advanced, features we like about git, too (git-stash, git-bisect, etc.)
How can people learn more?
The learning curve is pretty hefty, especially if you start out thinking of it like “subversion-but-with-some-differences”. The best way to learn git is to forget everything you know about more traditional SCM’s and read through the various tutorials online. We’ve got a Backpack page where we’ve been accumulating various Git resources.
Once you’re over the hump, though, it’s pretty amazing how easy it makes some tasks that are really hard in other systems.
Phil
on 11 Jun 08First line: directory contact manager or directory content manager?
James
on 11 Jun 08Thanks for this; I was wondering why you guys had chosen git over svn. Those Backpacked resources look useful too; much appreciated ;)
Parveen Kaler
on 11 Jun 08The only reason I haven’t tested Git is because I’ve heard that it is only a first-class experience on Linux.
37Signals is a Mac shop, correct? Could you please talk about your experiences with Git on a Mac?
phil swenson
on 11 Jun 08I’ve always disliked how SVN/CVS created all those SVN/CVS directories in your source code….
does Git do this as well?
Jonathan Rockway
on 11 Jun 08No, it’s a first-class experience on everything that’s not Windows. Basically, you need a shell and Perl. Every OS in existence except windows comes with both of those in the default install, so it’s really no big deal.
Rob Sanheim
on 11 Jun 08Parveen: Git is just about first class on the Mac, due to its unix core.
Phil: Git only has one top level .git directory in the root of your repo. So much cleaner then SVN and CVS.
thomas
on 11 Jun 08Have you guys tried Versions on Mac?
mkb
on 11 Jun 08thomas: all due respect, but a new GUI won’t make Subversion’s branching system better. Versions is also only in beta and will cost money upon final release, like so many other Mac OS X frontends to free tools.
Joe Grossberg
on 11 Jun 08Pardon me if I’m being pedantic, but in my experience it’s not branching that’s hard with SVN; just merging all those changes back in. What a laborious and error-prone process that is!
John Topley
on 11 Jun 08@thomas
Why would they use Versions which is a Subversion GUI when this post is about how they’ve switched from SVN to Git?
BTW that Backpack page is really handy, thanks!
Brenton
on 11 Jun 08If you’re working by yourself, is version-control worth messing with?
I just create backups of my code everytime I build some cool new thing into it, and store each archive in a folder called Version History.
Paul M. Watson
on 11 Jun 08@Brenton Version control is very useful from teams of one to teams of a thousand. Lot more efficient than folders too.
leethal
on 11 Jun 08Was wondering how long it would take you to get onto the git wave! Personally, I’m hopin’ for a github.com/37signals. Oh, there is one. I’m hoping for one with stuff in it, then.
Nathan
on 11 Jun 08@Brenton – I’ve found git to be especially useful for projects I am working on by myself. There is no need to set up any servers to host the repository, just ‘git init’ the directory and you are ready to track changes.
vinnie
on 11 Jun 08@Brenton, you’re doing version control already with your backup/archive system, might as well do it right with svn/git/whatever
ceejayoz
on 11 Jun 08@Brenton – I work almost exclusively by myself on projects, and Subversion has saved me days of work many a time.
Jeff
on 11 Jun 08If you rarely branch and/or merge do you still believe Git is a worthwhile move away from Subversion? As a one person shop, it is rare that I ever branch.
Are there any nice apps to manage Git like svnX or Versions?
How about a PVCS to Git conversion tool? That would be excellent.
Ben Tsai
on 11 Jun 08@Brenton – For small projects or experimental spikes, I use Mercurial to setup ad-hoc version control on top of my company’s Perforce/SVN/Other centralized VCS.
Since I’m on Windows, I chose Mercurial, but the basic idea is the same: DVCS’s (distributed version control systems) offer speed and obviate the need to setup a repository (as @Nathan mentioned). It’s been a real boon not to have to worry about breaking the build and frees you to pursue agile spikes.
Stacey
on 11 Jun 08I’ve actually just started using svn recently for my own projects. For the past 10 years I’ve literally been copying/pasting and using tar files. My friends call it “cave(wo)man coding”
As of now, I absolutely LOVE svn. It’s tedious sometimes, but it’s a breeze because I’m still used to keeping organized with Make, shell scripts and directories.
Will definitely give git a try, though.
Peter Urban
on 11 Jun 08We’re currently using subversion but we’ll definitely give something else a try if it’s more productive or less hassle.
chad
on 11 Jun 08to all the people above talking about subversion vs git for a single user: the problem with subversion is that branching/merging is handy for making big changes to a tree, even if you are the only one doing the work. what happens when you’re in the middle of a huge change and your client wants a minor bug fixed on the production site? branching/merging is critical then. it’s not only useful for big teams.
and yet, with subversion, about 70% of the time, i regret doing the branch and merge because it is so painful.
i’ve only held off from investigating git because of the time cost to make the switch.
Ben Atkin
on 11 Jun 08Great! Now you can work on a plane, and still be able to use version control!
Johan Sahlén
on 11 Jun 08I work almost exclusively on my own in projects, but I couldn’t live without SCM. I often do deliveries of templates to third parties, and in those cases it’s wonderful to have a complete log of what changes I’ve made, and being able to quickly run a diff against a certain date’s tree, so that I can send over only the files that were added/modified since my previous delivery. When I was using Subversion, I never branched/merged, but after moving to Git I do it all the time. For example; right now I’m working on some JavaScript optimizations for a project in a separate branch, while still being able to do day-to-day bug squashing on the master branch, and be able to deliver those fixes to the third party. When I’m done with the optimizations, I’ll just merge that branch back in, and deliver it in one chunk. In a word: awesome.
Pat Maddox
on 11 Jun 08How are you guys actually dividing up the repositories? Subversion lets you throw everything under one big source tree and then just check out subdirs as needed, but git doesn’t. I assume you have different git repos for each of your products. But what about shared stuff like Rails, plugins, etc?
Peter Jackson
on 11 Jun 08Hm. I was hoping for more “How” than “Why” when I came to read this post. As a recent git convert myself, I understand “why” one would want to migrate from SVN to git.
Can we have some insight into the advanced features you find useful? More on your practical application of “git-stash” and “git-bisect” maybe?
W. Andrew Loe III
on 11 Jun 08@Pat Maddox
http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html
W. Andrew Loe III
on 11 Jun 08@Peter Jackson
I use stash quite a bit. Master is my mainline branch, and then I create a topic branch feature-1. I’m in feature-1 and my partner comes in and tells me that there is a critical bug that needs to be fixed now. Without any thought I can just run git-stash and whatever I’m doing gets put on a shelf, I don’t have to commit or think. I switch into master, checkout a new branch called fix-bug-343 do whatever commits are necessary, then merge them back to master and push. Crisis averted, I swap into my local topic branch (feature-1) and then run git-stash apply and my working tree is exactly how it was before I was interrupted, and I can continue on my merry way making the next great feature.
Peter Jackson
on 11 Jun 08@Jeff: Git ships with “gitk”, a graphical browser. There are some better ones out there as well.
@chad: The learning curve isn’t too bad. I was productive again in less than a day.
Peepcode has a great screencast on git. Worth the $9.
Devan
on 11 Jun 08We are thinking of switching to Bazaar from svn here. Anyone had any experience with Bazaar who can point out any differences between bzr and git?
Brenton
on 11 Jun 08Thanks friends. I’ll look into Mercurial.
Ashley Williams
on 12 Jun 08@Jonathan Rockway: Well it is a decent experience on Windows with msysgit. It isn’t exactly perfect because it will only work from the .bat file and not from any old command window, but once your in its pretty much a unix environment with git, so it works as Linux or Mac OSX would work.
Jesse Andrews
on 12 Jun 08You state that you have a central repository. Why did you choose the star-topology instead of a distributed topology (where each person has their own repos and pull from each other)?
I’ve used both in group projects before, but find the star topology frustrating since multiple people changing the same remote repository means you have to keep up with what everyone else is doing if you are working in multiple branches.
MilesZS
on 12 Jun 08For those that were wondering about Git on Windows, here is a screencast from Gitcasts.com, explaining how to setup Git on Windows: http://www.gitcasts.com/posts/git-on-windows.html
Jamis
on 12 Jun 08@Pat Maddox: yeah, we’ve got one repo per project, which I actually prefer to the one-huge-repo-for-everything setup that we had with subversion. For plugins, we’ve got one repo for each of those, too. For things like Rails, we’re still experimenting with how best to manage “externals”. We’ve tried git submodules and subtree merging and a few others and nothing has really clicked for us.
@Peter Jackson: sorry we didn’t tell more about the “how”. The fact is that most of us are git newbies, so we aren’t doing anything really advanced. The backpack page linked in the article really is the extent of the “advanced” stuff we’ve been doing so far. I’ve only used git-bisect once, myself, to track down a Rails change that broke Basecamp. (git-bisect totally rocked, btw.)
@Jesse Andrews: we chose the star topology because that’s what we’re familiar with. I’ve never actually participated in a project that uses only a distributed topology—I’d be curious to read more about how the work flow is for such a setup. Any links?
Jack Moffitt
on 12 Jun 08Distributed version control is very neat, and I heartily encourage anyone who hasn’t tried it to do so. Git is the latest in a long line of these. You should also look at a Bazaar (bzr) and Mercurial (hg). These three seem to be the leading contenders currently.
That said, branching and merging doesn’t have to be so painful in subversion. Check out Divmod’s Combinator (or read how it is used in the tutorial). We use this at Chesspark a lot to manage branches in subversion and it makes it extremely easy. And it works anywhere there is Python, which means Windows users are included.
Brad Fults
on 12 Jun 08For what it’s worth, deleting a remote branch doesn’t require that you prefix it with “heads/”. On your Backpack page with Git tricks you have git push {repository} :heads/{branch}.
All you really need is git push {repository} :{branch}. It basically says write from the ref on the left side of the : to the ref on the right side of the :. So, from nothing to {branch} turns the branch into nothing.
pwb
on 12 Jun 08Brenton, thanks for bringing it up.
It seems to me that solo coders should absolutely be using version control. However there is very little information about just how to do this (for newbies).
Looking forward to having a look at git due to trust in 37s thoughts on the matter.
Terry Jones
on 12 Jun 08What took you so long? :-)
Why did you choose git over mg or bzr? Moving away from svn is a no brainer (once you’ve made the move you see why (and that includes combinator)). But the choice between git, bzr & mg wasn’t easy for us (we went with bzr). If you have comments on that choice they’d be much more interesting – at least to this reader.
Thanks!
Anthony
on 12 Jun 08Can someone help me understand how a merge (and in particular conflict resolution) in SVN is any different from a merge with GIT?
As near as I can tell when there is a conflict there is no easy way to visual how or what needs to be fixed. Seems there is a glaring need for a gui to aid in this process.
This “what to do when there is a conflict” question has keep me away from version control for a while now.
Greg Macoy
on 12 Jun 08I’m with Brenton and pwb! I’ve never managed to get my head around Subversion. I find with a lot of apps like that there’s an assumption that you already know what they’re talking about. I find a lot of open source stuff is difficult to get into because of the assumptions that get made, or because no-one can give you a clear overview of exactly what it is and how to use it.
I tend to zip the site I’m working on before making any major changes. With bigger sites this isn’t ideal though. I’ve looked at Subversion a few times but the learning curve seemed a bit too high
Stefan
on 12 Jun 08By the way: Git is not an improvement of Subversion, they can’t be compared this way. I chose Git and never looked back at Subversion. Branching, merging, pushing, pulling. This is so cool, so superfast, you won’t even need a gui. It’s so easy I even do a “git init” on most of my not web-related projects, like LaTeX files or even Photoshop Layouts. There are some good screencasts on GitCasts.
Saurabh Nanda
on 12 Jun 08We’re looking at Git to solve our branching + merging problems. It seems to be the new “in-thing” for large teams these days. Given that there’s “no silver bullet” and each tool has its pros and cons, can you also share the disadvantages you’ve come across while using Git?
(One thing I’ve noticed while using Git on my local machine for pet projects, is that the learning curve is steep. So, training the entire team to learn another SCM tool is going to be an issue. The other thing is the lack of something similar to svn:externals.)
Eric Anderson
on 12 Jun 08Being a shop so focused on the user interface experience I surprised you chose git. Did you pick it over the other distributed SCMs mostly because it was getting popular in the Rails community? (all the other cool kids are doing it :))
I looked into git about a year ago and found it very hard to use. I found myself being forced to understand how it works internally just to use it as a user. I think this stems from it being designed as a core building block for building higher-level SCMs instead of being a complete SCM itself. If I remember right I think there were other projects that layered on top of git to provide a better user experience (e.g. Cogito). I have heard the user experience has gotten better recently and the idea of SCM layers was abandoned but with that as a starting philosophy how much better of a user experience can it get?
I’ve been experimenting with Bazzar lately. It also is a distributed SCM but it has a focus on the user experience and a much smoother transition from SVN commands. Obviously 37 Signals is on git to stay but for others thinking about making the switch I would suggest investigating Bazzar rather than just defaulting to git just because everybody else is doing it in the Rails community.
And if you really do care about popularity it is interesting to know that Ubuntu (on of the fastest moving Linux distributions) uses Bazzar for manging much of the source code it generates.
Jamis
on 12 Jun 08@Eric Anderson, fair enough. I’ll openly admit that it was the “everyone is doing it, it must have merit” aspect that first got me to investigate git. But we’ve adopted it at 37signals not because of peer pressure, but because we’ve found there to be a good deal of value in it, especially when compared to how we were using subversion before. That said, there is no silver bullet. I’m sure bzr is a great SCM, too, as are mercurial and the others.
In the end, never do something merely because everyone else is. The grapevine is a good way to hear about new things, but make sure you adopt a new technology or technique because you understand it and find value in it.
Anthony
on 12 Jun 08@jamis: Can you comment on how you deal with conflicts that arise from your merges? Are you just stuck viewing/resolving those manually?
Jamis
on 12 Jun 08@Anthony, I haven’t had to deal with many conflicts yet, but when I have, I’ve dealt with them just like in subversion—opening the file in question and resolving them manually.
Jakub Pawlowicz
on 13 Jun 08Guys, are you aware you’ve just made git’s kick off?
So let’s try it! :-)
jimmy
on 13 Jun 08Look for git usage to rise by 100% now that 37 signals says they use it.
Nick s
on 13 Jun 08We switched from DARCS (an older distributed version control system) to GIT a couple of months ago. DARCS supported a ‘truly distributed’ model a little better because it had fewer restrictions on how commits were ordered in a branch, however, this also made it (extremely) slow, and cumbersome to manage.
@Anthony, Saurabh Nanda, et al Git treats a branch as an ordered series of commits or patches, merging simply means taking every patch from after the branches diverged from one branch, and applying them on top of the other.
as opposed to svn, etc’s system of making you manually merge each conflicting file.
as a result, manual merging only happens where the two branches change the same line of code. (pretty rarely, in my experience)
as this all happens (very quickly) on a developer machine, the merge can be ‘pushed’ back to your server at once, and all the other developers can get the complete set of changes the next time the fetch updates.
Michael
on 14 Jun 08Jamis,
Dumb question – but are you using Capistrano and Git? If so, how does this compare to Subversion and Git. Is there any difference?
Thanks.
Michael
on 14 Jun 08Cool – just found my answer
Jamis
on 16 Jun 08@Michael, we’ve also got a custom-tweaked capistrano deployment strategy that we’re using here, and which we’ll probably release eventually now that we’ve got it working. :) It’s based on the remote cache deployment strategy, and is pretty blazing fast (especially compared to the :checkout strategy with subversion that we were used to).
This discussion is closed.