Bitbucket Server 4.13 brings in-browser editing and more

By on January 26, 2017

You’ve probably heard the word “simplify” floating around a lot this time of year. People are setting New Year’s resolutions, cutting the clutter, and generally, trying to do more with greater efficiency and focus. On the Bitbucket team, we’re trying to simplify too, which is why our first release of 2017 includes several new features to make your day to day a little easier.

Edit files in-browser

Fixing typos, editing README files, and making other small changes can require a fairly large amount of steps relative to the size of the change. First, you must clone the repository locally, then make your change, next push back up to Bitbucket, and finally create a pull request (if needed). Before you know it, a quick spelling change has taken 5 or 10 minutes. And for those who aren’t as prepared to make changes locally, for example a doc writer who hasn’t installed Git, this can be quite daunting.

In Bitbucket Server and Data Center 4.13, we’ve simplified the process by letting you edit files inside of Bitbucket. To help make your change, the editor pre-selects a syntax based on filetype, lets you add a commit message, and even offers the option to create a pull request on push. With no need to do anything locally, simple changes can be applied much more quickly.



Easily find related JIRA Software issues

The past few years we’ve made huge enhancements to our JIRA Software and Bitbucket integration. Features like smart commits, embedded issue information, and the development panel in JIRA improve visibility and save time. As part of our continued focus on this integration, today we’re releasing a small but powerful improvement to JIRA issue integration. Throughout the Bitbucket UI JIRA issue keys have been modified to become hyperlinks to JIRA, making it easier to locate and dig into related issues. Keys are now clickable in commit messages, pull request titles, and in branch names.


Built-in SAML 2.0 support in Bitbucket Data Center

For admins looking to simplify user management in Bitbucket Data Center, SAML 2.0 single sign-on support is now available out of the box. SAML support integrates into your existing infrastructure, providing developers a more secure and hassle free way to log in. Having only one username/password to maintain means quicker access to tools and less password reset requests for admins.

We support a large list of popular identity management providers including Okta, OneLogin, Azure, Active Directory (ADFS), Bitium and PingOne.

Upgrade to Bitbucket Server 4.13

No matter what your New Year’s resolution is, we can all use a bit more simplification in our lives. Small improvements lead to big gains. In this case, less time switching between tools, looking for links, or fighting with passwords means more time spent on whatever is important to you.

Upgrade to Bitbucket Server 4.13

But wait, that’s not all! In Bitbucket Server 4.13 we identified areas to use less memory by caching template rendering. With this improvement, 4.13 uses less memory than any other 4.X version of Bitbucket. For a list of other improvements and bug fixes check out our 4.13 release notes.

Add tags to commits in Bitbucket

By on January 20, 2017

Git tags have become essential to a Git workflow to mark specific points in your Git history (like referencing a specific version of a project by tagging a commit for your release). They reduce complexity, clean up your branch workflow, and are a way to mark exact versions of commits. If you change versions a lot, they are a life saver for an organization instead of just using branches, which commonly leaves you with lots of rarely used branches.

Here’s a look at a hypothetical scenario for adding tags: You’re a release manager getting ready for a release so you navigate to Bitbucket’s UI and view all the commits, looking for the one that has all the features you want to include and has passing builds. You find the commit and realize that it is missing a release tag, so you go to the command line – create and push the tag so you can tag the commit for the release, then go back to Bitbucket’s UI to view the tag and ultimately, do the release. This is a major pain (shakes fist at context switching).

Add tags from the UI vs the command line

Bitbucket users have asked us how they can cut out this back and forth and tag commits directly from Bitbucket Cloud’s UI, and today we’re launching this capability to add annotated git tags and regular mercurial tags directly to commits from the UI. The name of the tag, date/time, and author can be applied to any commit.

If you’re reading this thinking “why would someone tag a commit from the UI? The command line works just fine for me.” Lets look at where you can save time and find commits that need tagging in Bitbucket without switching over to the command line:

Add tags from Bitbucket’s UI


To add a tag, navigate to a commit in your repository and click on the commit in need of a tag. In the details pane, on the right side of the commit view, you can see ‘current tags’ and ‘create tag’. Once ‘create tag’ is selected, the author and timestamp will automatically be recorded.

In the future we will be expanding tagging from the UI with the ability to add custom messages to compliment any annotated git tag applied in the UI. If you are looking for lightweight tags, they can still be added via our API but are not currently available in the UI.

Try tagging commits

If you already use Bitbucket, start saving time with this new feature and start tagging (allthethings). If you’re new to Bitbucket, sign up for a Bitbucket Cloud account, create a repo and make a commit to take it for a spin. If you get stuck, more in depth tagging documentation is available here.

Get started, it’s free

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


Find & fix errors faster with Rollbar + Bitbucket

By on January 6, 2017

[This guest post is written by Jesse Gibbs, Head of Product at Rollbar. Jesse is a developer turned product manager who has spent 15+ years at companies building tools for software development, devops, and QA teams.]

Rollbar notifies developers in real-time when critical errors occur in their production apps. And now, Rollbar integrates with Git repositories and issue tracking in Bitbucket so that developers can troubleshoot and fix errors fast, ensuring that important errors don’t slip through the cracks.

Let’s take a look at how this works:

Deep links to source code in stack traces
Every Rollbar error report includes a full stack trace. With Rollbar connected to your Bitbucket Git repo, the stack trace entries become URLs linking to the exact line of code in source file.

When troubleshooting critical, customer-facing errors, developers can jump immediately from stack trace to source code, saving valuable time when every second counts.

Correlate Errors to Deploys
It’s easy to notify Rollbar every time you deploy to production or release a new version of your app. Rollbar integrates with Bitbucket Pipelines, and you can easily track deploys with other tools. Tracking deploys unlocks several valuable features in Rollbar that will make root cause analysis easier.

Suspect Deploys
With deploy tracking enabled, Rollbar will tell you which deploy preceded the first occurrence of an error, or a re-occurrence of an error that was previously fixed.


View deployment details
Rollbar’s Deploys view provides a quick summary of all your recent deploys, including who triggered the deploy and what changes were included. This information can speed up root cause analysis when a recent change led to a spike in errors.


Visualize deploys and errors across time
When deploys are tracked in Rollbar, they will appear in project and error-level timelines that show error frequency across the last few minutes, hours, and days.


With deploys displayed on these charts, you can quickly confirm if a particular deploy caused a spike in errors.

Track Rollbar errors with Bitbucket issues (JIRA too)
Production apps often have more errors than developers can fix immediately. To ensure that nothing slips through the cracks, Rollbar errors can be linked to Bitbucket or JIRA issues.


Issues in Bitbucket and JIRA can be automatically or manually created from Rollbar, or a Rollbar error can be linked to existing issues. When Rollbar errors are resolved or reopened, the corresponding Bitbucket or JIRA issue is updated.

For teams using JIRA Cloud, the Rollbar for JIRA add-on surfaces real-time error frequency data in JIRA and also updates Rollbar error status when JIRA issues are updated for complete 2-way status sync.

See Rollbar in action with Hipchat, Bitbucket and JIRA
Rollbar integrates with Hipchat, Bitbucket, and JIRA so developers can get notified, investigate, and keep track of critical production errors with the tools they use every day. Check out the Rollbar + Atlassian page to watch a quick video and sign up for a 14-day free trial.


2 additional ways to trigger your builds in Pipelines

By on January 3, 2017

If you didn’t hear it already, Bitbucket recently announced Pipelines which lets your team automate the integration and delivery process. Automation in software development is becoming increasingly important. Automation saves you time because you have less manual work and it reduces risk by giving you a consistent and repeatable process for all of your team’s code. Ultimately, you spend less time putting out fires and more time releasing quality code, faster.

While in most cases, your team will want to use automation to trigger builds when branches are pushed, there are times when you may want to add a manual step to your process, such as with longer-running builds or triggering a release manually.

That’s why we’ve added manual pipelines.

Trigger builds manually


Just add a custom pipeline to your bitbucket-pipelines.yml and you’ll be able to trigger it for a commit in Bitbucket.

Trigger builds with tags

Many of those already using Pipelines have asked for this, and we listened! In addition to letting you set up manual pipelines we’ve also introduced an additional way to trigger your builds — with tags.

You can now trigger your builds with tags in your Git repository (and bookmarks for Mercurial repositories). While your usual development workflow may mean pushing branches, your team might use tags to mark a commit for release. For example, configure a pipeline that deploys on tags then tag your commit to deploy it. Additionally, the name of the tag being built will be available as an environment variable as <$BITBUCKET_TAG>.

image: node:4.6.0

– step:
– npm install
– npm test
– step:
– npm install
– npm test
– npm publish ./

Check out our guide on how to trigger builds with tags.

Try Bitbucket Pipelines

If you’re ready to get started with Bitbucket Pipelines, sign up for a Bitbucket cloud account.

If you’re already using Pipelines, you can learn how to set up manual-triggered and tag-triggered builds here. Have feedback for us on these features? Tell us what you think by tweeting us @Bitbucket.


The Bitbucket Pipelines Team

Bitbucket Server: a year in review

By on December 13, 2016


2016 has certainly been a year for the books. All year long the Bitbucket Server & Data Center team has been improving Bitbucket and adding new features you have requested. You told us that modern software developers require tools that are reliable, let them move fast, and build with high quality. We took your feedback to heart and built features that enable collaborative development without sacrificing speed or performance.

One hundred customer suggestions resolved, 100+ Bitbucket T-shirts printed, and thousands of cups of coffee consumed is one way to describe 2016 for Bitbucket Server, but that only scratches the surface.

To celebrate the launch of our final release in 2016, we thought it only fitting to review our development stats and favorite new features of the year.

Bitbucket Server team landscape

Our Bitbucket team was busy coding, designing, and documenting throughout the year. Here’s a peek at some of our most interesting stats.


Favorite new features

A year in review post wouldn’t be complete without a look at our most memorable features. From boosting performance for geographically dispersed teams to creating an unrivaled pull request workflow we did something for everyone.




Pull request progress became easier to track with reviewer status



Resolved one of our most requested feature suggestions with code search across projects and repositories








iterative review

Streamlined the code review process with iterative reviews


The end of a busy year

In the software development world, every new year brings about new technologies and ways of working. Since Bitbucket Server’s beginning in 2012 it has been our privilege to find creative and thoughtful ways to make these changes available to you. Bitbucket Server 4.12, available today, caps off a year full of releases that do just that – bring modern software development to professional teams.

As 2016 comes to an end, we’d like to send a big thank you to all of our customers. You are the reason we get to do what we love every single day.

Start the new year off right and upgrade to Bitbucket Server 4.12 today.

Try Bitbucket Server 4.12

Protect your master branch with Merge Checks

By on December 5, 2016

Your master branch represents the code that you will ship to your customers, and should be protected at all costs. No one intends to ship a bug to a customer on purpose, so having a mechanism in place to catch these subtle bugs is essential to a development team. Code review has been around in some form since the dawn of version control to help keep a close eye on the master branch and ensure code quality is high.

Pull requests in particular provide a way to do peer code reviews and merges as part of a branch-based development workflow. As teams grow sometimes you need to take pull requests a step further to really make sure code is ready to be merged in to the family jewel: the master branch.

Merge Checks in Bitbucket Cloud

That’s why we added merge checks to Bitbucket: they make it easy to ensure that every Pull Request is fully vetted before it gets merged. This gives teams the flexibility to:

Bitbucket merge checks

Atlassian is a public company, so the Bitbucket team uses these checks as part of our compliance controls to prevent unauthorized changes to our code, and we know many teams have similar requirements. We also know that having an entire repository locked down can be frustrating, which is why we made merge checks totally configurable at the branch level. Production code can be protected and thoroughly reviewed but until it’s ready, you can still iterate quickly on features in dev and staging, all in the same repository.

Try Merge Checks

Merge checks are a feature in Bitbucket Cloud’s Premium plan which has features for teams that require granular admin controls, security and auditing. All features in Bitbucket Cloud’s premium plan are in a free trial until early 2017 when the plan will be $5/user/month.If you’re ready to get started, sign up for a Bitbucket Cloud account.

If you’re already using Bitbucket Cloud, you can add merge checks from your repository settings menu, under the branch permissions section.

Happy coding!

Get started for free

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

Software Development Trends and Benchmarks

By on November 30, 2016

This report holds data from more than 17,000 software professionals—as well as 1,300 of our own customers— to identify what tools and practices teams are using to move quickly and stay ahead of competition.


Download the Whitepaper

Faster development for distributed teams with Smart Mirroring

By on

Modern software development teams are increasingly distributed around the globe and expect to work fast from anywhere in the world. However, the desire for development speed can sometimes be blocked by factors out of your control – like waiting hours when cloning because you’re in a remote location and have a slow internet connection. This is a common occurrence if your team is working with lots of historical information in your repository, is storing large binary files or is using monolithic repos.

Reduce clone times with Smart Mirroring

We developed Smart Mirroring for Bitbucket Cloud with these distributed teams in mind who want to drastically reduce clone times. With Smart Mirroring, you can:

Smart mirroring can be set up in 4 steps, and less than 10 minutes. You install the mirror locally, set up security with SSL, start and connect the mirror to Bitbucket Cloud, select what you want to mirror, then sit back and enjoy the speed. Below is a mirror in action, increasing speed by 1.5x:

smart mirroring

Try Smart Mirroring

Smart Mirroring is a feature in Bitbucket Cloud’s Premium plan which has features for teams that require granular admin controls, security and auditing. All features in Bitbucket Cloud’s premium plan are in a free trial until early 2017 when the plan will cost $5/user/month. If you’re ready to start mirroring in a free trial, sign up for a Bitbucket Cloud account.

If you’re already using Bitbucket Cloud, learn how to set up and evaluate a Smart Mirror in less than 10 minutes to see mirroring in action.

Get started for free

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

5 pull request must-haves

By on November 15, 2016

Raise your hand if you remember the days of in-person code reviews. Whole afternoons spent checking out changes from SVN, running them locally, and making notes of areas that could be improved. Then spending another hour or two in a room with your team discussing suggestions live. Once changes were incorporated the whole process began again until it was finally time to merge. Ah merging… never fun and often times a total nightmare.

Quality time with the team is great, but we sure are glad those days are over. Thanks to the rise of distributed version control (DVCS), like Git, the process to garner peer feedback has vastly improved. Git’s ability to branch and merge easily has made it possible to review smaller sets of changes more often. This type of code review is based on a concept known as pull requests. Pull requests provide a forum to discuss proposed changes to your codebase before they’re merged into shared branches (e.g. before merging a feature branch into master).

pull request

The popularity of Git and pull requests have been growing exponentially with no signs of slowing down. The benefits of peer review – higher quality code, shared team knowledge, shared sense of ownership – and flexible workflows in Git have lured teams of all sizes. Amadeus, one of our largest customers, employs over 5,000 developers. Since they made the switch from SVN to Git three years ago, pull requests have become an invaluable tool to protect against poor quality code.

“At Amadeus Bitbucket supports 1,000+ pull requests a day and it’s growing. Pull requests are at the core of how we want our developers to work for higher quality and faster time to market.” – Frederic Ros, Head of Development Efficiency.

Selecting a Git management tool

With development speed and code quality at stake, it’s no surprise that pull requests have become a key selling point for Git management tools. Of course other factors are at play – like security, scalability, and deployment flexibility – but when it comes to developer productivity it’s the pull request experience that will set one tool apart from the others. We believe the pull request experience is THE most important deciding factor when selecting a version control solution. They are the best way ensure you’re releasing the highest quality code possible.

In talking with teams among our 60,000 customers, and of course our experience as developers, we have found that pull requests work best when 5 key pieces of functionality are in place. Let’s take a look at these areas and how Bitbucket Server provides them.

1. Assigned reviewers

In their most basic form, pull requests are simply a request to merge changes into a destination branch or fork. Once you introduce the idea of adding reviewers, they become much more than that – a forum for open discussion around code. When you’re looking at a tool to manage your Git repositories, the ability to explicitly add your team members as reviewers is the basis for a sound review workflow. How else will your team know they need to review your changes?

In Bitbucket Server we make the process even smoother by giving you the option to set up default reviewers for specific types of branches (i.e. feature, hotfix, or bugfix). You also have the ability to use Marketplace add-ons for additional functionality, like the Bitbucket Server Reviewer Suggester.


2. Comment on ALL THE THINGS 

What would a good code review be without the comments? Capturing feedback in-context gives pull request authors a reference point for enhancements. Reviewers can make suggestions for changes or congratulate their team member on a brilliant piece of logic.

In Bitbucket Server you have the option to leave all types of comments: on the entire pull request, commit by commit, on a particular file, or on specific lines of code in a file. Every developer has their preferred way to read and review code, so your tool should cater to everyone.


Pro tip: Need a second opinion on a specific section of code? In Bitbucket Server, you can use an @mention on a particular line to bring in a busy specialist (e.g. front-end ninja, performance engineer, security expert) to review something in particular without saddling them with the whole review.

3. Iterative review

Pull requests create a feedback loop – you write some code, your team reviews, you incorporate changes, your team reviews and approves them, you merge, and then you’re done. If your Git management tool doesn’t provide a mechanism to capture reviewer status or review iterations, how are you supposed to keep track?

In Bitbucket Server, we solve this problem by providing status buttons for reviewers (i.e. if the author needs to make changes you can click “Needs Work”). Once changes have been incorporated, reviewers can easily find what’s new via iterative review, a mechanism allowing you to constrain the diff to only new changes since you last reviewed. No need to hunt through files for changes or re-review old code. If your team cares about spending their time wisely, then iterative review is a Git tool must-have.

iterative review

4. Workflow flexibility

The creation of a development workflow involves a lot of factors. For example: Do you work in a highly regulated industry? Who should have access to your codebase? What types of quality checks do you need? The list goes on. This is why workflow flexibility is so important; no two development teams are exactly alike.

In Bitbucket Server we give you the freedom to pick how a pull request is merged (available merge strategies include merge commit, fast forward only, and squash) and when it is merged with merge checks (e.g. only allow merges if there are 2 approvals and a passing build). No other Git tool rivals the flexibility found in Bitbucket Server. We give you the power to decide how you want to work, not the other way around.


5. Integrations

Finally, before purchasing a brand new Git management tool, consider how it will fit in with the rest of your toolchain. Development is way more fun when you don’t have to jump between tools to report on pull request status. With thoughtful integrations like smart commits, the ability to transition JIRA issues via commit messages, Bitbucket Server handles the overhead for you. Save time and keep everyone up to date with first-class JIRA Software, HipChat, and Bamboo integrations. Using other tools? Atlassian provides a Marketplace full of additional integrations and functionality through add-onsWhy settle for a “jack-of-all-trades” tool when you can combine the power of best of breed tools that work for you?

dev panel

The right choice for your team

Peer feedback reduces the amount of bugs in your code. It’s a safety net for developers, a way to ensure you’re putting out the highest quality code you can. At the end of the day, your customers only care if your product works for them or not. That’s why code review and pull requests are so important when selecting a Git management tool. This process cannot fail you.

By choosing Bitbucket Server, you’re choosing the best pull request experience for your team. Assigned reviewers, in-context comments, iterative review, workflow flexibility, and first-class JIRA integration are all built in. We have made pull requests a priority, and folks like AmadeusSplunk, and our third party Solution Partners have noticed.

“Pull requests have become a non-negotiable part of the developer workflow. Bitbucket Server’s pull requests are one of the top reasons our customers switch to Bitbucket” – Zubin Irani, CEO cPrime Inc.

Make pull requests your priority and try Bitbucket Server today!

Try Bitbucket Server

Interested in Bitbucket Cloud pull requests? Learn more here.

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