Git is not Subversion

We decided in Spring 2011 to take Git in use as our only version control system. Original ambitious goal was to get rid of all existing Subversion and CVS repositories by the end of year 2012. That didn’t quite work out, we still have a lot of stuff in the old repositories. I can understand this with old not active repositories where nobody sees added value in moving them to Git, but a lot of active development is still done in Subversion repositories.

We’ve had several debates over the issue, latest was today. Some developers were complaining that Git is too complex, it is too difficult to learn to use correctly and it doesn’t explain what went wrong clearly enough. “With Subversion things are just a lot simpler and easier.” When digging deeper with this I found out some of the (Windows) developers are trying to use Git as they have used Subversion. So no use of local branches, no use of stashing, no use of rebasing… And they don’t want to use Git command-line, but GUI tools instead. Because that’s how they have always done.

I admit, if you use Git like you would use Subversion, Git is worse. It sucks. And if you don’t familiarize the fundamentals of distributed version control, Git will never be easy for you. It becomes the necessary evil of version control and you will never learn to use it properly. You start to hate it. And you won’t do anything in order to move ye old Subversion repositories to Git.

Git is not Subversion. Git is a distributed version control system and fundamentally different from Subversion, CVS or (dear god almighty) Source Safe. In order to properly learn Git, one should forget everything they’ve learned from source code version controlling using Subversion or CVS. Git is different. Even though it can be used like you would use Subversion, it is not meant for that. It is a powerful and sophisticated tool which helps you version control exactly the stuff you want. Git is your friend.

So give it another try, but this time start fresh. And uninstall that GUI tool or at least forget it. Git should be first learned using the command line version, it’s the best way to learn the usage properly.

Internet is full of resources for learning Git. Here’s for example one I presented in the Tampere Goes Agile conference in 2011: Up to speed with Git.

Advertisements

Benefits of Git for a developer

We have few teams who have used Subversion for a very long time. When they were told that Subversion is past and Git is future and that eventually we will move all our source code to Git, they weren’t really happy.

So I decided to gather a list of things which make developer’s life easier when using Git, focus being in the stuff which is real.

With Git…

You are in control

  • You decide when (and how) to integrate changes from others.
  • You decide when and what to commit
  • You decide when the commits are published to others
  • You decide how your commits will look like when published
  • You decide what kind of workflow you want to use

You can truly isolate your tasks

  • You can do as many local branches as you want
  • You can stash your changes aside (or in a branch) whenever you want
  • You can start a branch from any point in the history
  • There’s never need to have same repository checked out more than once on your computer

You can do things fast

  • Really many operations are local
  • You’re not limited by the access speed to the source code server
  • If source code server is offline, you’ll be able to continue working
  • Even though Git repositories come with full history, Git uses disk space sparingly. In most cases repositories on disk are smaller than equivalent Subversion repositories.

You can learn from the past

  • You can really easily check out any version of any file at any time. You don’t even need access to the source code server.
  • You have full history of the repository available at all times.
  • You can quickly view log, blame, branch or diff whatever and whenever you want

You can easily correct your mistakes

  • You can perfect your commits before you publish them. If you want, you can squeeze your 28 commits into one.
  • Totally messed up everything? Just scratch everything since last update from the server and start over.
  • Want to revert what you already published? No problem, you can safely revert any commit when ever.
  • Want to correct type in a commit message? If you didn’t publish your commits yet, it’s easy as taking a lollipop from a child.

You have plenty of backups

  • Every clone of your repository is the whole repository. If your source code server blows up, repositories can be restored really quickly.

You can focus on the most important things

  • Want to ignore some files relevant only for you? Easy.
  • Want to ignore certain files on all clones of your repository? Easy.
  • Want to create a new repository? Shouldn’t take longer than few minutes.
  • Want to publish your local branch to others? It’s one command.

 

Return of the Son of the Farewell to SVN

It’s almost a year since we started piloting GitHub:FI in our company. I had high hopes that by the end of 2011 everyone would be already using it. Or at least most of the people. Didn’t happen. Latest ambiguous estimate is that we could maybe get rid of most of the SVN (and CVS!) repositories by the end of this year.

We deliberately started piloting slowly and expected people to start taking GitHub in use after piloting phase was over. Didn’t happen. Those people who already had used Git earlier, were happy to start using GitHub. Several of them had already been using Git on another server… We managed to also mandate new development projects to start on Git instead of SVN and that worked reasonably well, but. Several projects were continuation of previous incarnations of same stuff, it’s anyway rare that something totally new is started. And as people were busy and projects on a tight schedule, no PdO wanted to include stories about moving repositories to Git.

Few teams spent their improvement allocation in moving the repositories to Git and started then learning new ways of working. Some hick-ups were experienced as well as some resistance from the SVN–ain’t-broken-no-need-to-fix-it -people. And yet, we’re still in the phase were few of the larger projects don’t have time and/or will to move those goddamn repositories away from SVN to a better place… And yet, using SVN hurts – it hurts every day, but apparently not enough.

I think I’m going to deliberately make all SVN related problems really visible.

And I think I’m going to try to sneak in stories about moving some repositories to Git when ever I have a chance. The battle is not over yet, it hasn’t even really started yet.

But this battle will be won. And it won’t take another year, I promise.

Farewell SVN, part II

We have one team which has been using Git for several years already. When they heard we’re looking for a substitution to Subversion, and speciall when they heard that one of the alternatives is VisualSVN, they said that Git is pretty much the only sensible choice. They did not want to give up using Git. So I started looking for more information about this wonderful VCS. The more I read about Git, the more convinced I was that this is the future choice of ours.

There were few challenges still to be resolved. How to manage access rights? How to manage storing SSH keys on server? How to deal with subcontractors? All the same challenges we had with SVN wouldn’t go away on their own with Git.

That’s when I was introduced to GitHub. A colleague of mine told that GitHub pretty much has everything we’ve been longing for (see part I), it comes out-of-the-box with features supporting using subcontractors and it has some really nice “social” features (see http://help.github.com/be-social/). Crappy thing was that our company policies don’t allow storing source code on any other than our own servers. So GitHub was out of the question, it seemed.

Luckily enough, I learned that there’s a concept called GitHub:Firewall. And it’s exactly what we needed and wanted – a private installation of GitHub on our own server, behind our own firewall. Excellent!

As of writing, we’re in the process of taking our own GitHub:FI in use. We’ve got a dozen developers using it at the moment and will expand to whole corporation use during Q2 (hopefully). I really hope that before the end of this year, we no longer have any single SVN installations running (not to even mention about those few CVSes we still have!).

So farewell SVN, I won’t be missing you.

Farewell SVN, part I

During the 13-14 years I’ve worked as a developer, I’ve been storing the source code to various different systems. In the first company I worked in there was no version control software whatsoever. All source code was mostly on developers’ workstations and was synchronized on a network drive on irregular basis. Needless to say, that was the worst way of working this far.

On year 2000 I changed workplace. The new company I worked in was light-years ahead in what came to software development practices. They had a development process! And a coding guideline! And, imagine this, a version control system for storing the source code!!!

The VCS we used at that time was Microsoft Visual SourceSafe, I think it was version 5. VSS kinda worked, but we had numerous problems with it, worst problem being unstableness. The system was offline about once a week as the database needed to be re-indexed or something. Occasionally we lost some data and there were no good tools available to e.g. solve merge conflicts.

It was a big step forward as we moved to CVS. That was the first time we started to outline a central build server. Move from VSS to CVS was a big change and it took a long time until we could retire the old VSS server. It wasn’t long after that when some teams started to move to SVN. Move from CVS to SVN was painless and quick, although we still have some legacy source code stored in CVS.

SVN has worked for us fairly well, but now after running a multi-team project where lots of people handle same source code daily, we’ve reached the point where SVN cannot cope with our requirements.

Also we’ve noticed that we have way too many SVN repositories and even few old CVS repos. So we’ve set a couple of goals for the new VCS:
1. We must be able to store all source code on the same system
2. VCS must support our way of working with multiple scrum teams
3. R&D, instead of IT, must be able to control access to different parts of the source code.
4. Transition process must be as easy and painless as possible

So the hunt for A Better VCS(tm) had begun.