Git is a distributed version control system (DVCS). It allows a developer in Japan, say, and another in New Jersey to make and record changes independently, and it permits the two developers to combine their changes at any time—all without a central repository. In this chapter, we’ll learn how to combine two or more different lines of development.
A merge unifies two or more commit history branches. Most often, a merge unites just two branches, although Git supports a merge of three, four, or many branches at the same time.
In Git, a merge must occur within a single repository—that is, all the branches to be merged must be present in the same repository. How the branches come to be in the repository is not important. (As you will see in Chapter 11, Git provides mechanisms for referring to other repositories and for bringing remote branches into your current working repository.)
When modifications in one branch do not conflict with modifications found in another branch, Git computes a merge result and creates a new commit that represents the new, unified state. But when branches conflict, which occurs whenever changes compete to alter the same line of the same file, Git does not resolve the dispute. Instead, Git marks such contentious changes as “unmerged” in the index and leaves reconciliation to you, the developer. When Git cannot merge automatically, it’s also up to you to make the final commit once all conflicts are resolved.