Subscribe to Anarion's Blog        RSS Feed

Git - A Distributed Version Control System

Icon 9 Comments
For the first time, I decided to try out Git, a distributed version control system; and also, write my first blog post! :D
So I visited Github and set up an account. Basically, github is used to make an online repository of projects, so that they can be shared with others.

In order to use git, I installed the git-core package and in a few minutes, I was ready to use it. Git's documentation explains things well; I learned the most useful commands in ~15 minutes and prepared a local git repository for a project I started a few months ago. One of the things I like about Git the most, is the use of branches. When a new repository is created, a default "master" branch is used; But it's a good idea to create a "testing" branch and work inside that one first, and then merge them when "testing" reaches a desireable state. This way, the master branch can be kept untouched and the testing branch is developed on actively; or even something like Debian's branches, which are worked on separately at a time, can be achieved.

So far, I have only tested Git on GNU/Linux, but had a look at the windows guide as well. The performance was a bit slow at my first try, don't know exactly what was making it slow. After the installation, when I wanted to switch between branches or commit a new snapshot, it took me a long time... but in the next system startup everything worked just fine!

Pushing a local repository to an online repository is quite straight-forward. If it's your first time using SSH, you have to make a key pair first, then add your public key to your github account... Right now I pushed my testing branch to github :)

For collaboration works, you can pull the modified branches from your online repository and check what files/lines have been changed. Also, if you modify a couple things in a branch, you can make a partially staged file(a patch) for some of the changes, rather than all of them. This might come very handy at times.

Conclusion: I am new to version control systems, but what I think about it right now is, "it's an easy way to get organized!".

9 Comments On This Entry

Page 1 of 1


29 July 2010 - 04:43 PM
Version control also lends itself to collaboration which makes merges and disjoint work on a project way easy.


30 July 2010 - 05:25 AM

Dark_Nexus, on 30 July 2010 - 02:13 AM, said:

Version control also lends itself to collaboration which makes merges and disjoint work on a project way easy.

I see... well, I haven't tried collaboration yet, but with the features I see, I am sure it is very well organized and therefore, easy.


31 July 2010 - 06:55 PM
There seems to be a lot of interest in distributed version control systems these days, but I admit that I don't see what their advantages are over centralized version control systems such as Subversion.


01 August 2010 - 12:04 AM
Git is not centralized, which means you don't have to have access to the main repository of project to be able to commit to it; basically you commit to your own local repository(which is a clone of the main repository). So, you work on your own cloned repository on your system separately; then contribute the parts you want to the main repository(for example, hosted on github). This is very important for a person like me, who has a (very?)limited internet service.

I believe [ This ] is a fair comparison by a person who uses both Git and SVN.


01 August 2010 - 05:59 AM

Anarion, on 31 July 2010 - 11:04 PM, said:

I believe [ This ] is a fair comparison by a person who uses both Git and SVN.

I've read these arguments before but they are not compelling to my mind. If you are collaborating on a project you still have to coordinate what you are doing otherwise you'll get conflicts. With Git you can commit while off-line, which is nice, but it hardly seems like a killer feature. Typically I work on a change for a few days before committing so as long as I get internet access on a semi-daily basis Subversion's approach is fine.

I can see that Git's method would work well if you want to make your own personal modifications to a popular open source code base. However, the cost is that you have to download and store the entire history of the project... huge volumes of information you'll probably never need. At least that's how Mercurial works. I haven't tried Git. In any case when a small team is working closely or when someone is working alone the advantages of the distributed approach seem slight at best. For example with Subversion I can also create an entirely local repository for my personal work and then use it without any internet access at all.


01 August 2010 - 09:41 AM


In any case when a small team is working closely or when someone is working alone the advantages of the distributed approach seem slight at best

In fact, Git is best useful for entirely large projects with many contributors (possibly from different countries). That's why it is used for Linux' Kernel development. I guess you missed the merge feature of git; your contributions can be easily merged with other branches(and/or repositories), so the conflicts between repositories are easily wiped out. Also aside from complete staging, you have partially staging that allows you to send patches to a repository.

Anyways, no one says Git is better than SVN or others, the fact is that, they work different. So the question is "Do I need a distributed system or a centralized system for my project?".


01 August 2010 - 03:31 PM
Yes, I don't mean to pick on Subversion or Git specifically. I'm only trying to understand the issues surrounding distributed vs centralized version control. I do know about merging. All VCS support merging in some form. However, if two developers both modify the same line in the same file, it is beyond the ability of the VCS to merge those changes since it has no understanding about the nature of the changes. Those are the "conflicts" I'm talking about. I don't think a distributed VCS makes those conflicts any less likely or handling them any easier than a centralized VCS. I can commit changes to my local repository all I want but when (and if) those changes need to get integrated upstream then conflicts could still occur and they would still need to be resolved manually.

I can see the value of a distributed VCS when there are many people interested in following the main line of development while also making their own local and relatively private changes. If I want to hack something into the Linux kernel for my own purposes I'll still want to integrate changes made by others to unrelated parts of the kernel. If my hack turns out to be genius and the core developers decide that it should be integrated into the main line, I would want it to be (fairly) easy to do that. The key point here is: I'm not an "official" kernel developer. I want to use the kernel's VCS but I also want to be able to make whatever changes I need privately. Something like Git would be great for that (except for the part about forcing me to download the huge history of all kernel changes). The other use cases I mentioned... a single developer working alone or a well defined team who is making an effort to stay synchronized... don't seem to lend themselves to distributed version control.


02 August 2010 - 01:38 PM
From what i have read and viewed, the main reason why git is such a great source code management system is simply because of its distributed development approach. Ensuring that there are nth versions of the same thing, allowing users to commit locally only until a point of stability is reached where they can push ask others to pull perhaps a new or improved feature from them. Keeping things local allows for experimentation and work within smaller teams within larger development teams. When you have a centralised system such as SVN / CVS you have issues with read / write access and at times corruption. Git uses a SHA1 hash to ensure that you are receiving exactly the same information from the repository that was put in.

All this is explained far better by Linus Torvald's -


03 August 2010 - 06:53 AM
This discussion has helped me to understand how distributed version control systems can be used effectively. I'll have to try Git, or maybe Mercurial, in my next project.

Page 1 of 1

May 2022

15 16 1718192021


    Recent Entries

    Recent Comments

    Search My Blog

    2 user(s) viewing

    2 Guests
    0 member(s)
    0 anonymous member(s)