From the official Git documentation, the term branch is defined as a lightweight movable pointer to a commit. The main branch in Git, by default, is referred to as master and, ideally, this branch should have the most stable code base that is ready for release. As many developers work on a project, the ideal workflow is as follows: one branches off the master (hence the term branch), makes the changes they need, such as adding features and fixing bugs, and then, after they are done, they commit those changes and request a merge back to the master branch, a process referred to on GitHub as making a pull request (PR).

Going back to our definition of a branch, we can see that, as we do this, we are moving this commit pointer outside the main branch so as to not destabilize our code, and once our code is considered worthy or bug-free, it is merged back.

One of the best analogies of branching is one on timelines. Think of a branch as a timeline. The main timeline is the master branch. When we create a branch, we create a new timeline from the master timeline and perform changes to the code base. When we want to merge back to the main timeline, we request a merge and, if our changes did not introduce any bugs or errors, then we are allowed to merge.

We can visualize our workflow as shown in the following diagram: