Git Rulez

Every project carried on by more than one person needs a Version Control System. In my opinion, it's a good idea to use a VCS for all non-trivial projects, even if you are the only developer.

According to Wikipedia:

[...] version control, also known as revision control or source control, is the management of changes to documents, computer programs, large web sites, and other collections of information

In my life as a developer, I've used only three VCS:

  • CVS (Concurrent Version System)
  • Borland StarTeam
  • Git/GitHub

and from the title of this post, you should have understood that I believe the last one is the best. Git has a lot of features that help to manage big projects ran by hundreds of developers, since it was created by Linus Torvalds with the purpose to maintain the sources of the Linux kernel. But don't be misled: it's not overkill for small projects.

How It Works

Git is a distributed VCS, this means that, when you clone a repository, you have the whole history and all the branches in your PC. The repository is compressed before being transferred, however the operation may take several minutes on huge repositories (like the following).

$ git clone https://github.com/torvalds/linux.git

You can work offline on your local copy of the repository and, when you are done, push it to the remote repository.

$ git push origin

The above command is OK in many cases but, if you are working on someone else's GitHub repository, you should use pull requests instead.

It's not said that the remote repository you want to push to is the main repository. It can be the repo of another developer (let's say Alice Smart) that is working with you on a specific feature.

$ git remote add alice git://github.com/alice_smart/fancy_project
$ git push alice

In this way two or more programmers can accomplish their work without impacting the whole dev team.

How many times a new features or a bug fix involve just one single file? Git does not track files but changes, even in multiple files. When you commit them, the modifications remain grouped together, so it's easier to identify all the changes and, if needed, revert the modification with just one command.

$ git commit --all
$ git revert HEAD

It's important to note that the reverted commit is not deleted. Simply a new commit with the changes applied in the reverse order is created. The cool thing is that the commit to be reverted can be any, not just the last one.

Moreover, this behavior lets you view an history of all the commits and lets you easily go in a well-known repository state even without having previously set a tag. The next command will rewind the history of your repository by 3 commits (again, without deleting anything).

$ git checkout HEAD~3

One of the best features of Git is the possibility to include in a commit just some rows of a modified file, thanks to the flag -p. This feature is greatly explained in this post: Git’s Patch Mode All the Way.

Branching

In a Git book I've read, it's written that books explaining other VCS talk of branching in the latest chapters. But in every Git book, you'll find branches treated within the first three or four chapters. Why this difference?

Simply because branching is a very powerful feature and in Git the creation a new branch is a very cheap operation. And with "cheap" I mean that there is no data duplication or hidden overhead. Simply two commits will have the same ancestor.

$ git branch new_feature
$ git checkout new_feature

The two rows above, create a new branch named new_feature and select it as the current one. The operation is immediate and no data duplication is made. The same operations can be made with a single command:

$ git checkout -b new_feature

When you work with branches (in whatever VCS) a typical need is to do the same modification (for example an urgent bug fix) on different branches. Git provides the cherry-pick command to do exactly this: to replay a commit (i.e. the changes made to one or more files) in another branch.

$ git cherry-pick 34f7ae0

Conclusions

This posts is only an overview of Git but I hope it's enough to make you understand how powerful this tool is. If you want to know more, take a look at the official Git website.

I've written other posts about Git: you can find them all here.


Image by Jason Long taken from Wikimedia Commons licensed under the Creative Commons Attribution 3.0 Unported license.

This post has been updated after its initial publication. Last change made on 2016/09/25.

Luca Sommacal

Luca Sommacal

Italian developer (mainly in C for embedded platforms), Linux learner, addicted to rock music, history, science and few other things. Follow me on Twitter

comments powered by Disqus