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.