Git and Subversion - the working directory is fundamentally different

One of the fundamental differences between Git and Subversion that I didn't understand at first and, IMHO, doesn't really get much coverage in the documentation is the way the 'working directory' is treated.

Git is all about branching and it is indeed very good at that but what happens when you switch branches in Git is completely different to when you switch branches in Subversion.

You could say that you never really "switch" branches in Subversion. You can create branches and checkout a branch in subversion: In subversion if you want to use a branch you typically 'check it out' to a new clean 'working directory'. This directory is a new place in your filesystem and you perform work on that branch in this new working directory. You can't easily 'switch' a working directory from one branch to another branch.

With subversion if you are working on a number of different branches then you would typically have a number of different 'working directories', each being for a specific branch. In Git things are very different...

In Git you typically have a single 'working directory' and when you want to work on a different branch to the current one you literally 'switch' branches and the source files in your working directory are modified to reflect the state of the files in that different branch. When you switch to another branch the source files are updated again to reflect the current state of every file in that other branch.

At first this seems like a lot of work for the revision control system to be performing but git seems to handle it in its stride - and very quickly. Most of the time the differences between two branches are only relatively small compared to the size of the overall code base. Git is very fast at storing 'deltas' and rendering and backing out those deltas on source files as required by branch switching.

You might ask, "what about changes that I have made to files in the current branch?"

Git won't let you switch branches if you have changed files in your working directory. You have to either commit the changes (not so bad as you're only committing to your local repository) or 'stash' the changes. Stashing tells git to store all the changes you've made in the current branch without a more official and long term 'commit'. You could say 'stash' is the perfect solution for developers who are scared of commitment. You can leave your current branch after a stash and return to it whenever you feel like it.

So the ability to switch between branches in Git means that you can have very quick access to any branch in your repository without having to checkout a new, full working directory on the filesystem. In other words, Git branch 'switching' is a lot faster than Subversion's 'branch' checkout.


I have to admit I wasn't at all excited by the arrival of Git at first - "Oh no! Another revision control tool to master" but many of the open source projects that I use on a regular basis are now hosted on GitHub so I have undergone a forced introduction to Git. I have to say that the more I use it the more I like it!

Comments

Popular posts from this blog

Java package name structure and organization - best practice and conventions

Classic software engineering mistakes: To Greenfield or Refactor Legacy code?

How to reset MySQL 8 root password on CentOS 7 and 8