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.

  • http://twitter.com/danostrowski danostrowski

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

    • http://www.bitbucket.org Justen Stepka

      Yes, the feature works with Mercurial and Git.

    • http://twitter.com/erikvanzijst Erik van Zijst

      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.

      • http://twitter.com/botteaap Hugo Visser

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

        • Erik van Zijst

          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.

  • http://davidchambersdesign.com/ David Chambers

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

    • Erik van Zijst

      Thanks dude!

  • skrattaren

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

    • http://twitter.com/erikvanzijst Erik van Zijst

      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.

  • http://twitter.com/botteaap Hugo Visser

    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.

    • http://twitter.com/scottymeuk Scott Robertson

      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.

      • http://twitter.com/botteaap Hugo Visser

        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

      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.

  • http://twitter.com/scottymeuk Scott Robertson

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

  • Mathieu de Ruiter

    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

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

  • Ungaminga Ungaminga

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

  • Domenico Testa

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

    • http://twitter.com/erikvanzijst Erik van Zijst

      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

        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

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

  • http://www.facebook.com/people/Tomas-Janovsky/1446395472 Tomas Janovsky

    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

      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

    This is a really cool feature! Great work guys :)

  • Edson Tadeu M. Manoel

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

  • Anonymous

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

  • Harshvardhan Parihar

    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

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

    • Ben Diamant

      @erikvanzijst:disqus hey? :)