There may be many different branches within a repository at any given time, but there is at most one “active” or “current” branch. The active branch determines what files are checked out in the working directory. Furthermore, the current branch is often an implicit operand in Git commands, such as the target of the merge operation. By default, master is the active branch, but you can make any branch the current branch.

A branch allows the content of the repository to diverge in many directions, one per branch. Once a repository forks at least one branch, each commit is applied to one branch or the other, whichever is active.

Each branch in a specific repository must have a unique name, and the name always refers to the most recent revision committed on that branch. The most recent commit on a branch is called the tip, or head, of the branch.

Git doesn’t keep information about where a branch originated. Instead, the branch name moves incrementally forward as new commits are made on the branch. Older commits must therefore be named by their hash or via a relative name such as dev~5. If you want to keep track of a particular commit—because it represents a stable point in the project, say, or is a version you want to test—you can explicitly assign it a lightweight tag name.

Because the original commit from which a branch was started is not explicitly identified, that commit (or its equivalent) can be found algorithmically using the name of the original branch from which the new branch forked:

$ git merge-base original-branch new-branch

A merge is the complement of a branch. When you merge, the content of one or more branches is joined with an implicit target branch. However, a merge does not eliminate any of the source branches or those branches’ names. The rather complex process of merging branches is the focus of Chapter 9.

You can think of a branch name as a pointer to a particular (albeit evolving) commit. A branch includes the commits sufficient to rebuild the entire history of the project along the branch from which it came, all the way back to the very beginning of the project.

In Figure 7-1, the dev branch name points to the head commit, Z. If you wanted to rebuild the repository state at Z, all the commits reachable from Z back to the original commit, A, are needed. The reachable portion of the graph is highlighted with wide lines and covers every commit except (S, G, H, J, K, L).

Figure 7-1. Commits reachable from dev

Each of your branch names, as well as the committed content on each branch, is local to your repository. However, when making your repository available to others, you can publish, or elect to make one or any number of branches and the associated commits available, too. Publishing a branch must be done explicitly. Also, if your repository is cloned, your branch names and the development on those branches will all be part of the newly cloned repository copy.