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 ...
Get Version Control with Git now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.