git-branch(1)

NAME#

git-branch - List, create, or delete branches

SYNOPSIS#

git branch\n [--color[=<when>] | --no-color] [--show-current]
\n
        [-v [--abbrev=<n> | --no-abbrev]]
\n
        [--column[=<options>] | --no-column] [--sort=<key>]
\n
        [--merged [<commit>]] [--no-merged [<commit>]]
\n
        [--contains [<commit>]] [--no-contains [<commit>]]
\n
        [--points-at <object>] [--format=<format>]
\n
        [(-r | --remotes) | (-a | --all)]
\n
        [--list] [<pattern>...]
\ngit branch\n [--track[=(direct|inherit)] | --no-track] [-f]
\n
        [--recurse-submodules] <branchname> [<start-point>]
\ngit branch\n (--set-upstream-to=<upstream> | -u <upstream>) [<branchname>]
\ngit branch\n --unset-upstream [<branchname>]
\ngit branch\n (-m | -M) [<oldbranch>] <newbranch>
\ngit branch\n (-c | -C) [<oldbranch>] <newbranch>
\ngit branch\n (-d | -D) [-r] <branchname>...
\ngit branch\n --edit-description [<branchname>]

DESCRIPTION#

If --list is given, or if there are no non-option arguments, existing branches are listed; the current branch will be highlighted in green and marked with an asterisk. Any branches checked out in linked worktrees will be highlighted in cyan and marked with a plus sign. Option -r causes the remote-tracking branches to be listed, and option -a shows both local and remote branches.

If a <pattern> is given, it is used as a shell wildcard to restrict the output to matching branches. If multiple patterns are given, a branch is shown if it matches any of the patterns.

Note that when providing a <pattern>, you must use --list; otherwise the command may be interpreted as branch creation.

With --contains, shows only the branches that contain the named commit (in other words, the branches whose tip commits are descendants of the named commit), --no-contains inverts it. With --merged, only branches merged into the named commit (i.e. the branches whose tip commits are reachable from the named commit) will be listed. With --no-merged only branches not merged into the named commit will be listed. If the <commit> argument is missing it defaults to HEAD (i.e. the tip of the current branch).

The command’s second form creates a new branch head named <branchname> which points to the current HEAD, or <start-point> if given. As a special case, for <start-point>, you may use "A...B" as a shortcut for the merge base of A and B if there is exactly one merge base. You can leave out at most one of A and B, in which case it defaults to HEAD.

Note that this will create the new branch, but it will not switch the working tree to it; use "git switch <newbranch>" to switch to the new branch.

When a local branch is started off a remote-tracking branch, Git sets up the branch (specifically the branch.<name>.remote and branch.<name>.merge configuration entries) so that git pull will appropriately merge from the remote-tracking branch. This behavior may be changed via the global branch.autoSetupMerge configuration flag. That setting can be overridden by using the --track and --no-track options, and changed later using git branch --set-upstream-to.

With a -m or -M option, <oldbranch> will be renamed to <newbranch>. If <oldbranch> had a corresponding reflog, it is renamed to match <newbranch>, and a reflog entry is created to remember the branch renaming. If <newbranch> exists, -M must be used to force the rename to happen.

The -c and -C options have the exact same semantics as -m and -M, except instead of the branch being renamed, it will be copied to a new name, along with its config and reflog.

With a -d or -D option, <branchname> will be deleted. You may specify more than one branch for deletion. If the branch currently has a reflog then the reflog will also be deleted.

Use -r together with -d to delete remote-tracking branches. Note, that it only makes sense to delete remote-tracking branches if they no longer exist in the remote repository or if git fetch was configured not to fetch them again. See also the prune subcommand of git-remote(1) for a way to clean up all obsolete remote-tracking branches.

OPTIONS#

-d, --delete

-D

--create-reflog

-f, --force

Note that git branch -f <branchname> [<start-point>], even with -f, refuses to change an existing branch <branchname> that is checked out in another worktree linked to the same repository.

-m, --move

-M

-c, --copy

-C

--color[=<when>]

--no-color

-i, --ignore-case

--omit-empty

--column[=<options>], --no-column

This option is only applicable in non-verbose mode.

-r, --remotes

-a, --all

-l, --list

--show-current

-v, -vv, --verbose

-q, --quiet

--abbrev=<n>

--no-abbrev

-t, --track[=(direct|inherit)]

The exact upstream branch is chosen depending on the optional argument: -t, --track, or --track=direct means to use the start-point branch itself as the upstream; --track=inherit means to copy the upstream configuration of the start-point branch.

The branch.autoSetupMerge configuration variable specifies how git switch, git checkout and git branch should behave when neither --track nor --no-track are specified:

The default option, true, behaves as though --track=direct were given whenever the start-point is a remote-tracking branch. false behaves as if --no-track were given. always behaves as though --track=direct were given. inherit behaves as though --track=inherit were given. simple behaves as though --track=direct were given only when the start-point is a remote-tracking branch and the new branch has the same name as the remote branch.

See git-pull(1) and git-config(1) for additional discussion on how the branch.<name>.remote and branch.<name>.merge options are used.

--no-track

--recurse-submodules

When used in branch creation, a new branch <branchname> will be created in the superproject and all of the submodules in the superproject’s <start-point>. In submodules, the branch will point to the submodule commit in the superproject’s <start-point> but the branch’s tracking information will be set up based on the submodule’s branches and remotes e.g. git branch --recurse-submodules topic origin/main will create the submodule branch "topic" that points to the submodule commit in the superproject’s "origin/main", but tracks the submodule’s "origin/main".

--set-upstream

-u <upstream>, --set-upstream-to=<upstream>

--unset-upstream

--edit-description

--contains [<commit>]

--no-contains [<commit>]

--merged [<commit>]

--no-merged [<commit>]

<branchname>

<start-point>

<oldbranch>

<newbranch>

--sort=<key>

--points-at <object>

--format <format>

CONFIGURATION#

pager.branch is only respected when listing branches, i.e., when --list is used or implied. The default is to use a pager. See git-config(1).

Everything above this line in this section isn’t included from the git-config(1) documentation. The content that follows is the same as what’s found there:

branch.autoSetupMerge

branch.autoSetupRebase

branch.sort

branch.<name>.remote

branch.<name>.pushRemote

branch.<name>.merge

branch.<name>.mergeOptions

branch.<name>.rebase

When merges (or just m), pass the --rebase-merges option to git rebase so that the local merge commits are included in the rebase (see git-rebase(1) for details).

When the value is interactive (or just i), the rebase is run in interactive mode.

NOTE: this is a possibly dangerous operation; do not use it unless you understand the implications (see git-rebase(1) for details).

branch.<name>.description

EXAMPLES#

Start development from a known tag

$ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6
$ cd my2.6
$ git branch my2.6.14 v2.6.14   \n(1)\n
$ git switch my2.6.14

Delete an unneeded branch

$ git clone git://git.kernel.org/.../git.git my.git
$ cd my.git
$ git branch -d -r origin/todo origin/html origin/man   \n(1)\n
$ git branch -D test                                    \n(2)

Listing branches from a specific remote

$ git branch -r -l '<remote>/<pattern>'                 \n(1)\n
$ git for-each-ref 'refs/remotes/<remote>/<pattern>'    \n(2)

Patterns will normally need quoting.

NOTES#

If you are creating a branch that you want to switch to immediately, it is easier to use the "git switch" command with its -c option to do the same thing with a single command.

The options --contains, --no-contains, --merged and --no-merged serve four related but different purposes:

When combining multiple --contains and --no-contains filters, only references that contain at least one of the --contains commits and contain none of the --no-contains commits are shown.

When combining multiple --merged and --no-merged filters, only references that are reachable from at least one of the --merged commits and from none of the --no-merged commits are shown.

SEE ALSO#

git-check-ref-format(1), git-fetch(1), git-remote(1), “Understanding history: What is a branch?”[1] in the Git User’s Manual.

GIT#

Part of the git(1) suite

NOTES#

1.

“Understanding history: What is a branch?”