Universal 2nd Factor (U2F) now supported in Bitbucket Cloud

By on June 22, 2016


Last week, we released support for FIDO Universal 2nd Factor in Bitbucket Cloud. FIDO U2F is an emerging standard for two-step verification that uses a physical USB key to digitally sign a challenge from a trusted website. It’s a new authentication standard designed to enable small USB tokens, mobile phones, and other devices to act as a secure second factor for 2FA without requiring any additional overhead of installing drivers or client-side software applications.

What does this mean for you?
You may have heard about some high profile breaches and subsequent unauthorized publication of stolen user credentials in the past few weeks. Two-step verification on your Bitbucket Cloud account ensures that your data will continue to be protected even if someone else gets your password.

With U2F, instead of having to enter a TOTP (Time-based One-time Password) every time you want to log in to Bitbucket Cloud, you can simply press a button on a small USB device plugged into your computer. You are also less vulnerable to phishing attacks since security keys will only sign challenges that match the proper domain for the website.


Visit two-step verification settings to add your key. If you do not already have two-step verification enabled, you’ll need to enable it before you can use your U2F key with Bitbucket Cloud.

Special Yubikey promotion for Bitbucket users
You’ll need to purchase a security key that supports U2F in order to take advantage of this feature. We’re collaborating with Yubico, co-creator of the U2F protocol, and offering discounts for a limited time through a special offer: Bitbucket teams can purchase up to 10 keys at a 25% discount, (while supplies last). You can find more information about the offer here.

We are proud to be among the first few websites to support this standard. “We applaud Atlassian for their support for the FIDO U2F protocol, by introducing this forward thinking strong public key cryptography two-factor authentication option to their user base,” said Jerrod Chong, VP Solutions Engineering, Yubico. Earning and keeping your trust is part of our customer commitment. Learn more about 2FA and U2F.

Atlassian account is coming to Bitbucket Cloud

By on June 14, 2016


Forget about having to remember multiple passwords and say hello to a better Atlassian experience in the cloud. Bitbucket users are now being upgraded to Atlassian account. The integration of Atlassian account with all Atlassian Cloud services is currently in progress, and when it is complete, you will be able to log in to Bitbucket, JIRA, Confluence, and HipChat with one Atlassian account. In addition, you can now use your Atlassian account to log in to SourceTree and our support and billing systems.

The upgrade process will ask you to verify the email address that we have on file. This should be quick and painless, and then it’s back to Bitbucket business as usual!

Already have an Atlassian account? No worries, we’ll join your Bitbucket account to your existing Atlassian account. And if you want to change your email address associated with your Bitbucket account, click “Try another email” during the migration process. If you use Google authentication to log in, you can keep doing so provided it matches your Atlassian account email address.

Want to learn more about Atlassian account? Click here.

Git 2.9 is out!

By on June 13, 2016

Just a couple of months after version 2.8, Git 2.9 has shipped with a huge collection of usability improvements and new command options. Here’s the new features that we’re particularly excited about on the Bitbucket team.

git rebase can now exec without going interactive

Many developers use a rebasing workflow to keep a clean commit history. At Atlassian, we usually perform an explicit merge to get our feature branches on to master, to keep a record of where each feature was developed. However, we do avoid “spurious” merge commits by rebasing when pulling changes to our current branch from the upstream server (git pull −−rebase) and occasionally to bring our feature branches up to date with master (git rebase master). If you’re into rebasing, you’re probably aware that each time you rebase, you’re essentially rewriting history by applying each of your new commits on top of the specified base. Depending on the nature of the changes from the upstream branch, you may encounter test failures or even compilation problems for certain commits in your newly created history. If these changes cause merge conflicts, the rebase process will pause and allow you to resolve them. But changes that merge cleanly may still break compilation or tests, leaving broken commits littering your history.

However, you can instruct Git to run your project’s test suite for each rewritten commit. Prior to Git 2.9 you could do this with a combination of git rebase −−interactive and the exec command. For example:

git rebase master −−interactive −−exec=”npm test”

would generate an interactive rebase plan which invokes npm test after rewriting each commit, ensuring that your tests still pass:

pick 2fde787 ACE-1294: replaced miniamalCommit with string in test
exec npm test
pick ed93626 ACE-1294: removed pull request service from test
exec npm test
pick b02eb9a ACE-1294: moved fromHash, toHash and diffType to batch
exec npm test
pick e68f710 ACE-1294: added testing data to batch email file
exec npm test

# Rebase f32fa9d..0ddde5f onto f32fa9d (20 command(s))

In the event that a test fails, rebase will pause to let you fix the tests (and apply your changes to that commit):

291 passing
1 failing

1) Host request “after all” hook:
Uncaught Error: connect ECONNRESET

npm ERR! Test failed.
Execution failed: npm test
You can fix the problem, and then run

        git rebase −−continue

This is handy, but needing to do an interactive rebase is a bit clunky. As of Git 2.9, you can perform a non-interactive rebase exec, with:

git rebase master -x “npm test”

Just replace npm test with make, rake, mvn clean install, or whatever you use to build and test your project.

git diff and git log now detect renamed files by default

Git doesn’t explicitly store the fact that files have been renamed. For example, if I renamed index.js to app.js and then ran a simple git diff, I’d get back what looks like a file deletion and addition:

diff −−git a/app.js b/app.js
new file mode 100644
index 0000000..144ec7f
−−− /dev/null
+++ b/app.js
@@ -0,0 +1 @@
+module.exports = require(‘./lib/index’);
diff –git a/index.js b/index.js
deleted file mode 100644
index 144ec7f..0000000
−−− a/index.js
+++ /dev/null
@@ -1 +0,0 @@
-module.exports = require(‘./lib/index’);

A move is technically just a move and a delete, but this isn’t the most human-friendly way to show it. Instead, you can use the -M flag to instruct Git to attempt to detect renamed files on the fly when computing a diff. For the above example, git diff -M gives us:

diff −−git a/app.js b/app.js
similarity index 100%
rename from index.js
rename to app.js

What does -M stand for? renaMes? Who cares! As of Git 2.9, the git diff and git log commands will both detect renames by default, unless you explicitly pass the −−no-renames flag.

git clone learned −−shallow-submodules

If you’re using submodules, you’re in luck – for once! 🙂 Git 2.9 introduces the −−shallow-submodules flag that allows you to grab a full clone of your repository, and then recursively shallow clone any referenced submodules to a depth of one commit. This is useful if you don’t need the full history of your project’s dependencies. For example, if you have a large monorepo with each project stored as a submodule, you may want to clone with shallow submodules initially, and then selectively deepen the few projects you want to work with. Another scenario would be configuring a CI or CD job that needs to perform a merge: Git needs the primary repository’s history in order to perform its recursive merge algorithm, and you’ll likely also need the latest commit from each of your submodules in order to actually perform the build. However you probably don’t need the full history for every submodule, so retrieving just the latest commit will save you both time and bandwidth.

Overriding .git/hooks with core.hooksPath

Git’s comprehensive hook system is a powerful way to tap into the lifecycle of various Git commands. If you haven’t played with hooks yet, take a quick look at the .git/hooks directory in any Git repository. Git automatically populates it with a set of sample hook scripts:

$ ls .git/hooks

applypatch-msg.sample pre-applypatch.sample pre-rebase.sample
commit-msg.sample pre-commit.sample prepare-commit-msg.sample
post-update.sample pre-push.sample update.sample

Git hooks are useful for all sorts of things, for example:

App passwords are here in Bitbucket Cloud

By on June 6, 2016

Keeping your code secure is crucial. That’s why last year we added support for 2-factor authentication. However, only having native 2FA support limits you from accessing Bitbucket repositories via 3rd party applications. Today, we’re excited to announce application-specific passwords (a.k.a. app passwords), which will allow you to just do that. App passwords let applications access Bitbucket’s API via HTTPS when 2-factor authentication is enabled on your Bitbucket account.

app password list retina

For example, you can use an app password in SourceTree to get full desktop access to your repositories when you have 2FA enabled. From the command line, you can make API calls with the app password instead of the account password, like:

curl --user bitbucket_user:app_password https://api.bitbucket.org/1.0/user/repositories

Granular scopes
You can set the scope of app passwords when you create them and give each application exactly the access it needs. We show you the last time each app password was used to access Bitbucket, and if you want, you can easily revoke an app password if something changes.

app password create retina

You can create and manage app passwords in the Access Management section of your account settings, or check out the docs to learn more.

Happy (and secure) coding!

Bitbucket Pipelines Beta: continuous delivery inside Bitbucket

By on May 24, 2016


Software has changed the world faster than almost any other industrial innovation and it’s only picking up speed. Companies are moving from infrequent, large code deployments to frequent, small and agile deployments. This trend is having a huge impact on the current software development processes. For example, in one of our most recent customer surveys, more than 65% of software teams noted that they are practicing some form of continuous delivery. It’s becoming the norm for software teams.

But implementing continuous delivery is not easy. Setting up build agents is complicated. Developers have to constantly juggle between different tools. And most of the time, the build is sitting in a queue, or you’re burying yourself in log files digging for information about failures.

Bitbucket Pipelines
That is until now. Bitbucket Cloud is introducing Pipelines to let your team build, test, and deploy from Bitbucket. It is built right within Bitbucket, 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. Just enable it in one click and you’re ready to go.

Pipelines is also a great fit for branching workflows like git-flow. Anyone on your team can adapt the build configuration to map the structure of your branches. Here is a quick look at some of the salient features of Bitbucket Pipelines:

Bring your own services to Bitbucket Pipelines
We worked very closely with some of the leaders in the industry so you can bring your own services to Bitbucket Pipelines, right out of the box. Whether you want to deploy, test, monitor code quality, or store artifacts, complete any workflow with the tool of your choice: Amazon Web Services, Ansible, bitHound, BrowserStack, buddybuild, Code Climate, JFrog, Microsoft Azure, npm, SauceLabs, Sentry, Sonatype, and TestFairy.

Pipelines provided us with the perfect opportunity to bring the power of automated code quality analysis to Bitbucket users. We’re excited about the awesome potential of Pipelines and they’re only just getting started!” –Michael Bernstein, VP of Community, Code Climate.

Check out our integrations page for more details.

Continuous Delivery options from Atlassian
We believe that the best way to provide our customers with a top-notch cloud CD solution is to build the service natively within Bitbucket Cloud. That’s why we built Bitbucket Pipelines and also why today, we’re announcing the end-of-life for Bamboo Cloud, which will be discontinued starting Jan 31, 2017. While Bamboo Cloud has helped many customers to adopt CD, we realized that we would not be able to deliver the experience and the quality of service that our customers need. If you’re a Bamboo Cloud customer, click here to learn more about the migration options.

If you want to build and ship behind the firewall, we’re still heavily investing in Bamboo Server as an on-prem CD solution.

Get early access to Bitbucket Pipelines
With Bitbucket Pipelines we want to empower every team to accelerate their releases. No more time wasted on setup and maintenance, just focus on the work you love. You can sign up for the Bitbucket Pipelines beta program today and request early access.

Sign up for the beta program

Pin a comment in issues for Bitbucket Cloud

By on May 11, 2016

Every few weeks, we set aside a week for what we like to call “Innovation Week”. During that time, our developers can work on whatever they like – feature enhancements, new features, bug fixes, performance improvements, etc. Today, we’re releasing one of the projects from our most recent Innovation Week: the ability to pin a comment in issues as an “Official response“:

Screen Shot 2016-05-10 at 3.31.37 PM

Repository administrators can now pin their comment to the top of an issue’s comments section. It will be highlighted as an “Official response” right below the issue’s description and can be used for communicating a resolution status, highlighting open questions, or providing additional context and clarification. It will be particularly useful for large open-source repositories or repositories owned by organizations with large user bases.

This feature is available now for all users. Happy pinning!

Build webhook integrations faster with new troubleshooting tools

By on May 5, 2016

Last year, we released a set of new webhooks to make integration with Bitbucket Cloud easier and more powerful. The response has been overwhelming. We recently added new troubleshooting tools to better support all of you developing integrations using Bitbucket webhooks.

Request details page
We’ve added a “View details” link next to each webhook request on the log table. The new “Request details” page includes a lot of useful information about the webhook request and response, including headers, bodies, and other specifics that will help you debug.

USE 1 webhook log table

Resend request button
While developing or testing an integration, sometimes you need to trigger the same webhook multiple times while you make code changes between each request. This can be very time-consuming, slowing down your development speed. To alleviate this, we’ve included a “Resend request” button on the “Request details” page. Now you can just click once to resend the original request manually – no need to go through the steps to trigger the hook again. And if a request has been resent several times, each try will split into its own tab for easy reference.

USE 2 multiple requests

Also, the request list view now displays an icon to indicate when a request has been attempted multiple times:

USE 1 webhook log table 2

We hope these improvements will enhance your webhook development experience! If you’re new to Bitbucket webhooks, you can configure them in your repository settings. Are you inspired to build new, exciting integrations? Clone our webhook-listener demo project to quickly get started with Bitbucket webhooks.

Renewing our certificate

By on May 4, 2016

It’s almost time to replace our main bitbucket.org certificate, so we’re planning to do that at 00:00 UTC on May 6 2016.

Most users shouldn’t notice any difference. However, if you’re using Mercurial over HTTPS, then you might see this error message after the new certificate is installed:

abort: certificate for bitbucket.org has unexpected fingerprint
(check hostfingerprint configuration)

If you do see that error, you’ll need to update the host fingerprint for bitbucket.org in your ~/.hgrc or Mercurial.ini configuration file:

bitbucket.org = 3f:d3:c5:17:23:3c:cd:f5:2d:17:76:06:93:7e:ee:97:42:21:14:aa

Happy branching!

Got questions? We’ve got answers. Git, agile and JIRA/Bitbucket answers to be exact.

By on May 3, 2016

Are you a JIRA Software or Bitbucket user? How about an Agile fan or Git enthusiast? We’re looking at you. To honor one of Atlassian’s core values, Don’t *%# the customer, we want you to use us as a resource. Today, Atlassian’s Product managers and developer advocates will unite to give your team the leg up on any JIRA Software/Bitbucket, Git or agile questions you may have.

How you ask?

Here’s the deal. Today we’ll be answering questions on Twitter from 12-7pm PST and will get to as many questions as we can, as fast as we can, until signing off at 7pm PST. Here’s how to join in the fun:

  1. Ask a question on twitter using the hashtag #AskJIRABB
  2. Be sure to follow both @JIRA and @Bitbucket to see your answer, and follow along with the conversation
  3. It’s as simple as that

To get the conversation started, here are some examples questions we can help you with:

Get the idea? Awesome. Gather your questions, your dev team, and join the conversation.

Protect our Git repos: stop foxtrot merges now!

By on April 28, 2016

This guest post is written by Sylvie Davies, the author of the Bit-Booster Commit Graph and More add-on for Bitbucket Server. Sylvie is a mother, poet, painter, pianist, and software developer with over 5 years experience in Java and JavaScript, and 2 years with Git. 


First, what is a foxtrot merge?

A foxtrot merge is a specific sequence of git commits. A particularly nefarious sequence. Out in the open, in lush open grasslands, the sequence looks like this:


But foxtrots are rarely seen in the open. They hide up in the canopy, in between the branches. I call them foxtrots because, when caught mid-pounce, they look like the foot sequence for the eponymous ballroom dance:



Others have blogged about foxtrot merges, but they never name them directly. For example, Junio C. Hamano blogs about having Fun With –First-Parent, as well as Fun With Non-Fast-Forward. David Lowe of nestoria.com talks about Maintaining Consistent Linear History.  And then there’s a whole pack of people telling you to avoid “git pull” and to always use “git pull –rebase” instead. Why?  Mostly to avoid merge commits in general, but also to avoid them darn foxtrot vermin.

But are foxtrot merges really bad? Yes.


They are clearly not as bad as the Portuguese Man o’ War. But foxtrot merges are bad, and you do not want them creeping into your git repositories.

Why are foxtrot merges bad?

Foxtrot merges are bad because they change origin/master’s first-parent history.

The parents of a merge commit are ordered. The 1st parent is HEAD. The 2nd parent is the commit you reference with the “git merge” command.

You can think of it like this:

git checkout 1st-parent
git merge 2nd-parent

And if you are of the octopus persuasion:

git merge 2nd-parent 3rd-parent 4th-parent ... 8th-parent etc...

This means first-parent history is exactly like it sounds.  It’s the history you get when you omit all parents except the first one for each commit. For regular commits (non-merges) the first parent is the only parent, and for merges it was the commit you were on when you typed “git merge.” This notion of first-parent is built right into Git, and appears in many of the commands, e.g., “git log –first-parent.”

The problem with foxtrot merges is they cause origin/master to merge as a 2nd parent.

Which would be fine except that Git doesn’t care about parent-order when it evaluates whether a commit is eligible for fast-forward. And you really don’t want that. You don’t want foxtrot merges updating origin/master via fast-forward. It makes the first-parent history unstable.

Look what happens when a foxtrot merge is pushed:


You can calculate the first-parent history yourself by tracing the graph with your finger starting from origin/master and always going left at every fork.

The problem is that initially the first-parent sequence of commits (starting from origin/master) is this:

B, A

But after the foxtrot merge is pushed, the first-parent sequence becomes this:

D, C, A

Commit B has vanished from the origin-master‘s first-parent history. No work is lost, and commit B is still part of origin/master of course.

But first-parent turns out to have all sorts of implications. Did you know that the tilda notation (e.g., <commit>~N) specifies the Nth-commit down the first-parent path from the given commit?

Have you ever wanted to see each commit on your branch as a diff, but “git log -p” is clearly missing diffs, and “git log -p -m” has way too many diffs?

Try “git log -p -m –first-parent” instead.

Have you ever wanted to revert a merge?  You need to supply the “-m parent-number” option to “git revert” to do that, and you really don’t want to provide the wrong parent-number.

Most people I work with treat the first-parent sequence as the real “master” branch. Either consciously or subconsciously, people see “git log –first-parent origin/master” as the sequence of the important things. As for any side branches merging in? Well, you know what they say:


But foxtrot merges mess with this. Consider the example below, where a sequence of critical commits hits origin/master in parallel to your own slightly less important work:



At this point you’re finally ready to bring your work into master. You type “git pull,” or maybe you’re on a topic branch and you type “git merge master”. What happens? A foxtrot merge happens.



This wouldn’t really be of any concern. Except when you type “git push” and your remote repo accepts it. Because now your history looks like this:




What should I do about the pre-existing foxtrot merges that have infected my git repo?

Nothing. Leave them. Unless you’re one of those antisocial people that rewrites master. Then go nuts.

Actually, please don’t.

How can I prevent future foxtrot merges from creeping into my git repo?

There are a few ways.  My favorite approach involves 4 steps:

1. Setup Atlassian Bitbucket Server for your team.

2. Install the add-on I wrote for Bitbucket Server called “Bit Booster Commit Graph and More.”  You can find it here:  https://marketplace.atlassian.com/plugins/com.bit-booster.bb

3. Click the “Enable” button on the “Protect First Parent Hook” in all your repos:


4. Call in sick to work for 31 days to make the trial license expire.

This is my preferred approach because it keeps the foxtrots away, and it prints a cow whenever a foxtrot is blocked:

$ git commit -m 'my commit'
$ git pull
$ git push

remote:  _____________________________________________
remote: /                                             \
remote: | Moo! Your bit-booster license has expired!  |
remote: \                                             /
remote:  ---------------------------------------------
remote:         \   ^__^
remote:          \  (oo)\_______
remote:             (__)\       )\/\
remote:                 ||----w |
remote:                 ||     ||
remote: *** PUSH REJECTED BY Protect-First-Parent HOOK ***
remote: Merge [da75830d94f5] is not allowed. *Current* master
remote: must appear in the 'first-parent' position of the
remote: subsequent commit.


There are other ways. You could disable direct pushes to master, and hope that pull-requests never merge with fast-forward. Or train your staff to always do “git pull –rebase” and to never type “git merge master” and once all your staff are trained, never hire anyone else.

If you have direct access to the remote repository, you could setup a pre-receive hook. The following bash script should help you get started:


# Copyright (c) 2016 G. Sylvie Davies. http://bit-booster.com/
# Copyright (c) 2016 torek. http://stackoverflow.com/users/1256452/torek
# License: MIT license. https://opensource.org/licenses/MIT
while read oldrev newrev refname
if [ "$refname" = "refs/heads/master" ]; then
   MATCH=`git log --first-parent --pretty='%H %P' $oldrev..$newrev |
     grep $oldrev |
     awk '{ print \$2 }'`

   if [ "$oldrev" = "$MATCH" ]; then
     exit 0
     exit 1


I accidentally created a foxtrot merge, but I haven’t pushed it. How can I fix it?

Suppose you install the pre-receive hook, and it blocks your foxtrot. What do you do next? You have three possible remedies:

1. Simple rebase:


2. Reverse your earlier merge to make origin/master the first-parent:


3. Create a 2nd merge commit after the foxtrot merge to preserve origin/master’s –first-parent relation.


But please don’t do #3, because the final result is called a “Portuguese man o’ war merge,” and those guys are even worse than foxtrot merges.


At the end of the day a foxtrot merge is just like any other merge. Two (or more) commits come together to reconcile separate development histories.  As far as your codebase is concerned, it makes no difference. Whether commit merges into commit B or vice versa, the end result from a code perspective is identical.

But when it comes to your repository’s history, as well as using the git toolset effectively, foxtrot merges create havoc.  By setting up policy to prevent them, you make your history easier to understand, and you reduce the range of git command options you need to memorize.

Did you like the git graphs in this blog post?   You can make similar git graphs for your own blog posts using the git-graph-drawing-tool: http://bit-booster.com/graph.html.  You can also install the Bit-Booster Commit Graph add-on for Bitbucket Server to block foxtrots AND see nice git graphs.