I am going to explain how I learned to work with Git as a distributed version control system in this post. My intention is to be able to contribute to open source projects hosted on GitHub and to be able to work with a source control when I am not connected to any network.
There are many great tutorials and guides on the web that explain in detail how Git works and what we can do with it. I am not going to compete against these great resources in this post. This post explains my personal experiences during the process of learning Git. Furthermore, there could be some tips especially for those who have deep knowledge in using Subversion and start learning about Git.
Differences between Git and Subversion
In Subversion, we have a repository mostly located on a server or file share and a private checkout of this repository. When you start using Git, you have to completely forget that knowledge. At least, you should not try to reuse that knowledge when using Git.
The only thing Git and Subversion have in common is that there is a repository. Instead of checking out a repository to a local directory, we clone the entire repository. This means that any information stored in the repository will also be copied (or cloned) to our local repository.
This is basically the concept of Git which makes it very powerful. We don’t have to call the server if we want some information about the change log for example. There are many other things we can do because of this concept which I won’t describe here.
Working with the shell
This is something I have learned from the community (@danimeier, @FDeitelhoff). Although there are many (Windows) GUI clients available, I highly recommend working with the shell in the first place. For me, this was pretty hard to grasp at the beginning as a regular Windows user.
Is it possible that this tool called Git is so powerful and important if I am to use the shell instead of a nice looking graphical application? Yes, it is. After working with the shell for some days, I learned why we should do so when learning about Git.
Some of the commands have many options and can be widely used. It is hard to remember all of them at the beginning. But after a short period of time, you will exactly know what those instructions mean and how to correctly execute them.
After some more time with the shell, you will be very effective and efficient using the shell. Another advantage is that you can automate your workflows very easily because you already know about the necessary commands.
I had a pretty interesting time reading the Pro Git book online. I recommend this resource for a beginner. The good thing about Pro Git is, that there is an online version licensed under the Creative Commons Attribution Non-Commercial Share Alike 3.0 license. This means that it is completely free.
If you would like to have a hard copy of the book, have a look at its Amazon page.
Git Cheat Sheet
Using a cheat sheet can help you to be efficient. You can see them daily if you place these sheets somewhere, like a wall behind your monitors, they’ll help you a lot.
Getting started can be a tough thing. Git is not Subversion and we have to deal with the shell. Once we feel comfortable working with the shell and know the most important commands it gets interesting.
I am currently evaluating whether I should move my source code from a Mercurial-based Bitbucket repository to a Git repository. Although I have moved only months ago, it seems logical to have all the source code using the same version control system.
The Pareto Principle applies also to learning Git. We don’t need to know every command right from the beginning. If we know 20% of the commands used for 80% of the work, we have mastered Git and can use it in an efficient and effective way. There is always space to improve. Just use it.