Start a New Branch on your Remote Git Repository

Git is a distributed version control system so it allows you to create branches locally and commit against them. It also supports a more centralized repository model. When using a centralized repository you can push changes to it so that others can pull them more easily. I have a tendency to work on multiple computers. Because of this, I like to use a centralized repository to track the branches as I work on them. That way no matter what machine I’m on, I can still get at my branches.

The Workflow

My workflow is generally something like this:

  1. Create a remote branch
  2. Create a local branch that tracks it
  3. Work, Test, Commit (repeat) – this is all local
  4. Push (pushes commits to the remote repository)

Git commands can be a bit esoteric at times and I can’t always seem to remember how to create a remote git branch and then start working on new code. There also seems to be multiple ways of doing it. I’m documenting the way that seem to work for me so that I can remember it. Maybe it will help someone else too.

Creating a Remote Branch

  1. Create the remote branch
    git push origin origin:refs/heads/new_feature_name

  2. Make sure everything is up-to-date
    git fetch origin

  3. Then you can see that the branch is created.
    git branch -r

This should show ‘origin/new_feature_name’

  1. Start tracking the new branch
    git checkout --track -b new_feature_name origin/new_feature_name

This means that when you do pulls that it will get the latest from that branch as well.

  1. Make sure everything is up-to-date
    git pull

Cleaning up Mistakes

If you make a mistake you can always delete the remote branch
git push origin :heads/new_feature_name
(Ok Git’ers – that has to be the least intuitive command ever.)

Use the Branch from Another Location

When you get to another computer or clone the git repository to a new computer, then you just need to start tracking the new branch again.
git branch -r to show all the remote branches
git checkout --track -b new_branch origin/new_feature_name to start tracking the new branch

Automate it A Bit

That’s a pretty easy thing to automate with a small shell script luckily

!/bin/sh

git-create-branch

if [ $# -ne 1 ]; then
echo 1>&2 Usage: $0 branch_name
exit 127
fi

set branch_name = $1
git push origin origin:refs/heads/${branch_name}
git fetch origin
git checkout --track -b ${branch_name} origin/${branch_name}
git pull

For further help, you might want to check out:

69 Replies to “Start a New Branch on your Remote Git Repository”

  1. i think it is easier to first create the branch locally and then push it to the remote repo:

    git checkout -b new_feature_name
    git push origin new_feature_name

  2. Pietro,

    does this really setup tracking correctly? I had problems with that way when I modified that branch on a second computer. After I returned to the first computer where I initially setup the branch I tried to push some commited work and it told me, that the remote branch is somehow not compatible. But trying to merge the new commits into my local repo told me that there is no such remote head to sync with. Very strange. I had to rename my branch, merge the other branch into it and rebase it to commit it.

    Not sure if I did everything right because I am still pretty new to git and originally came from subversion. Git is so much nicer in many ways but the workflow is completly different if you want to use it as its full potential. So I may sometimes still to thing “intuitively wrong”.

  3. (take from http://cheat.errtheblog.com/s/git):

    git config branch.autosetupmerge true
    Tells git-branch and git-checkout to setup new branches so that git-pull(1)
    will appropriately merge from that remote branch. Recommended. Without this,
    you will have to add –track to your branch command or manually merge remote
    tracking branches with “fetch” and then “merge”.

  4. If someone happens to have a problem with pushing updates, at this command:

    git checkout –track -b new_branch origin/new_feature_name

    Instead of “new_branch” use the same name of the “new_feature_name”. If you don’t git won’t be able to figure out where to push your changes.

  5. @kai & @pietro (3 & 4): (I know I’m late, but… just saw this)

    No, this doesn’t automatically add tracking (even with Nikos’ hint). Just tried it. What you *can* do, is to edit the .git/config file and add the following (after doing the push):

    [branch “new_feature”]
    remote = origin
    merge = refs/heads/new_feature

    You can also do the same using git config:

    git config branch.new_feature.remote origin
    git config branch.new_feature.merge refs/heads/new_feature

    I tend to do the edit, though.

  6. I’ve just added a simple alias to my ~/.gitconfig file that lets me “publish” an existing branch like:

    git publish branchname

    So I can create my branch and publish it later. The alias is:

    [alias]
    publish = !sh -c ‘git push origin \”$0\” && git config \”branch.$0.remote\” origin && \
    git config \”branch.$0.merge\” \”refs/heads/$0\”‘

    I’d like to modify it so it will publish the current branch, but for now this will work, I believe.

  7. In the command “git push origin origin:refs/heads/new_feature_name” to create the remote branch, is the second “origin” correct? This is the <src> in the <src&gt:<dst&gt refspec, so I’d expect it to be a branch name such as “master” or a revision name such as “HEAD”. This would then be the point at which the new branch came off its parent, which is what would make sense to me.

    I stared at http://www.kernel.org/pub/software/scm/git/docs/git-push.html for a long time to understand what you’re doing here.

    Other than that, it’s a great post and answered the question of how to create a branch in a remote respoitory and then use it, tracked, locally.

  8. Bash Friendly Script:

    #!/bin/sh
    # git-create-branch

    if [ $# -ne 1 ]; then
    echo 1>&2 Usage: $0 branch_name
    exit 127
    fi

    branch_name=$1
    git push origin master:refs/heads/$branch_name
    echo "git push origin master:refs/heads/$branch_name"
    git fetch origin
    git checkout --track -b $branch_name origin/$branch_name
    git pull

  9. Windows CMD friendly script


    @set argC=0
    @for %%x in (%*) do Set /A argC+=1
    IF %argC% == 1 (
    set branch_name=%1
    git push origin origin:refs/heads/%branch_name%
    git fetch origin
    git checkout --track -b %branch_name% origin/%branch_name%
    git pull
    ) ELSE (
    echo Usage: %0 branch_name
    )

  10. Just want to say that your post is listed in a private wiki for the company I work for and I reference it every now and then – thanks for the lasting contribution :)

  11. John!

    You should know a patch id from your removed branches. When you remove a branch, your patches are not removed immediately, you can remove them by using the garbage collector of git (git-gc). So you need to find one commit on the removed branch, follow the commit tree, and create a branch that refers to the last commit…

  12. I use a remote work branch to create snapshots before I change workstation (from notebook to desktop). Therefore local branches are not enough, because I’d like to sync to that “snapshot” branch from both machine…

    Thanks the article!

  13. Another useful way of creating a remote branch is by naming the topic branch you want to push to origin

    git push origin master:new_remote_branch

    or

    git push origin topic_branch:new_remote_branch

  14. Like Michael Johnson I, too, prefer to create the local branch first (who knows if I really want to push it later?).

    Instead of using a .gitconfig [alias] (and having to provide the branchname manually) I simply wrote a shell script that parses the current branchname, and named it git-branch.

    #!/bin/sh
    function parse_git_branch {
      ref=$(git-symbolic-ref HEAD 2> /dev/null) || return
      echo ${ref#refs/heads/}
    }
    BRANCHNAME=`parse_git_branch`
    git push  
    git config branch.$BRANCHNAME.remote origin
    git config branch.$BRANCHNAME.merge refs/heads/$BRANCHNAME
    
    

    More details can be found on my blog post

  15. I just added these to my gitconfig. They allow me to publish (or unpublish) the current branch.

    [alias]
      publish = !sh -c 'CURRENT=$(git symbolic-ref HEAD | sed -e s@.*/@@) \
          && git push --set-upstream origin $CURRENT:$CURRENT'
      unpublish = !sh -c 'CURRENT=$(git symbolic-ref HEAD | sed -e s@.*/@@) \ 
          && git push origin :$CURRENT'

    Requires git version 1.7.

    This is a play off of Michael Johnson’s aliases above and a note from this post.

  16. Thanks a LOT! I was searching hopelessly to find out how to do precisely this, and your short tutorial here just saved me tonnes of time! Definitely bookmarking your site. :D

  17. You can create a new local branch that’s tracking remote trunk with just one command:
    git checkout -b some-branch-name -t origin/trunk

    That’s at least how I mostly do things. For each new feature/bug-fix or whatever makes sense to be a smallest group of file changes – I create a local branch. I commit to it – once I’m satisfied (unit/functional test passed and all) I push changes to remote trunk.

    I rarely need to push my local branch to “main” git repository as a branch there – perhaps when there is 2+ of us working on the same thing…

  18. As a shortcut to step #4, if you want the name of the local branch to be the same as the remote, you can issue the following:

    git checkout -t remote/branch

    This is my default for checking out remote branches as I can’t remember ever having a reason to rename the branch locally. As a side effect, it reduces human error since you only enter the branch name once. :-)

  19. This was great except it didn’t work for me at all. In response to the initial push, I was getting the “error: src refspec origin does not match any”, which isn’t even grammatical English, let alone helpful. Turns out, somehow I had branch.autosetupmerge set to false months ago when I clone my repo. Fixed it with

    git branch --set-upstream master origin/master

  20. And, grrrr, it’s

    git push origin master:refs/heads/new_feature_name

    The label “origin” only appears once!

Leave a Reply

Your email address will not be published. Required fields are marked *