A couple of weeks ago I introduced myself to the world of the world of Git and Github. And I did not see much wrong with it. But over the last couple of years I have become very frustrated with the slowness of SVN – or it could just be TortoiseSVN. Anyway, I thought it was time for a change. I am still a lonely developer in a non-IT oriented workplace, so I mainly use source control for Backup as well as for easy Continuous Integration. Every time I commit somewhere, a server starts to build the project and run the unit tests like magic. But now it is time to move on and lose some time with learning a new thing again. I guess using Github or some other third party external thing would be cool but it is not an option in my line of business.
My first attempt was to create a Ubuntu machine and set it up as a central repository. I got the Ubuntu machine installed and Git working on it but I could not get the client to communicate with the server because of a firewall issue so I gave up. Mind you, that was after a fight of 5 hours with downloads, Kubuntu , proxy servers, apt-get, VMWare, more proxy madness,…
I saw the light
I saw the light. During all of the various installations I had a lot of time to surf the world wide web and saw that I did not need a server. I could just use a share and set that up as a central repository. This is fairly easy once you understand how it works.
So first we create a share on a server somewhere. Then we create a folder on that share; I guess you all know how to do that. If you don’t, then step away from the keyboard.
Now you have to open a command window and go to the folder you just created. Or just use explorer shift+right-click on the folder and choose “Open command window here”. And now for the hard part. Type
git --bare init
A short aside about what git means by bare: A default git repository assumes that you will be using it as your working directory, so git stores the actual bare repository files in a .git directory alongside all the project files. Remote repositories don’t need copies of the files on the file system unlike working copies, all they need are the deltas and binary what-nots of the repository itself. This is what “bare” means to git. Just the repository itself.
And this is what it looks like after you do the command-line thingie.
Now that we have our central repository set up we need to set up our local repository. For this we go to My Documents and create a folder in there. Right click on the folder and click Git Clone.
The url to fill in is the folder where you have setup your central repository.
Now we just create a few files and folders in the local repository and commit them to master (master being the branch, but more about that in the next post).
This commit (unlike the SVN commit) just commits things locally. To make the central repository receive our changes we need to do a push.
Via this menu.
Or via the Git sync… menu item.
Normally the remote should have been setup by your cloning action and should be correct.
Now if we go back to our central repository it will just look the same as before.
But the files are there. We can see this best by creating a second local repository and doing the clone thing again. And here is the result.
This is magic stuff and very easy to do.
Using Git with Tortoisegit is easy, using Git and making a central repository on a share is easy. What more do you need? My next attempt at a blog will be about branching and merging which is easy in Git. And in the future I also want to try out Git-extensions because they have a VS plug-in.