I’ve heard good things about GIT and decided to see whether to use it over Subversion for a project.
The first few benefits of GIT I encountered:
- Distributed nature/connectivity – you have access to the whole repository even if you don’t have network/internet connectivity
- Bisect command – to see when a bug introduced
- Disk space – GIT compresses data well so the whole repository doesn’t take up as much space as one would expect
Disadvantages of GIT:
- Since it is so new, the tooling isn’t as mature as I’d like it to be before relying on a project. (This may not be a project for work, but it’s not just version control on my own machine either.) See below about GIT clients.
Things I’m not sure about yet:
- Branch handling – “You can commit to your local repository without messing up things for your co-worker” – This seems like it flies in the face of continuous integration. I want people to be committing to a shared space frequently so we find out about integration issues as early as possible. This sounds like “developer branches” which I feel are a step backwards.
- Audit – Where is the official copy? If everyone has a copy of the repository, which is the official copy for auditing/protection against hackers/etc.
Git clients
- Command line. The command line looks solid. There is even a command comparison if you use Subversion. You just download and install.
- GUI. (SmartGit) – While this is still in beta, it seems ready. The official statement is “SmartGit is in pre-release state, but we consider its feature set (for the first release) rather complete. ” It has been in public milestone status since August (2009.) When I installed it, SmartGit said it “expires 12/30/09”. I suppose this is so you don’t stay on the milestone build too long.
- Eclipse plugin. (EGit) – While you can get this from the Eclipse update site, it says “are only made available to help the EGit development team use the plugin to develop itself. ” I tried anyway to see what would happen. It installed, but I couldn’t find a perspective/view that had to do with GIT.
While the GUI is available for all operating systems (Windows, Linux, Mac’s OS X, etc), it is still technically in beta.
My conclusion
Git looks like it will be really good one day. For playing with a version control tool. I think it is great. However, I don’t think it’s a point to recommend using for the project I was thinking of for several reasons. The two main ones are:
- The GUI support isn’t there yet. This project has a lot of new developers on it so I think a good GUI is critical.
- I’m not yet comfortable with the idea of source control being so distributed. If something is on one person’s machine, it doesn’t really exist. Just like “if it isn’t in SVN it isn’t done.”
Further reading:
See the official GIT/SVN comparison
I haven’t had a chance to try it yet, but I’ve heard of some people using the GIT/SVN tools, creating their GIT repo locally from SVN, doing all their stuff, then ultimately committing back to SVN. It supposedly works quite well for nervous first-time “gitters”, like me 😉
I think with new developers, command line access is actually a much better learning tool. In most cases you only need a couple of commands for day-to-day work (add, commit, pull, push).
You can indeed have an official master copy and this can be centrally located. GitHub is a great service, there are alternatives (including on your own server). We have cruise control pull from the master repository for builds.
Mike: I think I’m going to try that. It lets me play with GIT without affecting the project or anyone else.
Toby: These are really new developers. In particular, they are high school students. I think it’s more productive for them to have fun and like programming than learn details of a tool. And if they like the command line, they can still use it. I didn’t know about GitHub It sounds interesting.
Few of my friends suggested me to use Git, instead of subversion. Yet to check it out.
Just host one Git repository and call it the master. People working on the code can clone the repository, work on it and when something is done it can be incorporated in the master repository. No problem there.
Well, my idea of this complete stack is not only to have a repository on your local system, but also the CI system. Without pain you can change configuration, still working, add new Tests, still working, if you commit to central repository you already know it will going well.
I think this approach is highly dependent of your setup. If you are working in a small team in a company, were everyone is working in the same room at the same time. Benefit of personal branches etc without the problem of missing CI. If you have a very disconnected setup, you may need a CI System on every developer computer.
Have you tried Mercurial?
I’ve been using MercurialEclipse and I find it pretty productive.
In fact, I use hg to control my source code locally then I push to an SVN repo where my other team mates can fetch it.
Distributed SCMs are way more powerful than Subversion. If I were you, I didn’t worry for the frequency of pushes to the main repo: this doesn’t depend on the tool, but on your process. Indeed, the fact that you can commit locally is just a freedom degree more, as it simplifies a very good practice IMO, which is “branch per feature” – as usual, freedom must be used with responsibility. Of course, tooling is a real issue and you should double check it.
I’ve personally moved to Mercurial a few months ago – it’s very similar to Git and the two things can substantially do the same stuff. You could even evaluate Mercurial in addition to Git. Mercurial support is excellent in NetBeans (NetBeans has got a Git plugin too).
I’ve written a very short tutorial about how I’m using Mercurial on my projects, and it could be helpful to learn its potential: http://jrawio.rawdarkroom.org/development/mercurial+best+practices/ – between July and August I’ve also blogged many times about it http://www.java.net/blogs/fabriziogiudici/
I haven’t tried Mercurial . I don’t like personal branches/branch per feature though so I can’t see why it would be for me. And the developers on this project aren’t experienced enough to have a a feel for process. This sounds like a way to give them rope to hang themselves.
You can set up git in many different ways, including setting it up just like subversion. You can setup one git which does not have a working copy (like a subversion server) and your developers could “push” their code to that central repository when they’re ready.
Heck, you could even use the hooks git provides to force your developers to have the latest central version of the code before committing, and also to force them to push their code to the central repository after committing, JUST like subversion.
I personally couldn’t do that to my fellow developers, because they enjoy being able to make sure a feature is ready before asking me to pull it from them and test it out.
Regarding auditing: You can keep one copy of the repository (your own, perhaps) which you control solely, and you can run integration tests on, and you can decide whose commits come into it. The fact that every git repository contains a FULL history of all commits made makes it MORE easy to recover, not less. Think about it–if you have 10 developers, you have 10 full backups of your code base and every commit ever made. A potential hacker would have to hack into every single repository and corrupt them all the exact same way in order to be successful. And even then, it’s most likely that you’d be able to tell something was changed (Git has some auditing tools built in, to check the integrity of the repository).
Oh, and did I mention Git is about a billion times faster than subversion? Ever get tired of waiting for big commits to go through? I no longer have that problem using Git.
Pingback: git plugins for eclipse and netbeans | Down Home Country Coding With Scott Selikoff and Jeanne Boyarsky