Game Development with Bitbucket

By on November 14, 2016

When starting to develop an idea into a game, there are a lot of things to consider: picking the right game engine, setting up a dev environment, getting early feedback, the list goes on. With all of this going on the last thing you want is to have to fiddle around with your tooling, or even worse, forget to backup your code entirely.

Indie game development often means working long hours on limited funds, and doing multiple jobs in parallel to pursue your dreams. The need for speed is essential. This is where choosing the correct version control system comes in – it should be somewhat “invisible”. Perforce has become synonymous with gaming development, because there used to be a perception that Git did not play nice with large files. With the addition of Git Large File Storage (LFS), Git is poised to be the preferred version control of choice for gaming development, just as it is for almost every other industry. But why?

Perforce vs Git

With Perforce, you have to be connected to the central server to see a history of changes, creating a bottleneck. Perforce also maintains a branching record on a per-file basis which creates a lot of metadata, making branching very expensive and restrictive. With Git, you can work from home or the beach without having to be connected to a central server and carry the full history of your code repository with you. This means Git is lightning fast compared to Perforce and is conducive to modern workflows. Making a branch for a new feature with Git’s branching model is simple, inexpensive, and built for modern software development best practices like CI/CD to ensure your code is always production ready.

Git beats out Perforce in cost and speed but there is one other major player when it comes to choosing a version control system for gaming: versioning large files- which has been solved.

Track all your files in one place with Git LFS

Before Git LFS, game developers who wanted to use Git ran into problems because Git repositories usually have size limits to ensure operations run performant as a repo grows. As they would add and change large binaries in Git, their repos would quickly bloat in size and become very slow. Hacks were created to work around these limitations like tracking large assets outside of Git in local storage systems or cloud storage providers. This required the team to manually sync and communicate all changes to keep code working– not awesome.

Now with Git LFS, game developers can version large files alongside their source code. Git LFS keeps your large files in parallel storage, and only lightweight references are stored making your repos smaller and faster. The next time your team clones a repo with files stored in Git LFS, only the references and relevant large files that are part of your checked out revision will get downloaded, not the entire change history. And with our launch of LFS general availability this October, Bitbucket Cloud has upped the game when it comes to Git LFS by adding the following features:

To start using Git LFS, follow these easy steps or to learn everything you could possibly want to know about LFS, read this in depth guide.

Why Bitbucket for game development?

game development

Depending on the kind of game you’re making, costs can quickly add up. You’ve got decisions to make about tools, technology, even music. We want to make it easy for teams to get started with Bitbucket and provide the path of least resistance so you can start working on your game and then grow with us. That’s why we’ve made Bitbucket Cloud free for up to 5 users with unlimited public and private repositories.

We also know that the faster you can get your game out in the world, the faster your user base grows and money starts coming in. In October we announced the general availability of Bitbucket Pipelines, our continuous delivery service built right within Bitbucket Cloud that gives you end-to-end visibility from coding to deployment so you can automate many of the tasks associated with building, testing, and deploying services. The best part? It’s included in our 5 user free tier.

Bitbucket integrates nicely with the tools you need to create your game. We offer best in class JIRA integration for full development traceability across your issues. If you are looking to use Unity for your game engine, you can get set up with Bitbucket and Unity in 7 easy steps.

Free marketing for your game

Choosing the right version control system and Git solution that can scale with your game is essential for your games’ success. Check out our Bitbucket for gaming resource for more ammo on making the switch from Perforce to Git, to get everything you could possibly want to know about Git LFS, or get some free marketing and get featured on our page by submitting any games you’ve already #BuiltwithBitbucket to us on Twitter with the hashtag (there could be an extra surprise in store for you if you do, (wink)).

Get started for free

Have more specific questions about this post? Reach out to us on Twitter to get the information you need

Introducing pull request iterative reviews in Bitbucket Server 4.11

By on November 8, 2016

There is no denying that peer to peer feedback decreases the amount of bugs, shares knowledge across the team, and creates a sense of shared ownership of every feature. This is why we’ve been working hard to make Bitbucket Server’s pull requests (a.k.a lightweight code reviews) a quick and painless part of your day. Today we’re introducing iterative reviews in Bitbucket Server 4.11, allowing your team to discuss changes to code in the context of a single pull request.

See what’s changed since your last review

Let’s be honest, everyone knows pull requests are valuable but sometimes they can become a bit of a drag. We’ve all been there – tagged as a reviewer on a monster pull request that updates every time you refill your coffee. So much time is wasted looking for the newest changes. You ask yourself questions like, “Did I already review this piece?”, or “Have the comments left by so and so been addressed?” Thanks to iterative review you now have the answers.

Iterative Review Example

When a pull request is updated Bitbucket Server will show you exactly what has changed since you last reviewed it. No more hunting through files for edits or re-reviewing code you’ve already seen. Upon returning to an updated review Bitbucket will automatically display the ‘number of commits since your last review’ in the request scope. This will allow you to comment only on those newly added commits.

Pro tip: If you’re not ready to approve a pull request, click the “Needs Work” status indicator. When you come back, Bitbucket Server will show you only the changes made since then. Still not happy? Add comments on the new unreviewed changes diff and the author will be notified of your feedback just like before.

Merge your request with confidence

On the flipside we’ve also all been the author of those monster pull requests. You know, the ones containing code with the potential to bring down your entire product. You’ve done your best to ensure there are minimal bugs and green builds, but without your team giving the thumbs up merging can be stressful.

This is why pull requests are great… that is until you start to incorporate changes and your team must re-review. Questions like, “Did everyone see your fix for that big issue?”, or “Is my pull request ready to merge?” run through your head. Relieve some stress and have peace of mind knowing the team has reviewed all of your changes thanks to iterative review.

Iterative reviews are a pull request game changer. As a reviewer, regain time back to code by avoiding playing the “Have I Already Reviewed This?” game. And as an author, merge your changes with confidence knowing every modification has been reviewed. Upgrade your team’s pull request workflow and download Bitbucket Server 4.11 today!

Try Bitbucket Server 4.11

But wait… there’s more! Besides iterative review, Bitbucket Server 4.11 is chock-full of other goodies including:

Read more in our release notes.

Better support for multiple SSH keys

By on October 26, 2016

Alongside your professional “day job” Bitbucket account, you may just have a personal Bitbucket account where you’re building silent iPhone 7 games, hacking on the first killer VR app, or training TensorFlow to write one for you. To access both accounts from one computer, you’ve either had to use HTTPS for repositories belonging to your second account, or mangle your SSH config in order to provide the right key for the right clone. All whilst wondering why your repository’s SSH URL is prefixed with the seemingly redundant or

Moonlighters, I have good news for you! You can now prefix your repository URL with your Bitbucket username to easily use different SSH keys with different accounts. Simply clone from and Bitbucket will use the correct key proffered by your SSH agent.

To update a local repository to specify your username in the clone URL:

# determine your Git clone URL
$ git remote -v
origin (fetch)
origin (push)

# replace git@ with your-username@
$ git remote set-url origin

If you haven’t already, you can easily generate a second SSH key for your alternate account:

# generate and add a new SSH key
$ ssh-keygen -f ~/.ssh/your-username
$ ssh-add ~/.ssh/your-username

(You’ll also need to add the contents of ~/.ssh/ as a new Bitbucket SSH key.)

ssh-add adds the key to your local SSH agent, which Git and Mercurial will use automatically when interacting with a remote repository over SSH.
During key exchange, your SSH agent offers all the keys that may be appropriate for a particular host. Using git@ as a prefix means Bitbucket doesn’t know which user you’re attempting to authenticate as – so it accepts the first key that it recognizes. If this key belongs to your professional account, and you’re attempting to access a personal repository (or vice versa), you’re outta luck. Using your-username@ as a prefix allows Bitbucket to filter down which SSH keys should be accepted for a particular request.

If you have but a single Bitbucket account – no need to do anything. For backwards compatibility (and supporting things like deployment keys) git@ and hg@ will continue to work for the foreseeable future.

Happy moonlighting!

Bitbucket Pipelines is now generally available

By on October 25, 2016

Sign up for Bitbucket Pipelines

The fastest growing companies in the world today aren’t product companies, they’re service companies. Where we used to buy cars, we now hail a ride from a ridesharing app, and where we used to buy physical music, we now stream online. Agile and DevOps methodologies are increasingly popular today as software development teams strive to improve their velocity to keep up with this demand, and these teams are breaking down silos in order for their various engineering, support, and IT orgs to operate better together.

Continuous Delivery in particular is allowing teams to automate many of the tasks associated with building, testing, and deploying their services. This automation allows teams to meet customer demand for frequent releases while improving the quality of their services, and we’re proud to announce that Bitbucket Pipelines is now generally available to help all teams build, test, and deploy using continuous delivery, all within Bitbucket Cloud.

Configuration as code

If you missed the launch of the beta earlier this year, Bitbucket Pipelines is built right within Bitbucket Cloud, giving you end-to-end visibility from coding to deployment. With Bitbucket Pipelines there’s no CI server to setup, user management to configure, or repositories to synchronize. And where your build configuration files might be hosted separately from your code, Pipelines keeps everything together in Bitbucket. Better still, your configuration files are managed and versioned, allowing for your team to view, edit, and review to ensure quality like the rest of your code.


Bitbucket native

Gone are the days of having to switch between different systems to work out the status of your builds or why they’ve failed – Pipelines brings the status of builds into your repository. You can see the status of your branches and commits everywhere in Bitbucket, giving you crucial visibility on the status of your builds when you branch and before you merge.



It’s easy to get started too – all you need to do is commit a single configuration file into your repository and you’re good to go. Your configuration can be as simple or as complex as you need and with Pipelines utilizing Docker containers, you have the flexibility to choose from a wide variety of languages.

Infinite scale

Estimating capacity for your builds is a fine balancing act. Underestimate and you risk builds queuing up, resulting in idle time for your developers; overestimate and you’re wasting money on extra capacity. Bitbucket Pipelines scales instantly, helping you avoid queues by scaling up on demand when you need it. And with Pipelines you don’t have to pay for idle time, saving you money by charging for just what you use.


Whether you want to deploy, test, monitor, analyze code, or store artifacts, complete any workflow with the tool of your choice by bringing your favorite services to Bitbucket Pipelines. We’re working with many industry leaders to ensure there’s continued support for the tools and technologies your team needs to build and ship software. Current integrations include AWS, Google, Microsoft, npm, Puppet, Rollbar, Sauce Labs, Sentry, SourceClear, TestFairy, and many more. Check out our integrations page for the full list of integrations.

Pay for what you use

Best of all, Bitbucket Pipelines utilizes a unique pay-as-you-go model for pricing. Never pay for containers and getting charged for the days, weeks, or even months when a given repository is idle; get started with continuous delivery for as little as 1 cent per minute. Based off of average use during the beta, that’s less than a cup of coffee a month for each developer!

With Bitbucket Pipelines we want to help all teams deliver better software faster, and we’re excited about the future of Continuous Delivery within Bitbucket. Try Bitbucket Pipelines and accelerate your team’s releases today.


Sign up for Bitbucket

Scaling in Bitbucket Cloud: new features and reliability numbers

By on October 12, 2016

More and more applications are moving to the cloud. It is growing so rapidly that revenue from public cloud platforms, business services, and SAAS will grow 22%, reaching $236 billion by 2020 according to Forrester*. But why? The flexibility to scale cloud capacity, decreased hardware costs, automatic software updates and the ability to access critical information anytime, from anywhere makes a powerful business case for cloud.

The second wave of adoption will be moving the full software development workflow to the cloud for the same reason applications moved: accelerating business velocity. Having your apps and your CD pipeline in the cloud in one integrated platform reduces the need to switch between tools, cuts down on complexity, and gives companies a big competitive advantage by enabling rapid agile delivery. We are committed to meet teams where ever they are on their cloud journey, which is why we built Pipelines, LFS and Mirroring in Bitbucket.

New Features: Pipelines, Git LFS, Smart Mirroring and more

To help both our on-premise and SaaS customers scale in the cloud, today we’re announcing new features focused security, collaboration, and performance:

Bitbucket media file viewer

Premium Features- now in a free trial: Some teams require granular admin controls, security, and auditing capabilities. For them, we’re introducing a new Premium plan that is available for all users as a free trial for a limited time including the following features:

Security and reliability improvements in Bitbucket Cloud

Source code in the cloud used to be unthinkable due to security and reliability concerns, but the momentum has shifted. Today, if you build for the cloud, you should build in the cloud. Bitbucket has seen a massive trend in this direction with a 142% compounded annual growth rate over the last 3 years among professional software teams moving their source code to the cloud.

Over the last we’ve made major investments in upgrading our hardware, improving monitoring and alerting, reconfiguring internal and external network infrastructure, and revised database queries and configurations. We’re proud to see these investments paying off with 99.98% uptime in June, 100% in July, 99.98% in August, and 99.98% in September.

We’ve also launched a slew of security updates over the last year to ensure your company’s most precious asset is safe. 2 factor authentication (2FA), Universal Second Factor(U2F), improved SSH to accept ECDSA and ed25519 user keys, and added HTTPS to our hosted sites are just the beginning.

Pay only for what you need with per user pricing

Most companies use SaaS so they can scale easily in the cloud and pay only for what they use. In our current model, unless you have exactly 10, 25, 50 or 100 users, you can end up paying for seats you don’t use. In the new pricing model (price-per-user) you only pay for the users who are actually part of your team. The Standard plan includes the Bitbucket you love at $2/user/month. The Premium plan at $5/user/month is for teams that require granular admin controls, security and auditing. Bitbucket Cloud will still be free for small teams of up to 5 users. More details can be found here.

Get started

At Bitbucket, we invest heavily in both our cloud and on-prem platforms so we can meet teams whereever they are, whether hosting their source code using Bitbucket Server behind the firewall or in the public cloud, or making the full move of their source code to Bitbucket Cloud.

We hope you enjoy Bitbucket’s new features. Let’s start shipping more awesome things together.

Sign up for Bitbucket

*The Public Cloud Services Market Will Grow Rapidly To $236 Billion In 2020, a September 2016 Forrester report

Have more specific questions about this post? Reach out to us on Twitter to get the information you need

Safer branching

By on October 6, 2016

A comic in which a developer commits directly to master, temporarily breaking the build. Another developer has the misfortune to fetch master whilst broken, and creates a feature branch from the broken commit. This causes confusion later on when the tests fail in an area of the code that they had not modified on the branch. Had the developer created the branch via the Bitbucket UI, they would have been warned that the branch they were creating a commit from was currently failing the tests.

Try Bitbucket Pipelines

Bitbucket blog update

By on October 4, 2016

Dear Readers,

Bitbucket team here with a quick update on how we are managing the Bitbucket blog. Starting Friday, October 7th, we will be turning off commenting on the blog.

It’s not that we don’t want to talk to you – we do! We noticed that sometimes blog comments go unanswered for weeks because a comment get posted on a really old blog post. We want to make sure that you are able to get answers to the comments and questions you have on the right channels and by the right people. Here are the places for you to chat with us on anything from product questions, support requests, reporting bugs, and requesting features:

Customer support

For any technical issues, please visit our support center.

Feature requests and bug reporting

If you would like to request a new feature or file a bug, please visit our public issue tracker. Here you can see what other Bitbucket customers have requested, follow requests and issues, and even create a new one yourself.

Atlassian Answers

Have any open questions about how to use Bitbucket, Git, or integrate with another product like Microsoft Azure? Visit Atlassian Answers where you will find questions submitted and answered by the user community, ecosystem developers, and Bitbucket staff.

Finally, get social with us! Join us in our enthusiasm for Bitbucket, spooning or software development best practices on Twitter.

Thank you for reading our blog, and for all the feedback you’ve given us over the years. Talk to you soon!

Hello World! A new grad’s guide to coding as a team

By on October 3, 2016

This post is featured in our ebook, “Hello World! A new grad’s guide to coding as a team”– a collection of essays designed to help new programmers succeed in a team setting.
Grab it for yourself, your team, or the new computer science graduate in your life. Even seasoned coders might learn a thing or two. 

Read it online

Click here to download for your Kindle

It’s not quite what I had in mind when growing up, but right now my role title tells me I am a team lead. In the course of my time in this role, I’ve learned that being a team lead is something my fellow developers are interested in doing someday, so I want to share about my experience. This is what I’ve learned in discovering what it means to be a team lead.

People management

I’ll start with the obvious. A team lead is supposed to manage the people on their team. For me, these people are usually developers. Of course, everyone is different and situations arise in a variety of ways, some that I can prepare for or help with and some that I cannot. Over the years I have learned a lot about how to manage people and how to deal with common problems, but the one common denominator is that I don’t always know what to do in 100% of the situations. This is certainly a never-ending learning exercise. It’s an interesting aspect of the role that managing no one person is ever the same. Getting a team of different people to work together, keeping them challenged and motivated, ensuring they are performing, improving, and growing, is all quite interesting and challenging. Seeing teams form to reach their potential and watching individuals progress in their career is what I find most rewarding about my job.

Project management

Generally as team lead, I’m also the one managing the projects and making sure they get delivered on time (← why is that bit so hard?!). Delivering the right features, a good user experience, and high quality software on time is damn hard. There are so many equally important projects going on that should have been delivered yesterday. There is never enough time, so you have to constantly prioritise, which often means just saying no.

This picture best describes the situation I often find myself in. Just picture me in the middle of this four way tug-of-war. In front of me is a product manager, who tells me all the lovely, but never-ending list of things we must do. To the left I have a designer showing me designs for the best user experience we could possibly build. To my right is the quality engineer who always seems to be scolding me about our test coverage and quality of code. And of course, behind me are the developers who tell me things are going to take longer than estimated, complain about the amount of code debt we have, and explain how we need to build things better.

Now, I may be slightly exaggerating here, but the truth is, everyone is rightfully doing their job and pulling me in the direction they are supposed to. I just happen to be the person in the middle. The trick is finding the right balance and not falling over, which is quite hard to do. I sometimes worry if I’ll even make anyone happy in this constant game of give and take.

“As a development lead, it’s my job to be pulled in different directions without losing my balance.”


When I’m not embroiled in a game of tug-of-war, some other things I do associated with project management include sprint planning, roadmap planning, people planning, risk mitigation planning, deployment planning and planning for planning (yes, it’s a thing).

Having a bird’s eye view

This overlaps with project management a bit, but I tend to think about it separately since it’s on my mind a lot. As someone not on the ground coding everyday, I am able to take a step back and look at what my team is building more holistically. There is always a constant stream of questions to be asked and decisions to be made, ranging from technical concepts like implementation to other concepts like if the user experience makes sense. A final aspect of this perspective is considering the project dependencies, or how my team is depending on a different team, and how other teams are depending on us.

Wearing different hats

You don’t necessarily have to be a team lead to wear different hats, but it’s absolutely required of me when the Product Manager, Designer, or QA Engineer isn’t available. I don’t claim to do any of these roles particularly well, but I have to learn to think like these people. It is quite common for questions to arise once development has already started, and it’s usually quicker for me to make these small decisions on the spot, which is where putting myself in someone else’s shoes comes in handy.

Conversations and coding

As a team lead, my calendar is full of meetings, which I prefer to call conversations, because that is what they are. Besides my 1-on-1s with the people I manage, my mentors, and my managers, my calendar is usually full with conversations about the software we’re going to build. There is planning to be done, design reviews to go over, technical discussions to be had, and more.

To be honest, I hardly code any more. I code 1-2 hours a week if I’m lucky organised. Most of the team leads I know don’t code much either. Letting go of coding is probably the first thing most devs-who-become-team-leads struggle with. I learned that as team lead it is not my priority to be writing code. In fact, when I do have to code, I’m not as efficient as another developer because I haven’t been following the issue entirely through the workflow. In an attempt to keep up, I try to do random code reviews, set up a dev environment, do a bug fix, or simply pair with whoever is available.

Well, this is my experience being a team lead. Even after a few years, I still find my job stressful, challenging and hard, but for the most part, it is highly rewarding and enjoyable. If one day you find yourself in my position, I hope hearing about my experience will have served you well in the challenges and opportunities you will face.


This post is featured in our ebook, “Hello World! A new grad’s guide to coding as a team”– a collection of essays designed to help new programmers succeed in a team setting.
Grab it for yourself, your team, or the new computer science graduate in your life. Even seasoned coders might learn a thing or two. 

Read it online

Click here to download for your Kindle

Try new merge strategies in Bitbucket Server 4.9 and more

By on September 8, 2016

Bitbucket Server 4.9 and Bitbucket Data Center 4.9 bring strategy to the forefront of how teams work with their source code. Learn about three new features and how your team and business can set up new strategies to help teams work the way they want to work.

Make disaster recovery part of your business plan

For mission-critical tools like Bitbucket Data Center, disaster recovery (DR) is more than just a feature, it’s a strategy. Why? Because if the main instance goes down (aka a disaster) teams need a tool that allows them to continue working with their data. This is where DR comes into play. It provides Bitbucket Data Center customers the ability to replicate the state of their primary instances to a “cold standby” instance at an offsite location. So if your primary instance goes down, Bitbucket Data Center can cut over to the standby.

A “cold standby” is one example of a disaster recovery plan (DRP) in which the standby Bitbucket instances are cold and the file server, database and Elasticsearch instances are warm, in order for the replication to occur.

Since your standby site contains cloned Bitbucket indexes and a copy of your production database – think critical plugins – your team can quickly get back up and running. At Atlassian we use this model because we have instances in different geographies, so if a primary instance goes down in Sydney we can cut over to the disaster recovery standby instance in San Francisco with minimal downtime.

The addition of DR to Bitbucket Data Center gives teams and businesses the toolset to set up a proactive strategy for when things go wrong, so the prospect of developers sitting around with nothing to do becomes a non-issue. Instead admins and IT can focus on the reason for the downtime – no small feat – while source code work moves forward.

For more details on DR and a reference DR deployment, see our updated documentation.

Choose how your pull requests get merged using merge strategies

While DR and zero downtime backup help teams and business with downtime strategies, Bitbucket Server 4.9 introduces a new feature specific to workflow and code review strategies called merge strategies. Its complement merge checks have been in Bitbucket Server for a while, but merge strategies give users and teams control over how pull requests get merged rather than controlling if a pull request can be merged.

Different teams desire different things when it comes to how they track the history of their repositories. Bitbucket has traditionally been opinionated about applying a merge commit when closing a pull request, but there are good reasons not to always do this. For example, some teams have a different view on what constitutes a clean history and want to use fast forward only or squash merge strategies.



Now a repo admin can define the default merge strategy and specify what alternative strategies are allowed for selection at merge time. That means the person merging each pull request can have full control over strategy used. An example where this can be handy is when you’re using a Gitflow branching model. You might set the default to squash on merge, but allow “no-ff” to be used so that proper merge commit occur between release branches. This detail in a team’s workflow, much like the default reviewers feature, gives teams unique features to work the way they want.

Import repositories from other hosting services

Lastly, starting a new project that requires a migration of repositories in bulk from one product to another or of repos from one server to another server should be frictionless. So instead of writing scripts or importing repos one at a time, the new import repository feature for both Bitbucket Server and Bitbucket Data Center allows for bulk imports to give teams the ability to try out real or demo data.

This is especially important when you’re just getting started with Git and Bitbucket Server, or wanting to pull in code from an existing project from Bitbucket Cloud,, GitHub Enterprise, or individually from any HTTP-based Git host. It is quick, easy, and gives teams the flexibility to work with data where they want to.

import repositories into bitbucket

All of the new features released in Bitbucket Server 4.9 and Bitbucket Data Center 4.9 help teams collaborate with strategies in place. The addition of DR to Bitbucket Data Center is important to any team’s daily activities. Your tools are business and/or mission-critical, so work can’t be stopped during a disaster or downtime. And in the world of pull requests, different teams and different repositories may want to use different merge strategies.

The addition of merge strategies to your pull request workflow gives teams the flexibility needed to set up a merge strategy. It is with these types of features that Bitbucket Server and Bitbucket Data Center can help your team and business think about strategy at the team level and up to help teams work better together.

Try Bitbucket Server 4.9

Check out the release notes for more information on these new features and the other improvements we’ve made in 4.9.

In case you missed it

Since Bitbucket 4.5 we’ve continued to improve our pull request experience, add new features, and more. Check out to see what has been added:

Bitbucket Cloud: 5 million developers and 900,000 teams

By on September 7, 2016

February 2017 update: Now 6 million developers and 1 million teams.

A sincere thank you to the 5 million developers, 900,000 teams and countless amazing projects that were developed by our users with Bitbucket over the last year. Everything our users do inspires everything we do – from offering free unlimited private repositories for small teams to building the security features our larger teams need to take their ideas from the first keystroke to production. We strive to make it easy for teams to get started and then scale with Bitbucket as their team grows, and the 5-million developer milestone prompted us to take a look back and reflect on everything that’s happened in the past year.

5 million developers, 900,000 teams

To put it all in context, here’s a little bit of Bitbucket history. Bitbucket launched in 2008 with support for Mercurial repos, followed by Git support in October 2011. Since then, we’ve seen a massive adoption amongst the developer community. Through the help of our users spreading the word and building features that cater to professional teams, we have seen rapid growth of developers and teams in Bitbucket over the last 3 years.

Many of us on the Bitbucket team remember the day we reached 1 million users and how amazing that felt. So needless to say, reaching 5 million blew us away.

Bitbucket developer growth             Bitbucket team growth

We are excited that more and more teams continue to trust us with their source code and build innovative software with Bitbucket.

Some cool stuff is #BuiltwithBitbucket

And let’s not forget all the cool stuff these teams have been building. We believe your day-to-day coding has a bigger impact in the world than you give yourself credit for so we asked our users to tell us what they built over the last year. The responses came in droves: Mobile games, musical scores, apps that help you figure out how many diapers you will need for your child, online education, cancer research… the list goes on.

Atlassian’s mission is to empower teams to advance the world through software so we were both humbled and proud to see what the developer community is contributing to the world. It was incredibly cool to see the use cases we never would have thought of and see that our users are using Bitbucket to make an impact on someone’s day out there with what they are coding.


Keep telling us what you are building using #BuiltwithBitbucket. We absolutely love to hear it and show you off.

New features

Behind the scenes, the Bitbucket Cloud team releases on a weekly basis to get new features to our users and solve some common needs: code review, strong integrations, an easy to use UI, security and more. Here are a selection of the most popular features we released over the last year:

We’ve made strides over the past year, but we’re not done yet. This year’s roadmap is shaping up nicely with more updates to improve your workflow. To keep up to date with all the most recent updates or get a more in depth scoop on a specific feature you can follow our latest features page.

That’s a wrap

Thanks again to our amazing developer community – we can’t wait to see what you build with Bitbucket next. If you are new to Bitbucket, you can can sign up for free unlimited private repositories here or if you are already a Bitbucket user, check out what’s new.

Sign up for Bitbucket