=== Understanding Branches
Without getting into the internals of how Git works, having a basic understanding of what a branch is will help you to choose and apply the strategies outlined in this chapter.
Each Git repository contains a pool of commits. These commits are linked to one-another through their metadata--each commit contains a reference to its parent. In the case of a merge commit, there may be more than one parent commit referenced. I like to think of a branch as a string of beads, which each commit represented as a bead on the string. The analogy isn't technically correct, but it works quite well as a mental model for most purposes.
Branches in Git are actually a named pointer to a specific commit. (Give yourself a magic wand, and tap on a specific bead while saying a name. This is a branch.) When you check out a branch, you are requesting the data stored in that special commit object be copied into your working directory. Once the work has been copied into the working directory, you can make as many changes as you like (add, edit, delete files), and save your changes as a new commit object.
Any commit objects you create in your local repository are uniquely yours until you choose to explicitly share them with a remote repositories. This is radically different than the centralized model of version control where committing a change automatically uploads the work.
Within each repository, the database of commit objects includes both the local, editable content as well as a copy of the non-editable content contained in any of the remote repositories you are connected to. The database of remote references is updated only when you explicitly ask for updates. When you share a branch with others, you may continue adding commit objects to it locally; however, if someone else also adds commit objects to their copy of your branch, you can run into problems the next time you try to identify the specific bead which represents the commit object at the tip of the branch.
To avoid conflict, developers have created conventions for the naming and use of branches. These conventions help developers to choose when to allow work to diverge (create new branch), and when to merge (combine commit objects from two or more branches). Generally there are two types of branches used in a convention: a long-running public branch; and a short-lived private branch. The function of a long-running branch is to act as a mediator for code which is contributed by lots of developers. The function of a short-lived branch is to sandbox the development of a new idea. These new ideas could be bug fixes, feature additions, or experimental refactoring. It's up to you!
As you add commit objects to the tip of a branch, you advance the pointer for your copy of the named branch to your latest commit object in your local repository. Remembering that each developer has their own magic wand for their own repository provides the foreshadowing we need to understand where conflicts come from.
You will learn about how to keep your branches up-to-date in [Updating Branches]. First, though, let's take a look at some of the most common branch naming strategies developers use for maintaining their work in Git.