O'Reilly logo

Version Control with Git by Jon Loeliger

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Merge Strategies

So far, our examples have been easy to handle because there are only two branches. It might seem like Git’s extra complexity of DAG-shaped history and long, hard-to-remember commit IDs isn’t really worth it. And maybe it isn’t, for such a simple case. But let’s look at something a little more complicated.

Imagine that instead of just one person working on in your repository, there are three. To keep things simple, suppose that each developer—Alice, Bob, and Cal—is able to contribute changes as commits on three separate eponymous branches within a shared repository.

Since the developers are all contributing to separate branches, let’s leave it up to one person, Alice, to manage the integration of various contributions. In the meantime, each developer is allowed to leverage the development of the others by directly incorporating or merging a coworker’s branch, as needed.

Eventually, the coders develop a repository with a commit history as shown in Figure 9-1.

Criss-cross merge setup

Figure 9-1. Criss-cross merge setup

Imagine that Cal started the project and Alice joined in. Alice worked on it for a while, then Bob joined in. In the meantime, Cal has been working away on his own version.

Eventually, Alice merged in Bob’s changes, and Bob kept on working without merging Alice’s changes back into his tree. There are now three different branch histories as shown in Figure 9-2.

Figure 9-2. After Alice ...

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required