Introduction
Source control has always been a really annoying issue for me, since it was either :
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 here : 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 commited 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 basicly 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 DLL's are deployed to the build folder
commit a289f8a70b961f83110c96a91e9ed97edb900909
Author: Tom Janssens <Tom@xx>Date: Wed May 6 10:28:53 2009 +0200
Inital checkin 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 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 to 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)
Basicly 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 follwing 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 :
Appearantly 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 helpfull command : "stash".
Suppose you are working on a branch, but would like to switch to another branch without commiting your changes, and getting back later to the original branch :
$ git checkout experminental
-- 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 experminental
-- 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 then intially 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 definately "to git"
Subscribe