What does linear history mean in revision control?

Question

Few times I heard about keeping linear history in Git or Mercurial. What does it practically mean? Can someone provide me with simple example?

Answer 1

TL;DR - In linear source control, each change must be made after the other. In non-linear source control, simultaneous code changes can be made at any point and merged into the main line.

If your code under source control has a linear history, it means that each committed change in code is made after the previous one. Think of it as a long, single chain of code changes, like this:

[A]---->[B]---->[C]---->[D]
                         *

The * denotes HEAD.

With this approach, you must always be working off the latest code, so if you're on commit [B] and you're currently working on the changes that will eventually be commit [D], you need to pull from the repository to get the changes from [C] in order to push your code without conflicts.

However, Git lets you branch your code, so you can work on multiple versions of the code at once. Let's say this is how your commit history looks so far:

[A]---->[B]
         *

Now suppose you want to make some changes, but you don't want to disturb [B]. (Maybe other people are working on this code simultaneously, who knows?) In Git, you can branch from the commit you're on to work on your own version of the current code. This is a cornerstone of Git: multiple people can work on the same file without overwriting each other's changes. This is a huge advantage over source control with strictly linear history, where code collision is much more of a nuisance.

Anyway, back to the example. You create a new branch while others continue to push changes to the original master branch.

[A]---->[B]
           \
            [E]
             *

Let's say they make two commits, [C] and [D] while you're on your own branch:

[A]---->[B]---->[C]---->[D]
           \
            [E]
             *

Now, it doesn't matter what they're doing, since in your branch, you have your own copy of the code, and you're free to do whatever you want with it. So you make two commits on your branch, [F] and [G]:

[A]---->[B]---->[C]---->[D]
           \                   
            [E]---->[F]---->[G]
                             *

After testing your changes, you decide it's good enough to merge back into master:

                                 *
[A]---->[B]---->[C]---->[D]---->[H]
           \                   /
            [E]---->[F]---->[G]

This is basically how non-linear source control works. You can see it's pretty easy for a lot of people to work off the same cut of code without stepping on toes. Now, if two people are working on the same file, there will still be merging conflicts, but Git has a nifty tool called git-merge that facilitates merging two people's concurrent changes on the same file.