I’ve talked recently with the CTO of a small-but-successful company, trying to explain how we do software development. I realized that many things are difficult for them to copy from us, mostly because we have a different approach to implementing features (in particular, we try to limit GUI-intensive features, while they have a very rich Javascript interface).
One thing, however, that I believe they can adopt without changing their code is the source code management tool Git. However, they had already considered it (they are currently using Subversion) and figured that it does not solve problems they already have.
I’d agree that Git doesn’t fix obvious problems. However, Git is powerful enough (once the complexity is mastered) to make lots of little things easier. Here is what it does for us.
- It makes merges much less painful, even when no branched are involved, for example when two developers modify the same file. With Git, it is possible for someone to move a file to a different package, while another developer renames it simultaneously. And removes half of the content. Git (almost always) magically resolves the conflicts and maintains the history of the file, all without any special command. No need for “svn move” or “svn rename”. And no code freeze when someone renames a package, so we tend to do refactorings more often.
- When a regression is detected late, Git can help find the faulty commit. That can be done automatically if you can write a script that detect the bug (for example if there was no automated failing test in the faulty commit), but that’s not necessary. For example, it helped us find at what point “mvn eclipse:eclipse” stopped working (it was because we enforced maven 3 usage in the POMs). The command that does this is “git bisect.”
- The entire source repository is on the developer’s machine (this is configurable). This gives us free backup across all our machines, and instantaneous access to Git logs. In the same spirit, I frequently use git blame to find out who wrote what on a particular piece of code, so that I can ask them for clarifications.
- There are no access rights to manage (though users’ accounts on the server machine, if you choose to have one, as many do, are still necessary).
- Suppose you’re working on something, but must suspend that work temporarily to fix a bug. In SVN, either you cancel all your changes, or re-download the entire code base in a separate directory. Or count on the fact that changes won’t overlap (maybe). In Git, you can temporarily put your changes on the side, do your fix, then retrieve them back again. This is known as “git stash“.
- If by any chance it is necessary to roll a fix in production, it is possible to hand-pick changes with “git cherry-pick“. My colleagues often use this.
- Generally speaking, there is much less mangling of the code base (none of the infamous “svn cleanup“)
None of these features are absolutely necessary. But all together, they make life easier for us. It even let do serverless CI.
Sebastien Douche has said during a presentation at a recent Paris JUG evening that DVCS are the one thing that all developers should learn in 2010. I think he’s right.
