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 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:

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.
# Copyright (c) 2016 torek.
# License: MIT license.
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:  You can also install the Bit-Booster Commit Graph add-on for Bitbucket Server to block foxtrots AND see nice git graphs.

Updated diff view for moved or renamed files in Bitbucket Cloud

By on April 14, 2016

On the heels of other improvements to code review that we recently released, today we’re updating the diff view to better represent moved or renamed files in Git repositories. This will speed up your code review by collapsing files whose contents have not changed—enabling you to jump right into the code that actually requires review. No more wading through large blocks of code for moved or renamed files!


Try out the new view for renamed/moved files today by visiting the “Labs” page (“Bitbucket settings” → “Labs”) and turning on “Show renamed/moved files in diffs“:


While you’re there, check out the “improved pull request list” if you haven’t already. We’ve updated the pull request list to make it easier for you to quickly find the pull requests you need to review and show the state of a review at a glance. We’ll be rolling out both these features to everyone over the next few weeks. Happy code reviewing!

Get to master faster with pull requests in Bitbucket Server

By on April 7, 2016

Pull requests provide a lightweight way to do peer code reviews and merges as part of a branch-based development workflow. Sure beats having to huddle around a monitor with 3 other developers! Today I’d like to share with you some improvements we’ve made to pull requests in Bitbucket Server that will help you get to master faster.

Pull request reviewer status

Professional teams benefit from having an explicit set of reviewers on pull requests, making it clear who is expected to pitch in and review. And we built that into Bitbucket long ago. As powerful as that has been, we’ve heard feedback that it wasn’t obvious who had reviewed the latest changes – even to the reviewers themselves. Some reviewers were also appearing a little too judgmental and reaching for the decline button when they really just wanted to say that the code needed a little improvement.

Pull requests need a way to help reviewers and authors keep track of what was going on around all the feedback flying around. So we added reviewer status to make reviewers’ intention clear to everyone. As a result, both the author and reviewers can see which pull requests need their attention. We shipped this last month with Bitbucket Server 4.4 and have seen strong uptake amongst our customers.

Another useful improvement we made to pull requests is the ability for users to quickly add or remove themselves as a reviewer. If you’re on a team that adds lots of reviewers, it’s now easy for a reviewer to opt out whilst make it clear who’s still on the hook. Conversely, if your teammates prefer to “self-select” by opting in as a reviewer, that’s easy too.

Even better branch permissions

Awesome pull requests are awesome and everything… but only if people use them. We’ve long had branch permissions that let teams choose who can write to a branch without a pull request. That’s pretty much an expected feature these days. Recently, we made it possible to protect certain branches by requiring pull requests for changes.

Organizations that wanted stricter pull request based workflows found this quite useful, though as some pointed out, there are times when bypassing this restriction is necessary. For example, when applying merges of already approved changes between release branches.

With Bitbucket Server 4.5, it’s now possible to nominate exceptions to any of the available restrictions – be it force pushes, branch deletions, or requiring pull requests. This means you can ensure developers’ changes always go through pull requests, while the release manager can propagate previously reviewed changes with regular merges.

Overdue for a Bitbucket upgrade?

If you’ve been holding off upgrading to the latest release or want to try Bitbucket Server for the first time, there’s never been a better time. Get these goodies into developers’ hands and they’ll thank you for helping them fly! Download Bitbucket 4.5 here.

Code review just got even better in Bitbucket Cloud

By on April 6, 2016

High performing teams use code reviews. A lot. And most of the time code reviews are done using pull requests.

Improved pull request list
We’ve updated Bitbucket’s pull request list to make it even easier for you to quickly find the pull requests you need to review, and to show you the state of a review at a glance:

We’ve improved the filter bar to let you jump right to the pull request you need to approve and filter by author, target branch or pull request state. You can search for the pull request too. The updated display shows who’s reviewing each pull request, who has already approved it, and which branch it’s targeting, so it’s easy to see how your team’s code reviews are progressing.

Manage features
Try out the new pull request list today by visiting the Labs page and turning on the improved pull request list:

Please provide feedback straight from the Labs page by clicking “Give feedback”. Your feedback will help us get it right. We’ll be rolling out the improved pull request list to everyone over the new few weeks.

We will use the Labs functionality in Bitbucket Cloud to gradually roll-out new features to our users. This will let you provide extensive feedback to our engineering teams and help make the feature better before we roll it out to everyone.

Ignore whitespace
Remember when you had to add ?w=1 to your page URL to ignore whitespace? That did the trick, but it wasn’t very intuitive. Now it is.

Now, every time you’re reviewing some code and want to ignore whitespace on that diff, click the “More Actions” menu (i.e., the ellipses “…”) and select “Ignore whitespace”. Selecting this option will ignore whitespace across all changed files. This option is available for everyone today.

We hope these new features we introduced recently improve your code reviewing experience in Bitbucket Cloud. Happy coding!


Did you find this post useful? Share it on your social network of choice so your fellow Bitbucketeers can learn about these new goodies, too!

How teams using JIRA Software and Bitbucket release 14% faster (and so can you!)

By on April 5, 2016

In the world of software, dev speed is critical. Better to add that highly-requested feature to your product today than see it show up in a competitor’s product tomorrow.

We did an extensive study amongst our users and found teams who have JIRA Software and Bitbucket integrated release 14% more often (when compared to teams using just one of those products). Part of the difference is that these teams chose JIRA Software and Bitbucket because they support the practices high-performing teams already want to adopt: agile planning, branch-based development, and continuous delivery. The other difference is due to the tools themselves: they help teams move faster.

So how do you maximize our integration between JIRA Software, the #1 software development tool used by agile teams, and Bitbucket? I’m glad you asked. Here’s an overview of what the integration does, as well as how easy it is to set up. I’ll also link you to documentation that can guide you through the steps in more detail.

Step 1: Connect JIRA Software and Bitbucket in less than a minute

Yes, you read that correctly. Linking your JIRA Software and Bitbucket instances now takes about 30 seconds. To quote Bruno Mars, “Don’t believe me – just watch.” Watch this 30-second video, that is:

Once you’ve linked JIRA Software and Bitbucket, your team will enjoy integration features that support faster release cycles through JIRA Software’s development panel, workflow triggers, and the release hub.

Step 2: Branch from within JIRA Software and activate the dev panel

With JIRA Software and Bitbucket talking to one another, engineers can save time by creating branches directly from the development panel inside any JIRA issue. Branching this way means less app-switching, and JIRA Software even pre-populates Bitbucket branch names based on the issue’s key and summary. With the issue key included in the branch’s name, information about commits, build, pull requests, and deploys is automatically sent back to the issue so it’s all in one place.

This integration is great for the rest of the team, too. With everything about the issue’s development updating in realtime, your team will spend less time shoulder-tapping one another for status updates and more time moving towards the next release.

Creating branches locally? No problem. All of the visibility and benefits of the development panel described above works exactly the same.

Create branches with JIRA Software and Bitbucket

Step 3: Configure workflow triggers on a customized workflow

JIRA Software and Bitbucket’s integration also lets you set up workflow triggers that will speed up the development process even more. Triggers can be added to any workflow status, which means that an action in Bitbucket can automatically update the status of a JIRA Software issue.

For example, you can set up a workflow trigger to automatically transition an issue from “To Do” to “In Progress” as soon as a developer creates a branch for the issue. Or you might need an issue to move from “In Review” back to “In Progress” if a pull request is rejected.

Automatic workflow triggers in JIRA Software and Bitbucket

Workflow triggers allow engineers to spend more where it counts, free them from having to manually update issues, and make sure JIRA Software’s dev panel is always up to date for the rest of the team. To add workflow triggers to your custom workflow, edit your workflow from the JIRA administration console and then click on “Triggers” within your chosen transition. For more workflow triggers use cases, check out this post.

Step 4: Release ahead of schedule with real-time release readiness

Once your team is taking advantage of the development panel inside JIRA issues, they’ll also begin benefiting from another feature: the release hub. The release hub dashboard gives a detailed – and automated – view of the progress of a release, replacing the manual process of checking individual issues for release readiness.

Release hub aggregates all the relevant information associated with an upcoming release. Then it generates warnings if it finds unreviewed code, open pull requests, or failing builds related to issues scheduled for release. This gives software teams the ability to track and release work in a more programmatic fashion, which tightens release cycles by a factor of days (if not weeks).

Release hub combines data from JIRA Software and Bitbucket

The release hub can be found in JIRA Software’s sidebar in the “Release” section. From day one of development to the hour before a release, release hub brings real-time release readiness to every member of your software team.

1 + 1 = 14%

It’s no coincidence that teams who have JIRA Software and Bitbucket connected are able to release 14% more often than teams who aren’t using these two tools together. With increased visibility, fewer status meetings, and real-time release readiness at your fingertips, every member of your team can accomplish more with greater speed and confidence. Automation of manual tasks means more efficiency and accelerated development cycles. And the best part is that we’re just getting started.

So if you could release software 14% more often, why wouldn’t you? Visit our JIRA Software/Bitbucket integration page to learn more and see these integrations in action.

See what JIRA Software and Bitbucket can do


Did you find this post helpful? Share it on your social network of choice so your fellow software makers can learn from it, too!

Software teams ship more often with JIRA Software and Bitbucket

By on

Every software team aspires to be faster. Agility and dev speed lead to happier customers, partners, and employees. We at Atlassian are committed to helping teams deliver software at speed, and we’ve made significant investments integrating our products so that it all flows smoothly from concept to launch.

JIRA Software and Bitbucket are two of the most popular developer tools among software teams and many of our customers choose to integrate them. While they swear by the integration, we were curious as to whether there was a measurable improvement to their processes and if so, how. So we asked one of our product analysts to pull the data for us (anonymized and sanitized for your protection, of course).

JIRA Software and Bitbucket teams release 14% more often

We compared the number of released versions completed during the second half of 2015 by JIRA Software teams with the Bitbucket integration vs. teams without it. There was definitely a correlation. We found that software teams released 14% more often on average when JIRA Software is integrated with Bitbucket. The contrast was especially significant for smaller teams (10 users customer tier) who released 25% more often on average vs. larger teams (2000 users customer tier) who released 5% more often.

All their information is in one place…

Why do software teams with JIRA Software and Bitbucket integrated release more often? For starters, they’re using agile and Git in their development process – plus the integrations themselves, which do a lot to enhance that.

JIRA Software and Bitbucket allow you to have all important information in one place so you can stay in the tool of your choice. You can track the health and status of your next release using the release hub. It shows a summary and a breakdown of the issues in the version, grouped by status.

Another important feature, the development panel, gives you visibility into development status within the context of an issue. Lastly, when you’re ready to start work, you can create a feature branch directly from the issue in JIRA Software. JIRA Software will automatically suggest a name for your new branch in Bitbucket based off the issue key so you never get lost in your branches.

…which helps them close 23% more issues

We also compared the number of issues created in the second half of 2015 that were transitioned to a “complete” state during the same time period. We found that on average, JIRA Software customers with the Bitbucket integration closed 23% more issues vs. JIRA Software customers without the Bitbucket integration. Again, the contrast was especially significant for small teams who closed 49% more issues on average with the integration.

Integrate to accelerate

Teams that use JIRA Software and Bitbucket accelerate development by taking advantage of features like workflow triggers to automatically transition issues from one status to another based on actions taken in Bitbucket (creating a branch, merging a pull request, etc.)

Likewise, smart commits in Bitbucket let you update your JIRA issues (add a comment, log time, or transition the issue) by adding special commands to your commit messages. Features like these let you avoid repetitive tasks and focus on coding, thus helping you ship more often.

“JIRA Software and Bitbucket allow us to more easily and reliably create better software for our customers, faster”, said Itay Neeman, Director of Engineering, Splunk.

Get started today

If you still aren’t convinced, why not try it yourself? It will take you less than 30 seconds to connect JIRA Software with Bitbucket. Whether you have both tools, just one, or neither, visit our integration page to get started.

Learn more about JIRA Software and Bitbucket


Did you find this post helpful? Share it on your social network of choice so your fellow software makers can learn from it, too!

Automating quality checks and Docker containers in a Git workflow

By on March 28, 2016

As a marketer for our family of developer tools, I get the chance to talk with developers doing really cool things with code they host on Bitbucket. Recently I had the chance to meet the team over at CloudCannon and discuss how they develop their application.

Similar to other small teams, they’ve faced challenges with setting up a solid continuous delivery model and ensuring the code released is of the highest quality possible. But thanks to the bitHound Bitbucket add-on and their own custom Bitbucket extension, they were able to create a workflow that’s a perfect fit. Here’s how it works – hopefully this will inspire a few ideas for your team’s process.

CloudCannon’s need for speed

CloudCannon makes it possible for non-tech savvy users to update their own websites. Developers build a static or Jekyll site with full control over design, libraries, and frameworks used. Then non-developers log in and update the content inline, with no prior knowledge of development needed.


Like all SaaS companies, they live and die based on their ability to release fixes and features to their customers as frequently as possible. Git’s support for branch-and-merge workflows, plus Bitbucket’s extensibility, plus Docker’s flexibility is their recipe for dev speed (with a dash of automation thrown in).

Node.js, microservices, and bitHound (oh my!)

Their infrastructure, written in Node.js, is entirely composed of microservices. Each repository contains a stable master (trunk) branch, a production branch, and feature branches as needed.

For each new feature, they create feature branches within every microservice repository it touches. To keep track of changes on their feature branches, they implemented a strict commit message convention. Each commit has to indicate the type of change made with “fix, feature, or chore”. For example:

fix(broken sharing ui)
feature(added ssl interface)
chore(fixed mixed whitespace)

These conventions come in handy when it comes time to tell customers about each release. They group commits together based on keyword to create detailed release notes they can publish in their documentation.


Once feature development is complete, they merge those changes back into the stable master branch. At this point in their workflow, CloudCannon needed a way to enforce additional quality checks. After meeting the bitHound team at Atlassian’s very own AtlasCamp event last year, they discovered that bitHound could do just that.

If you’re unfamiliar with bitHound, it’s a continuous code analysis tool for JavaScript that identifies risks and priorities inside the project’s code and dependencies. Using bitHound’s add-on for Bitbucket, CloudCannon could flag and update any packages or JS warnings before they made it into a release. bitHound statistics display right inside the Bitbucket UI on every repository CloudCannon creates.


Using Docker containers for deployments

Once features have passed the package quality check, changes are deployed to their staging environment. How does this happen? I’m glad you asked – this is where things get really interesting.

When CloudCannon set out to build their continuous integration and delivery pipeline, they found it difficult to find a solution that fit their exact requirements. What do you do when you’re an engineer and in need of a tool? You build your own! So CloudCannon did just that, creating their very own continuous integration and delivery tool called Weldr.


Named for its ability to ‘weld’ together Docker containers, Weldr is a node.js application that uses Express.js to create web services for the team to interact with. CloudCannon automatically kicks off builds using Bitbucket’s webhooks with each push to their master branch.

Tying together several bash scripts, Weldr then pulls the latest repository change from Bitbucket, spins up a new Docker image, starts up all necessary services, and finally publishes a log file of how the build went. If all is well in the log file, the developer then runs through a series of scripted manual tests to ensure everything is working as expected.

Currently the team needs to open Weldr to view the results, but they plan to enhance the process by sending build status updates to Bitbucket’s Build Status API. This will show them the status of builds without having to leave the Bitbucket repository.


When a batch of new features and fixes are ready for release, they repeat the process to deploy to production (which happens 2-3 times a week), with one minor change. Instead of automatically triggering production deployments, they decided to make it push-button to avoid any accidental mistakes.

…and so can you

Using Bitbucket’s extensibility, bitHound’s quality control, and their own custom continuous integration CloudCannon is able to deploy to their end-users with zero downtime – a feat they’re rather proud of.

If you’d like to implement pieces of CloudCannon’s process, you can find the bitHound add-on for Bitbucket here. And although Weldr is unique to CloudCannon, you can use just about any continuous integration tool to mimic their process. Many of which, like Bamboo, Wercker, and AWS CodeDeploy, integrate directly with Bitbucket for automatic deployments and build status.


Automation is just the beginning. For more on Git workflows and using Bitbucket for continuous delivery, head over to The Pipeline our continuous delivery hub.



Introducing code search for Bitbucket Server

By on March 24, 2016

How often has this happened to you: you see an error message and you’re not sure which part of the code it came from, or you know the function name but you don’t know what repo contains the code for it. “Ghaah!” Many of you’ve been asking for a way to search through your code in Bitbucket Server, and I’m pleased to tell you that the wait is over.

Today, we’re inviting our customers to take a first look at code search in Bitbucket Server via our early access program (EAP). Now you can search through your code to find exactly what you’re looking for right from the search bar:


How does it work?

We understand that many of your teams have a lot of code. So we’ve made it easy for you to restrict your search results to a specific project or repository using search filters. You can also search for code in a particular language (e.g., lang:java) or with a particular file extension (e.g., ext:css).


Search operators like AND, OR, and NOT can be added to searches to help narrow down or broaden the results. This is useful for further filtering results when you get too many.


How do I get started?
Glad you asked! You can download the Bitbucket Server EAP build with code search here and we’ve created this step by step guide to get you started. If you do try it out, let us know how it goes – your feedback is extremely valuable to us. Filling out this short and simple survey will help us make code search installation better for you and your fellow Bitbucketeers when it is officially released.

We look forward to bringing you more soon. Happy searching!

Download code search EAP now

New improvements for Bitbucket Cloud Projects

By on February 24, 2016

A few weeks ago, we introduced the concept of projects in Bitbucket Cloud based on requests from many of you. This is a unique feature of Bitbucket and has already proven helpful for teams who need a way to organize their repositories – especially teams in larger organizations managing hundreds (or thousands) of repositories. We’re constantly striving to innovate and add valuable features to Bitbucket Cloud, and we wanted to let you know about several improvements to Bitbucket projects already in the works:

Why should you use Projects?
As organizations grow, team sizes get bigger, and more and more repositories get added. It gets progressively harder to find the repository you’re looking for. Projects make it easier for your team to organize repositories and be more productive with Bitbucket Cloud. Some of the main use cases we’ve seen so far include:

Dashboard sorting preview
We’ll be continuously iterating on projects in Bitbucket Cloud, and we’re shipping some changes to our dashboard today. We’re introducing the last updated column as requested by many customers over the last month which, in combination with our updated filter bar, will make it easier than ever to stay on top of your team’s work and find the repositories that you’re most interested in. To accommodate these changes, we’ve removed the “Recently viewed” table, however those repositories are still only a click away in the repositories menu.

Here’s a preview of the new dashboard:


What’s next?
We’re committed to helping your teams deliver software at speed, so please keep the feedback coming! Projects are already making a big impact on the way teams organize and manage their repositories with Bitbucket and we’re looking forward to continuing to iterate on the experience based on everything we’ve heard so far. For further discussion, we will be available on this Reddit thread to answer any more questions you might have around Bitbucket projects.

Happy coding!

What designers, game developers and architects need to know about Git LFS

By on February 19, 2016

<This is a cross-post from Atlassian Blogs>

Atlassian is dedicated to unleashing the potential in software teams. We want to help you work smarter and faster. This is the reason we keep adding new features to Bitbucket  – branch permissions, merge checks, smart commits, smart mirroring and many more.

Last year, we were working on solving another big problem for our users: tracking large files in a Git repository. Git large file support (LFS) provides the ability to store really big files where they’re needed, not just where they fit. We want to make Git right for everyone and that’s why we decided to collaborate with GitHub on building a standard for large file support.

Why Git LFS?
It’s a known issue that Git doesn’t play nicely with large files, and it’s not just developers who struggle with large files and version control. Native Git’s limitations make it challenging for team members like designers, tech writes, sys admins, and build engineers to work closely with developers.

They often need to store their assets in stand-alone systems or cloud storage providers because of Git’s historic inability to track version history for large assets (schematics, graphics, or other media files). Co-locating non-code assets with the code itself means the large assets can be updated quickly, easily versioned, and become a natural part of the deployment pipeline. As a design team incorporates feedback on their interface assets, iconography, and images, they can deploy those changes in a fully-built version of the product and see the results.

Git LFS also allows people like designers to version the assets they share with their team, just like all the other assets in a repository. This means developers can find the latest revision of an asset they need to use without needing to track down the right version of a file or interpreting what “menubar_v2_final_v3_final_final.psd” means. (Sounds almost too good to be true, doesn’t it?)


For mobile software teams and game development teams, Git LFS relieves the pain of working with the ever-larger image, texture, and video assets that cater to the ever-improving resolution on mobile devices. It also means tests and builds don’t need to rely on an external step to succeed. And if you’re building a video- or audio-intensive app, you can keep those stored in Git LFS too.

Git LFS in Bitbucket
Naturally, we want to do everything we can to make Git more accessible to all team members. And that’s reflected in the changes we’re making to Bitbucket, our Git repository manager, available as a cloud service or on-premises server. Any software team using Git LFS can now view every version of project assets through the Bitbucket interface and in select media types we’re now making it easy to compare the latest version updated with our visual diff tools.


Bitbucket Server implemented Git LFS in v4.3, and we’ll be releasing support for LFS in SourceTree (our desktop client for working with Git) soon. We’ve also made it really easy to use LFS in Bitbucket Server so you can get started quickly. But Atlassian’s LFS journey is far from complete. We’re bringing LFS to Bitbucket Cloud soon.

Git for everyone!
We’ll continue collaborating with GitHub on the LFS protocol to extend the capabilities of Git for all software teams using features like file locking to prevent change conflicts, better handling of vector and layered files, and more. In Bitbucket, we’re making it easier to work with media files and our design teams are helping us bring a great UI experience to every member of your software team like designers, tech writers, marketing, etc. – even if they don’t write code.

If you haven’t used Git yet, check out our collection of Git tutorials and articles. Or if you’re ready to get started, signup for a Bitbucket Server account. If you’re already using Bitbucket Server,enable Git LFS for your team and let us know what we can do better.