Version Control with Git

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.

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 ...