Jonathan Worthington: Why I use Git

Git, if you haven't come accross it yet, is a version control system. Developed
by Linus Torvalds, creator of Linux, Git has taken the version control system by
storm in recent years - and with good reason. Distributed, with outstanding branch
and merge capabilities and just plain fast, Git enables developers who master
it to work more productively.

But wait a minute, what's version control all about?
As a system is developed and maintained, various changes occur. These changes may
add new features, fix bugs, refactor code, improve documentation and so forth.
Version control is about keeping track of these changes. It ensures that multiple
developers don't accidentally stomp on each other's changes. It enables you to do
bugfix releases of a product without having to ship the latest development work.

Centralized vs. Decentralized
Traditionally, version control systems have been very centralized. A central server
keeps track of all of the changes. Developers run version control client software on
their machines, which they use to get a copy of the current version of the code, fetch latest updates, review the changes they have done locally and then commit them to the central server. Questions about historical versions are answered by the server, which has a full view of the version history. This is the model followed by systems such as Subversion and TFS.

Decentralized version control systems are different. Every developer gets a full copy
of the version history on their local machine. This means that looking back in time is practically instant. You may think that this must be extremely costly in terms of disk usage, but in reality this doesn't tend to be the case; Git is extremely efficient when it comes to storing history, and in some cases fetching the entire histroy with Git can be faster than getting a single version with Subversion!

It goes much, much further than just viewing history locally, however. All operations
are available locally. You can commit to your local copy, create and merge branches in your local copy - in fact, you can work version controlled without any access to the central server, and synchronize your changes when you are ready. No more development grinding to a halt because the central server broke down! And since you are working locally, you have the power to get your commits in order before sharing them. Silly mistakes can be fixed without anybody knowing you made them, making for a cleaner version history - and the illusion that you're awesome.

Won't this be chaos?
At this point, you may have realized that it is possible to build up a set of
commits locally, and other developers can do the same. Essentially, it's like
everyone is working in a branch all the time, and merging to a central location
in order to share commits. So won't life become full of painful merges?

If Git changed anything for me, it was my view of branches and merging. Before
Git, a branch was a big deal. It wasn't so much that making the branch was an
issue - although in Subversion that meant making an entire copy of the source
tree, which was hardly fast. It was the merging that made branches a nuisance.

Happily, Git makes branch creation virtually instant, and creates them in place -
which means you can switch branch without having to change directory. Most
important, however, is that it works really hard for you when it comes to merges.
Thanks to the way it tracks history, and by employing multiple merge algorithms,
Git is able to take care of most things automatically, leaving you to resolve the
things that tend to genuinely need a human decision. By way of example, I recently
merged a branch that had diverged from the mainline by 200 commits, with changes
touching 80 files, and I had to resolve 3 issues by hand. This relatively large
merge was all over in well under five minutes.

So what's the catch?
Honestly, Git has a learning curve. Some people refer to it as an "unlearning
curve" - you have to learn to forget what you thought you knew about version
control. While that's a cute perspective, it doesn't change the fact that
getting started with Git needs you to invest a little time understanding the
underlying model and how to get stuff done with it. It's not so much that it
is inherently difficult - but it is different, and that takes time to get used
to.

My first few days using Git were confusing, but I was lucky enough to have lots
of people I could ask for hints when I got stuck. It wasn't long before I was
comfortable, and not all that long afterwards when I was answering questions
from others who were starting their Git journey. By now, I use Git just about
every day, for work projects, open source projects and personal projects. I
appreciate the speed, the way I can effortlessly branch and merge - which
has changed the way I work for the better - and many little bonus features
that make my day to day development that little bit more efficient. By now,
the time I invested in learning Git must have paid itself back many times
over, and will continue to do so for many projects to come.

Interested?
Myself and my other Git-fond teaching colleagues have put together an
introduction to Git, in hope that we can share what we've learned and help
others to enjoy the same productivity boost. See more at:

http://www.informator.se/utbildningar/metoder-och-modeller/arkitektur/introduction-to-git.aspx

/Jonathan