Feature branches just got better

By on December 10, 2012

The Bitbucket team uses Git’s branch and merge features religiously with pull requests for code review. At any given time we may have a dozen open pull requests for code that is looking to be merged into our staging branch, which later gets promoted to our production branch and deployed to bitbucket.org.

With so much in code in flight, keeping track of which branches are open, active, or gone stale can be a hassle. This got us thinking during our recent Innovation Week, “What if there was a way to review open branches that need to be pulled?”

Introducing a new way to see branches

With the new “Feature branches” commit listing, you can now see branched commits that are ahead of your main branch. This new view allows you to:

Branching is easy with Git

Creating branches, working on them, and merging your changes is effortless. To get started, simply clone your repository and create a feature branch:

git clone git@bitbucket.org:username/reponame.git

git checkout -b my_new_branch

Make some changes and when you are done, push your changes:

git commit

git push origin my_new_branch

Your branch will now show up on the “Feature Branches” view for everyone to see. Next you’ll want to share your branch with your team by creating a pull request to conduct a code review.

Closing branches with pull requests

The simplest way to close a branch with pull requests is to use the close branch option when creating a pull request.

When selecting this option, Bitbucket will automatically close the source branch for you, tidying up your team’s repository and “Feature branches” view.


  • Posted December 10, 2012 at 4:23 pm | Permalink

    This article only talks about Git, but it seems like this is enabled for Mercurial, too, right?

    • Posted December 10, 2012 at 4:50 pm | Permalink

      Yes, the feature works with Mercurial and Git.

    • Posted December 10, 2012 at 10:54 pm | Permalink

      Yes, it’s a bit silly that the post very specifically talks about Git only, right down to the branch commands. This of course should have included Mercurial too.

      This feature is entirely agnostic with respect to Git/Mercurial.

      • Posted December 11, 2012 at 12:44 am | Permalink

        Would it require a named branch in mercurial or would anonymous branches also work (if that makes sense)?

        • Erik van Zijst
          Posted December 11, 2012 at 11:20 am | Permalink

          Anonymous branches are merely multiple heads on the same branch and are treated as such: they only represent 1 branch and so this page will not tell you the differences between the heads within a single branch.

          By the way, this has consequences for bookmarks.

          Since bookmarks are often used as an alternative to named branches, these repos typically have only a single named branch (“default”), which will also be the repo’s main branch (configurable in the admin section). Since every commit on every bookmark is also on the main branch, this page will not find any feature branches.

  • Posted December 10, 2012 at 4:36 pm | Permalink

    This is a really useful feature. Well done, guys!

    • Erik van Zijst
      Posted December 10, 2012 at 6:29 pm | Permalink

      Thanks dude!

  • skrattaren
    Posted December 10, 2012 at 9:45 pm | Permalink

    The article sounds like BB is developed using Git, is that true?

    • Posted December 10, 2012 at 10:46 pm | Permalink

      It is indeed.

      It’s worth nothing that the bitbucket codebase had always been in Mercurial, even after we added Git support to the site in 2011. However, in the interest of dogfooding, we recently converted the repository to Git (this was done during the same innovation week that brought this Feature Branches page).

      Our workflow has hardly changed though. We’ve always used branches for feature development. The only difference is that we use forks less than we did before.

      While the site’s main code base is now in Git, we still have plenty of other projects that are still in Mercurial and we’ll continue to keep a nice balance between the 2 SCMs, converting repos back and forth occasionally.

  • Posted December 11, 2012 at 12:35 am | Permalink

    Looks like you guys are working on on repo using feature branches per developer? How would this work when the repo is forked? I’m curious about your workflow. We are using forks and pull requests to review what gets into the main repo for example.

    • Posted December 11, 2012 at 3:25 am | Permalink

      You can submit a pull request from a branch within the repo. I assume they do not need to Fork any repos at all. Since feature_test on the same repo as production, can be submitted as a pull request without a fork at all.

      • Posted December 12, 2012 at 1:26 am | Permalink

        I know, but the only “risk” there is that someone will accidentally commit on the wrong branch (we have stable and default for example). Not a terrible thing of course but something I’d like to avoid.

    • Erik van Zijst
      Posted December 11, 2012 at 11:38 am | Permalink

      This page only shows branch difference within the repo and does not extend to forks.

      A few years ago we used feature forks quite a bit, but we gradually moved to using named branches within a single repo (as well as the occasional bookmark). Since we’ve been on Git however, we’ve pretty much standardized on feature branches within our 1 repo.

      We don’t strictly follow gitflow (though I think it’s generally a good model), but we do have a stable/release branch called “production” and a dev branch called “staging”.

      The former is what we deploy from and is always in a releasable state. The latter branch is where we continuously merge our pull requests into and then immediately deploy to our internal dogfooding instance.

      Features and bugfixes are always done on branches, while hotfixes can go straight into “production”.

      We don’t really use gitflow’s concept of release or bugfix branches.

      Contributions from other Atlassian teams (from devs that may not have write access on our repo) typically still use feature forks.

  • Posted December 11, 2012 at 3:26 am | Permalink

    This is going to help my team a huge amount. Thank you!

  • Mathieu de Ruiter
    Posted December 11, 2012 at 4:04 am | Permalink

    Eclipse with eGit gives the error “An
    internal Exception occurred during push: remote does not support smart HTTP
    push” after a push. Any ideas how to resolve this?

  • Derek Bowes
    Posted December 11, 2012 at 7:32 am | Permalink

    So how do you use this with Mercurial? We have not done any branching yet, but would like to.

  • Ungaminga Ungaminga
    Posted December 11, 2012 at 8:45 pm | Permalink

    Hey mr. Horse! What’s your opinion on new “Feature branches”?

  • Domenico Testa
    Posted December 14, 2012 at 2:28 am | Permalink

    I personally identify Mercurial bookmarks as the GIT branch counterpart.
    Are there any plans to support bookmarks?

    • Posted December 15, 2012 at 5:45 pm | Permalink

      We’d like to, but we haven’t really worked out yet how that should behave when you also have named branches as they are essentially different concepts that overlap one another.

      • Guest
        Posted December 19, 2012 at 6:55 am | Permalink

        99% of repositories only use one or the other.

        Simple algorithm for the 1%: Consider all bookmarked heads to be the equivalent of a Git feature branch. Then, the tip-most head of every named but unbookmarked branch is also a feature branch.

  • Guest
    Posted December 17, 2012 at 12:51 pm | Permalink

    This focus towards git is slightly annoying, especially for anyone that

  • Posted December 17, 2012 at 1:08 pm | Permalink

    The focus on git is getting slightly annoying. Bitbucket tutorial starts only with git, new feature announcements are only about git, stash is only for git.. Many people feel uneasy if mercurial is going to be the first class citizen or just a “legacy” thing.

    • Mary Anthony
      Posted December 19, 2012 at 10:01 am | Permalink

      The tutorial does cover Mercurial later on. I tried to balance coverage of all Bitbucket features rather than focusing on a single DVCS system. When we have more resources, DVCS-specific tutorials that go beyond the getting started tutorial would be fun to write and I hope helpful.

  • Anonymous
    Posted December 19, 2012 at 2:16 pm | Permalink

    This is a really cool feature! Great work guys 🙂

  • Edson Tadeu M. Manoel
    Posted June 24, 2013 at 1:56 pm | Permalink

    How does it work for a feature branch that spans across multiple repositories?

  • Anonymous
    Posted July 15, 2013 at 7:11 am | Permalink

    What is technically doen when the branch is “closed” after the pull request is merged? The branch is still there, right?

  • Harshvardhan Parihar
    Posted June 8, 2014 at 9:58 pm | Permalink

    I created one branch locally, made few changes and then pushed the code to main branch using this command “git push origin HEAD:refs/for/master”. Now In bitbucket, my commit is not in master branch. Its in separate branch whose name is not avilable. I am unable to pull the code.

    This command, “git pull origin master” says “Everything is up to date”.
    I am not able to merge the commits in master branch in bitbucket.

    Can u help me, how to merge and pull the code from the repo.

  • Ben Diamant
    Posted June 30, 2014 at 7:29 am | Permalink

    Is this deprecated? I can’t find the feature branch view anywhere

    • Ben Diamant
      Posted July 1, 2014 at 9:22 am | Permalink

      @erikvanzijst:disqus hey? 🙂

  • triynko
    Posted August 4, 2015 at 7:22 am | Permalink

    There’s a huge bug with this feature. It leaves branches in the list which cannot be deleted and give a ‘not found’ error when you try to view them: https://bitbucket.org/site/master/issues/8342/deleted-branch-still-listed-bb-9455 The workaround is to recreate a branch in bit bucket with the exact same name as the deleted branch, then delete the branch again and it will be deleted properly.

  • Andreas Warberg
    Posted November 19, 2015 at 1:57 am | Permalink

    Is it possible to change to default value for “Close [branch] after the pull request is merged” generally or per branch? We are using a teambranch model where each teambranch is long-lived and should never be removed. From time to time we accidentally delete the teambranch when merging to master because the default is to remove the branch on merge.