Git version control
Version control is mandatory for software development, but can also be used for many other types of data, such as documents, configuration and presentations. You can use Git locally and collaborate with others via GitHub, but a local private Git server can do much the same as the public GitHub.
Git Version Control
In software development, a single project can consist of hundreds and sometimes thousands of source code files. If you have multiple people working on the same project, it's crucial that you have a version control system in place.
Centralized version control
Traditionally, version control has been a centralized version control system. You have a server that has all versions of the individual files, and then users can "check out" one or more files they want to work on. The downside of these systems is that typically only one person can check out the same file. Then others have to wait for the file to be checked in again and it's their turn. Another disadvantage is that you have a single point of failure. If the server is unavailable for any reason, everything stops for a while.
Examples of centralized version control systems I've worked with over the years: CVS, SourceSafe and Team Foundation Server.
Distributed version control
In 2005, Linus Torvald, the author of Linux, developed a new version control system Git. Git is a distributed version control system. Git version control is somewhat different from traditional version control systems. All versions and history can be in a repository local to each developer. You can also have a shared repository that is accessible to multiple developers working together. For example, it could be GitHub, but it could also just be another computer with Git installed.
Only at the point where a developer wants to send his changes into a shared repository, he performs a merge (if others have changed the same file). This eliminates the need to check out a file before changing it. It's fundamentally different from traditional version control systems. For me, it took a while before I could see the smartness of it. Once you get used to the idea, I now think it's a really good method.
Tools & Tools
Git version control is itself a command line tool, which is used by typing commands on the command line. So many people have created different graphical user interfaces on top of the command line tool. Maybe to make it a little easier to use, or perhaps more user-friendly.
Using git tools with a graphical user interface can also be great, and may be a good way to get started with git. I started out using the Sourcetree tool, and there are many others out there that are also great.
But...
It is important to note that all the graphical git tools are built on top of the command line tool git. Therefore, these graphical tools are an interpretation of the git tool that contains only a subset of the functionality of git. And when something goes wrong, you get error messages from the command line tool. It can sometimes be a little difficult to understand what's wrong if you only know the graphical tool.
Therefore, I would recommend starting by learning the command line tool git, even though it might be a bit more complicated. The trick to doing this is that once you've mastered the command line tool, you'll find it easy to understand all the different types of graphical tools you encounter and the error messages they can throw at you.
Many modern development environments also have built-in support for git, which is great. Then you can use git in the development environment for "everyday things", and then you can go to the command line when you need something a little more special.
Learn git version control on the command line
If you want to learn more about git, I recommend the book "Pro Git", which can be downloaded for free as a pdf file from git-scm.com, where you can also download installation files for git. You're also welcome to talk to me, I'd love to help you get started with git.
