To git or not to git - Source control done right / introduction and quick tutorial

Introduction

Source control has always been a really annoying issue for me, since it was either:

• Too complicated to manage
• Too restricted
• Too slow
• Too much a hassle to setup
• Badly integrated
• One or more of the above

I have been working with Subversion/TortoiseSVN for a little while, but I was noticing that I really had to force myself into using the source control repository. A few times in the last month, I noticed that I did not do enough commits, forcing me into re-implementing stuff again. I was also lacking a very good diff tool to compare different versions.

I have been looking for different alternatives every now and then, but without much success, until recently...

The holy grail : git

I found git.
Getting started with git has been a real pleasure. Setup/Commits/history checking is all really easy with git. As a proof of concept, I will show you a small walkthrough in a Windows environment.

1. Download (g)it

Download the windows version from http://code.google.com/p/msysgit/downloads/list.
(I downloaded the latest preview.)
Use the default install.

2. Create git repository

Start Windows explorer; right click on the source folder and choose "Git Bash here".
You will then get a Unix-like prompt. Now type:

$ git init
$ git add .
$ git commit -m "Initial checkin"
$ exit

That's it. You can now start modifying your code as you wish.

3. Save/check in changes, a.k.a. commit

Start Windows explorer; right click on the source folder and choose "Git GUI here". A new app will start.

On the left side, you will see what changes are available: staged and unstaged changes. If you do not see any files here, this means that you have not changed anything since the last commit. Go ahead and change something.
You can leave this window open, and just press the "Rescan" button to refresh in order to look for changed files.

You can click on any of the listed changes to see the details. If a change is sourcecode that has been changed, you will see the lines that are removed in red, and the lines that are added in green.

Only files that are listed in the "Staged changes" box will be committed on pressing commit.
You can stage a file (make it committable) by clicking on it, and pressing CTRL-T (or commit/stage in the menu).

If you have all your files that you want to commit in the "Staged changes" box, you just need to enter a short description, i.e. "* fixed bug abc", and press the "Commit" button. That's it, your changes are checked in.

A small remark:

I personally use the following description convention:

• "+" if I add something (feature)
• "*" if I change something (bugfix, etc.)
• "-" if I remove something (redundant code)

So the history will basically look like this after three commits:

+ Webdav support implemented
* illegal exception when deleting a non-empty folder
- Removed Log4Net

4. View commit log

If you want to view the commit log, you can do it like this:

Start Windows explorer; right click on the source folder and choose "Git Bash here". Then type:

$ git log 

You will get a long alphanumeric key and the description. An example:

commit 4f62ca99c026e0c7ee2bd2beb8f39f232c0d6072
Author: Tom Janssens <Tom@xx>Date:   Wed May 6 11:04:55 2009 +0200

Installer fix:

commit 6f8a7888b223d9aee7adbef105aca9a0adc8eb11
Author: Tom Janssens <Tom@xx>Date:   Wed May 6 10:53:32 2009 +0200

Make sure necessary DLLs are deployed to the build folder:
commit a289f8a70b961f83110c96a91e9ed97edb900909
Author: Tom Janssens <Tom@xx>Date:   Wed May 6 10:28:53 2009 +0200

Initial checking from http://xx.unfuddle.com/svn/xx_htm/tags/v1.3.0.3404/

5. Check out a version

If you want to check out a certain version, you must know the commit code from the log (step 4). You can then check out a version by typing

$ git checkout XXXXXXX 

Where "XXXXXXX" is the first few characters of the commit code in the log. Since this is not very user friendly, we can fix this by tagging.

6. Tag a version

If you have a version that is to be publicly released, you can tag it. Later on, you can reference this version with this tag. You can create a tag like this:

Start windows explorer; right click on the source folder and choose "Git Bash here". Then type:

--- create a tag : 
$ git tag v1.2.3.4 
--- delete a tag : 
$ git tag -r v1.2.3.4
--- show differences between the current version and 
--- a tagged version (type ":q" to quit): 
$ git diff v1.2.3.4
--- check out the tagged version (do not forget to commit your current changes first) : 
$ git checkout v1.2.3.4 .
--- check out the last version
$ git checkout .
$ exit 

7. Branching and merging(advanced)

Basically, branching allows you to have different versions of the source simultaneously (for example, specific code for a client).
By default, you start in a branch called "master".

To create a new branch called "experimental", we type the following in the git console:

$ git branch experimental 

You can checkout code from different branches like this:

$ git checkout experimental
$ git checkout master 

If you want to merge you current branch (master) with code from another branch (experimental), you can do it like this:

$ git checkout master
$ git merge experimental 

If you want to undo this:

$ git reset 

Update

Apparently it is not advised to do any work on the master branch, so you should always create a branch for everything you do. There is however a very helpful command : "stash".
Suppose you are working on a branch, but would like to switch to another branch without committing your changes, and getting back later to the original branch:

$ git checkout experimental
-- some changes, until someone wants you to adjust something on the master branch
$ git stash
$ git checkout master
-- do your stuff
$ git commit -m "some stuff"
-- go back to the last state of the experimental branch, including non-commited files 
$ git checkout experimental
-- apply the master changes to the experimental branch :
$ git pull master

There is a lot more to this, but this should get you started.

8. Other tools

There are a lot of ins and outs in git that I do not know about, but these should cover the basics. To get help, just type the following in the git console:

$ git help 

In Conclusion

While this was meant to be a really short introduction to git, it seems to be longer than initially planned. However, I am hoping that this article is helping people considering to switch to git, or looking for a simple source control system.

For me, the answer to "To git or not to git", is definitely "to git".