For some time I have heard good things about git and mercurial, but just never got around to really looking at it. So when I had last week off I finally got around to doing more than just cloning a repository from github or bitbucket. Basically what I needed was some easy way of doing source control for my pet projects, so either would no doubt get the job done.
My focus ended up being mostly on git simply simply because I often run into github when I read about open source projects that I find interesting. Another thing I had in the back of my head was that I could take a look at appharbor - which I hear about a lot on twitter. That being said I did read the Hg Init tutorial, just to get a feel of the differences between the two. As it turnes out they are very similar, so it will probably be the integration with github, bitbucket, heroku and so on that will decide for me in each case.
Adam and Eve
First things first as they say, so getting started I downloaded and installed git. Then I wanted to do the most basic thing, which is to create a repository, and do a commit. To do this you right click a folder you want to use as the repository and open git bash. Then to create the repository you run git init – which creates a hidden folder called .git inside my repository folder.
Now to add files that are tracked you can run git add . to add all files. Later I learned that I will probably always use git add . –A which will also make sure deleted files are removed. All that was left was to run git commit –m “My initial commit message” to do the actual commit. Having to first add and then commit might seem redundant, but actually it makes perfect sense, because adding files is just part of building the package that makes up a commit since you might not want to add all files.
Talk to the hand
Actually as a .NET developer the “not wanting to add all files” is something we should address right away. Otherwise you will be tracking changes to dll’s that are the output of a build, and resharper files, which you probably don’t care about. So to get git to do the “talk to the hand" we can add a .gitignore file to the root or add lines to the exclude file with patterns that tell git which files to ignore. The exclude file is found in the .git/info directory and for .NET projects what you want is probably something like:
*resharper.user
[Dd]ebug/
[Rr]elease/
build/
[Bb]in/
[Oo]bj/
*.suo
*.sln.cache
_ReSharper.*/
*.user |  |
When doubt arises about what changes have happened git status will tell you the differences between what is commited and what is in the working tree.
Ctrl + Z * N
Probably one of the most important features of source control in the daily work is that it acts as a big a** Ctrl + Z that undoes the changes you regret. Git has acouple of ways of doing this, depending on if you already commited and if you have if you want the rollback to be reflected as a new commit, or if it should just be undone etc. I wont even try and cover all possible scenarios but these three handpicked scenarios should give you a good idea on how it works.
- To undo changes that have not been commited you can run git checkout –f which will force a checkout of the current branch overwriting any changes.
- To revert the last commit by making a new commit that does the opposite run git revert HEAD
- To undo run git reset <commit hash> <filename> where the hash can be found using git log which will show you the commit log.
Branching and merging
Another very important feature of a source control system is branching - which should be easy and painless – so it is easy to work in a branch while developing a new feature, so the trunk can remain stable. With git it really is easy, because all you need to do is run git branch to see which branches exist, git branch <branchname> to create a new branch called dev and git checkout <branchname> to switch between branches.
Then when you wish to merge branches you can run git merge <branchToMergeIntoCurrentBranch> and then if there are conflicts you can run git diff to see the conflicts or git mergetool which opens a tool where you can resolve the conflicts. After they are resolved you simply add and commit. To get an overview of the branches you can use gitk, which gives you a graphical representation of the history.
Teamwork
In real life, when working on more than just a pet project we will need to use a centralized repository. The easiest way to do this is to have a repository on a shared network drive. This should be created by running git init ––bare --shared=all. Now each teammember can run git clone <pathToFolder> to get a local copy of the repository. From there you can work normally, and when you wish to push your local repository changes to the share run git push origin master
If you have an existing repository that you wish to push you can use git remote add. As an example using appharbour, you run git remote add appharbor <appHarbourEndpoint> and push using git push appharbor master
Tools
I think it is important to get a basic understanding of git first, but being a Windows guy I do like to have some integration with Windows and with Visual Studio. So far I have looked at two tools that seem to do the trick which are Git Extentions and Git Source Control Provider, which is a Visual Studio extension. With these two tools you get menus both in Windows and Visual Studio that provides you with the most widely used commands, and you get integration with Solution Explorer. One of the really nice things is that you get a more easy to use place to configure misc. settings - including your name and email so you can track two made a given change.
Subscribe