How to create new branch git

How to create new branch git

docs book git branch list, create and manage working contexts

docs book git checkout switch to a new branch context

git branch list your available branches

Without arguments, git branch will list out the local branches that you have. The branch that you are currently working on will have a star next to it and if you have coloring turned on, will show the current branch in green.

git branch (branchname) create a new branch

So now we can see that when we switch to the ‘testing’ branch, our new files were removed. We could switch back to the ‘master’ branch and see them re-appear.

You can see there how we created a branch, removed some of our files while in the context of that branch, then switched back to our main branch and we see the files return. Branching safely isolates work that we do into contexts we can switch between.

If you start on work it is very useful to always start it in a branch (because it’s fast and easy to do) and then merge it in and delete the branch when you’re done. That way if what you’re working on doesn’t work out you can easily discard it and if you’re forced to switch back to a more stable context your work in progress is easy to put aside and then come back to.

git push (remote-name) :(branchname) delete a remote branch

When you’re done with a remote branch, whether it’s been merged into the remote master or you want to abandon it and sweep it under the rug, you’ll issue a git push command with a specially placed colon symbol to remove that branch.

In the above example you’ve deleted the «tidy-cutlery» branch of the «origin» remote. A way to remember this is to think of the git push remote-name local-branch:remote-branch syntax. This states that you want to push your local branch to match that of the remote. When you remove the local-branch portion you’re now matching nothing to the remote, effectively telling the remote branch to become nothing.

In a nutshell you use git branch to list your current branches, create new branches and delete unnecessary or already merged branches.

docs book git merge merge a branch context into your current one

Once you have work isolated in a branch, you will eventually want to incorporate it into your main branch. You can merge any branch into your current branch with the git merge command. Let’s take as a simple example the ‘removals’ branch from above. If we create a branch and remove files in it and commit our removals to that branch, it is isolated from our main (‘master’, in this case) branch. To include those deletions in your ‘master’ branch, you can just merge in the ‘removals’ branch.

more complex merges

So first we’re going to create a new branch named ‘change_class’ and switch to it so your class renaming changes are isolated. We’re going to change each instance of ‘HelloWorld’ to ‘HiWorld’.

Now those changes are recorded in the ‘master’ branch. Notice that the class name is back to ‘HelloWorld’, not ‘HiWorld’. To incorporate the ‘HiWorld’ change we can just merge in the ‘change_class’ branch. However, the name of the file has changed since we branched, what will Git do?

Well, it will just figure it out. Notice that there are no merge conflicts and the file that had been renamed now has the ‘HiWorld’ class name change that was done in the other branch. Pretty cool.

merge conflicts

So, Git merges are magical, we never ever have to deal with merge conflicts again, right? Not quite. In situations where the same block of code is edited in different branches there is no way for a computer to figure it out, so it’s up to us. Let’s see another example of changing the same line in two branches.

Now we have committed a change to one line in our README file in a branch. Now let’s change the same line in a different way back on our ‘master’ branch.

You can see that Git inserts standard merge conflict markers, much like Subversion, into files when it gets a merge conflict. Now it’s up to us to resolve them. We will do it manually here, but check out git mergetool if you want Git to fire up a graphical mergetool (like kdiff3, emerge, p4merge, etc) instead.

And now we’ve successfully resolved our merge conflict and committed the result.

In a nutshell you use git merge to combine another branch context into your current branch. It automatically figures out how to best combine the different snapshots into a new snapshot with the unique work of both.

docs book git log show commit history of a branch

To understand the log command, you have to understand what information is stored when you run the git commit command to store a snapshot. In addition to the manifest of files and commit message and information about the person who committed it, Git also stores the commit that you based this snapshot on. That is, if you clone a project, what was the snapshot that you modified to get to the snapshot that you saved? This is helpful to give context to how the project got to where it is and allows Git to figure out who changed what. If Git has the snapshot you save and the one you based it on, then it can automatically figure out what you changed. The commit that a new commit was based on is called the «parent».

To see a chronological list of the parents of any branch, you can run git log when you are in that branch. For example, if we run git log in the Hello World project that we have been working on in this section, we’ll see all the commit messages that we’ve done.

What this is telling us is that this is the history of the development of this project. If the commit messages are descriptive, this can inform us as to what all changes have been applied or have influenced the current state of the snapshot and thus what is in it.

Now we can more clearly see when effort diverged and then was merged back together. This is very nice for seeing what has happened or what changes are applied, but it is also incredibly useful for managing your branches. Let’s create a new branch, do some work in it and then switch back and do some work in our master branch, then see how the log command can help us figure out what is happening on each.

Since we’re having fun playing in functional programming languages we get caught up in it and also add a Haskell example program while still in the branch named ‘erlang’.

Finally, we decide that we want to change the class name of our Ruby program back to the way it was. So, we can go back to the master branch and change that and we decide to just commit it directly in the master branch instead of creating another branch.

So, now say we don’t work on the project for a while, we have other things to do. When we come back we want to know what the ‘erlang’ branch is all about and where we’ve left off on the master branch. Just by looking at the branch name, we can’t know that we made Haskell changes in there, but using git log we easily can. If you give Git a branch name, it will show you just the commits that are «reachable» in the history of that branch, that is the commits that influenced the final snapshot.

This way, it’s pretty easy to see that we have Haskell code included in the branch (highlighted in the output). What is even cooler is that we can easily tell Git that we only are interested in the commits that are reachable in one branch that are not reachable in another, in other words which commits are unique to a branch in comparison to another.

This gives us a nice, simple branch management tool. It allows us to easily see what commits are unique to which branches so we know what we’re missing and what we would be merging in if we were to do a merge.

In a nutshell you use git log to list out the commit history or list of changes people have made that have lead to the snapshot at the tip of the branch. This allows you to see how the project in that context got to the state that it is currently in.

docs book git tag tag a point in history as important

If we do more commits, the tag will stay right at that commit, so we have that specific snapshot tagged forever and can always compare future snapshots to it.

We don’t have to tag the commit that we’re on, however. If we forgot to tag a commit that we released, we can retroactively tag it by running the same command, but with the commit SHA at the end. For example, say we had released commit 558151a (several commits back) but forgot to tag it at the time. We can just tag it now:

In a nutshell you use git tag to mark a commit or point in your repo as important. This also allows you to refer to that commit with a more memorable reference than a SHA.

Nearly every VCS has some form of branching support. Branching means you diverge from the main line of development and continue to do work without messing with that main line. In many VCS tools, this is a somewhat expensive process, often requiring you to create a new copy of your source code directory, which can take a long time for large projects.

Some people refer to Git’s branching model as its “killer feature,” and it certainly sets Git apart in the VCS community. Why is it so special? The way Git branches is incredibly lightweight, making branching operations nearly instantaneous, and switching back and forth between branches generally just as fast. Unlike many other VCSs, Git encourages workflows that branch and merge often, even multiple times in a day. Understanding and mastering this feature gives you a powerful and unique tool and can entirely change the way that you develop.

Branches in a Nutshell

To really understand the way Git does branching, we need to take a step back and examine how Git stores its data.

As you may remember from What is Git?, Git doesn’t store data as a series of changesets or differences, but instead as a series of snapshots.

When you make a commit, Git stores a commit object that contains a pointer to the snapshot of the content you staged. This object also contains the author’s name and email address, the message that you typed, and pointers to the commit or commits that directly came before this commit (its parent or parents): zero parents for the initial commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches.

To visualize this, let’s assume that you have a directory containing three files, and you stage them all and commit. Staging the files computes a checksum for each one (the SHA-1 hash we mentioned in What is Git?), stores that version of the file in the Git repository (Git refers to them as blobs), and adds that checksum to the staging area:

Your Git repository now contains five objects: three blobs (each representing the contents of one of the three files), one tree that lists the contents of the directory and specifies which file names are stored as which blobs, and one commit with the pointer to that root tree and all the commit metadata.

If you make some changes and commit again, the next commit stores a pointer to the commit that came immediately before it.

The “master” branch in Git is not a special branch. It is exactly like any other branch. The only reason nearly every repository has one is that the git init command creates it by default and most people don’t bother to change it.

Creating a New Branch

This creates a new pointer to the same commit you’re currently on.

You can see the master and testing branches that are right there next to the f30ab commit.

Switching Branches

To switch to an existing branch, you run the git checkout command. Let’s switch to the new testing branch:

This moves HEAD to point to the testing branch.

What is the significance of that? Well, let’s do another commit:

This is interesting, because now your testing branch has moved forward, but your master branch still points to the commit you were on when you ran git checkout to switch branches. Let’s switch back to the master branch:

If you were to run git log right now, you might wonder where the «testing» branch you just created went, as it would not appear in the output.

The branch hasn’t disappeared; Git just doesn’t know that you’re interested in that branch and it is trying to show you what it thinks you’re interested in. In other words, by default, git log will only show commit history below the branch you’ve checked out.

That command did two things. It moved the HEAD pointer back to point to the master branch, and it reverted the files in your working directory back to the snapshot that master points to. This also means the changes you make from this point forward will diverge from an older version of the project. It essentially rewinds the work you’ve done in your testing branch so you can go in a different direction.

It’s important to note that when you switch branches in Git, files in your working directory will change. If you switch to an older branch, your working directory will be reverted to look like it did the last time you committed on that branch. If Git cannot do it cleanly, it will not let you switch at all.

Let’s make a few changes and commit again:

Because a branch in Git is actually a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy. Creating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline).

This is in sharp contrast to the way most older VCS tools branch, which involves copying all of the project’s files into a second directory. This can take several seconds or even minutes, depending on the size of the project, whereas in Git the process is always instantaneous. Also, because we’re recording the parents when we commit, finding a proper merge base for merging is automatically done for us and is generally very easy to do. These features help encourage developers to create and use branches often.

Let’s see why you should do so.

From Git version 2.23 onwards you can use git switch instead of git checkout to:

Git FAQ

Frequently asked questions around Git and Version Control.

How do I create a new branch in Git?

Git makes creating and managing branches very easy. In fact, the power and flexibility of its branching model is one of the biggest advantages of Git!

There are a couple of different use cases when creating branches in Git. Let’s look at each of them in turn.

How do I create a new branch based on the current HEAD?

To create a new branch that is based on your currently checked out (HEAD) branch, simply use «git branch» with the name of the new branch as the only parameter:

How do I create a new branch based on some existing one?

If you want to base your new branch on a different existing branch, simply add that branch’s name as a starting point:

If you’re using the Tower Git client, you can simply use drag and drop to create new branches (and to merge, cherry-pick, etc.):

How do I create a new branch from a specific commit?

If you want to start your new branch based on a specific commit (not a branch), then you can provide the commit hash as the starting point:

How do I create a new branch from a specific tag?

You can also base your new branch on a specific tag you already have in your repository:

How do I create a new branch from a remote branch?

To take a remote branch as the basis for your new local branch, you can use the «—track» option:

Alternatively, you can also use the «checkout» command to do this. If you want to name the local branch like the remote one, you only have to specify the remote branch’s name:

How do I create a new branch in a remote repository?

After working on your new local branch for some time, you might want to publish it in your remote repository, to share it with your team:

The «-u» flag tells Git to establish a «tracking connection», which will make pushing and pulling much easier in the future.

What does the «git branch» command do?

The «git branch» command is used for a variety of tasks:

Learn More

Get our popular Git Cheat Sheet for free!

You’ll find the most important commands on the front and helpful best practice tips on the back. Over 100,000 developers have downloaded it to make Git a little bit easier.

About Us

As the makers of Tower, the best Git client for Mac and Windows, we help over 100,000 users in companies like Apple, Google, Amazon, Twitter, and Ebay get the most out of Git.

Just like with Tower, our mission with this platform is to help people become better professionals.

That’s why we provide our guides, videos, and cheat sheets (about version control with Git and lots of other topics) for free.

How to Create a New Branch in Git

Home » SysAdmin » How to Create a New Branch in Git

Git is an open-source version-control system for tracking changes during the software development life cycle.

It’s mutually independent branching model makes it stand out. Branches can be based on previous versions of the software to maintain the integrity of current progress while working on a bug fix or new feature.

This guide will detail multiple options to create a new branch in Git.

Note: This guide uses a Linux environment. Git is also available on Windows and macOS.

Create a New Git Branch

There are many ways to create a new Git branch. In most cases it comes down to whether you are creating a branch from the main branch or, for example, a new commit or tag.

One common method of creating a new branch is with the command:

This doesn’t automatically switch to that branch. To switch Git branches, enter the following command:

Note: Instead of type the name for the new branch.

Create New Git Branch From Current Branch

The easiest and most popular way of creating a Git branch is:

This creates a new branch from the current branch. It also automatically switches to the new branch.

Create New Git Branch From a Different Branch

To create a new branch from a different branch, run the following command:

Instead of type the name for the new branch, and instead of type the name of the existing branch from which the new one shall be created.

Create a Branch from a Commit

A commit is a command that saves the changes made in the code. A project may have multiple commits as it’s revised and improved.

Find the hash key for a specific commit:

The log contains the hash key.

Create a branch from an older commit:

Note: 6009fc in the example above represents the hash. Replace this with the actual hash from your git log command.

No need to enter the whole hash key, just the first few characters. View the git log again, and you’ll see the new branch listed.

This method is especially helpful if you need to go back to a previous version of the software to fix a bug without removing any existing features.

Use git checkout to switch to the newly created branch.

Create a Branch from a Tag

A tag is a final, unchangeable version of a commit. Where a commit can be edited, tagged versions are usually permanent.

To create a branch from this tag, use the command:

To switch to this branch:

For more details, check our in-depth Git checkout tag guide.

Create a Branch Using Detached HEAD State

Detached HEAD state happens when you check out a commit that’s not formally part of a branch.

To test, use git log to get the hash of a commit, then enter:

Replace 6009fc with the actual hash value from the system. The system prints the following output:

Just like the warning outlines, you can make changes based on the commit. Changes are lost if you don’t save them.

To save any changes, stage it and then enter the following:

To add the changes into the master, use the following:

Create a Branch from a Remote Branch

To create a new branch locally based on an existing remote branch, use the —track option:

Alternatively, use the git checkout command to keep the original remote branch name:

The git checkout command automatically creates the remote branch locally with the original name.

Create a Branch in a Remote Repository

Use the git push command to create a new branch in a remote repository based on a local branch:

How to Delete a Git Branch

To delete a git branch use the command:

The output confirms that the branch has been deleted.

You now know how to create branches in Git. Branches can be used to test-optional features before integrating them. Use small, short-term branches, so that the branch doesn’t stray too far from the central project.

How to create new branch git

Check your version of git by running

SYNOPSIS

DESCRIPTION

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

Note that this will create the new branch, but it will not switch the working tree to it; use «git switch » to switch to the new branch.

OPTIONS

Move/rename a branch, together with its config and reflog.

Copy a branch, together with its config and reflog.

Color branches to highlight current, local, and remote-tracking branches. The value must be always (the default), never, or auto.

Sorting and filtering branches are case insensitive.

This option is only applicable in non-verbose mode.

List branches. With optional

Print the name of the current branch. In detached HEAD state, nothing is printed.

When in list mode, show sha1 and commit subject line for each head, along with relationship to upstream branch (if any). If given twice, print the path of the linked worktree (if any) and the name of the upstream branch, as well (see also git remote show ). Note that the current worktree’s HEAD will not have its path printed (it will always be your current directory).

Be more quiet when creating or deleting a branch, suppressing non-error messages.

In the verbose listing that show the commit object name, show the shortest prefix that is at least hexdigits long that uniquely refers the object. The default value is 7 and can be overridden by the core.abbrev config option.

Display the full sha1s in the output listing rather than abbreviating them.

Do not set up «upstream» configuration, even if the branch.autoSetupMerge configuration variable is set.

THIS OPTION IS EXPERIMENTAL! Causes the current command to recurse into submodules if submodule.propagateBranches is enabled. See submodule.propagateBranches in git-config[1]. Currently, only branch creation is supported.

Set up
‘s tracking information so is considered
‘s upstream branch. If no
is specified, then it defaults to the current branch.

Remove the upstream information for
. If no branch is specified it defaults to the current branch.

The name of the branch to create or delete. The new branch name must pass all checks defined by git-check-ref-format[1]. Some of these checks may restrict the characters allowed in a branch name.

The new branch head will point to this commit. It may be given as a branch name, a commit-id, or a tag. If this option is omitted, the current HEAD will be used instead.

The name of an existing branch to rename.

The new name for an existing branch. The same restrictions as for
apply.

Only list branches of the given object.

A string that interpolates %(fieldname) from a branch ref being shown and the object it points at. The format is the same as that of git-for-each-ref[1].

CONFIGURATION

EXAMPLES

Delete the remote-tracking branches «todo», «html» and «man». The next fetch or pull will create them again unless you configure them not to. See git-fetch[1].

Delete the «test» branch even if the «master» branch (or whichever branch is currently checked out) does not have all commits from the test branch.

for-each-ref can take a wide range of options. See git-for-each-ref[1]

Patterns will normally need quoting.

NOTES

—merged is used to find all branches which can be safely deleted, since those branches are fully contained by HEAD.

—no-merged is used to find branches which are candidates for merging into HEAD, since those branches are not fully contained by HEAD.