This document is an in-depth review of the git branch command and a discussion of the general Git fork model. Branching is a feature available in most modern version control systems. Branching into other VCSs can be a costly operation in both time and disk space. In Git, branches are part of your daily development process. Git branches are effectively a pointer to a snapshot of changes. When you want to add a new feature or fix a bug, no matter how big or small, it generates a new branch to encapsulate your changes. This makes it more difficult for unstable code to merge with the main codebase, and gives you the opportunity to clean up the history of your future before merging it into the main branch.
The diagram above visualizes a repository with two isolated lines of development, one for a small feature and one for a higher-running feature. By developing them into branches, it is not only possible to work on both in parallel, but also keeps the main branch free of questionable code.
The implementation behind the Git branches is much lighter than other version control system models. Instead of copying files from one directory to another, Git stores a branch as a reference to a commit. In this sense, a branch represents the tip of a series of confirmations, it is not a container for confirmations. The history of a branch is extrapolated through commit relationships.
As you read, remember that Git branches are not like SVN branches. While SVN branches are only used to capture the occasional large-scale development effort, Git branches are an integral part of your daily workflow. The following content will extend the internal Git branch architecture.
How it works
A branch represents an independent line of development. The branches serve as abstraction for the editing/stage/confirmation process. You can think of them as a way to request a new working directory, staging area, and project history. New commits are recorded in the history of the current branch, resulting in a fork in the project history.
The git branch command allows you to create, enumerate, rename, and delete branches. It doesn’t allow you to switch between branches or reassemble a forked story. For this reason, the git branch is tightly integrated with the git checkout and git merge commands.
Common options
List all branches in the repository. This stands for git branch -list.
Create a new branch named . This does not unprotect the new branch.
Delete the specified branch. This is a “safe” operation where Git prevents you from deleting the branch if you have unmerged changes.
Force delete the specified branch, even if it has unmerged changes. This is the command you should use if you want to permanently discard all commits associated with a particular development line.
Rename the current branch to . List all remote branches. Creating branches It is important to
understand that branches are only indicators of confirmations. When you create a branch, all Git needs to do is create a new pointer, it doesn’t change the repository in any other way. If you start with a repository that looks like this
: 
Then, create a branch using the following command:
git branch crazy-experiment
The repository history remains unchanged. All you get is a new pointer to the current commit:
Note that this only creates the new branch. To start adding commits to it, you need to select it with git checkout and then use the standard git add and git commit commands.
Creating remote branch offices
So far, all of these examples have demonstrated local branch operations. The git branch command also works on remote branches. To operate in remote branch offices, you must first configure a remote repository and add it to the local repository configuration.
This command will send a copy of the crazy experiment from the local branch to the remote repository.
Deleting branches
Once you’re done working on a branch and merged it into the main codebase, you can delete the branch without losing any history
: git branch -d crazy-experiment
However, if the branch has not been merged, The above command will generate an error message
: Error: The ‘crazy-experiment’ branch is not completely merged. If you are sure you want to remove it, run ‘git branch -D crazy-experiment’.
This protects you from losing access to that entire line of development. If you really want to delete the branch (for example, it’s a failed experiment), you can use the uppercase -D flag:
git branch -D crazy-experiment
This deletes the branch regardless of its state and without warnings, so use it judiciously
.
The preceding commands will delete a local copy of a branch. The branch office may still exist in remote repositories. To delete a remote branch, run the following.
O
git push origin :crazy-experiment
This will send a delete signal to the remote source repository that triggers a deletion of the remote branch of crazy experiments
.
In
this paper we discuss Git branching behavior and the git branch command. The primary functions of git branch commands are to create, enumerate, rename, and delete branches. To operate further on the resulting branches, the command is commonly used with other commands such as git checkout. Learn more about git checkout branch operations; such as changing branches and merging branches, on the Git payment page.
Compared to other VCSs, Git branch operations are inexpensive and frequently used. This flexibility enables powerful customization of the Git workflow. To learn more about Git workflows, visit our expanded workflow discussion pages: Feature Branch Workflow, GitFlow Workflow, and Branch Workflow.