By Alastair Wilkes on June 12, 2018
Imagine this scenario: your code’s ready to go, your teammates have approved your pull request, and the builds are green. Now you just need to merge your feature branch into master, but you have a choice to make: which merge strategy should I use?
Natively, Git offers several merge strategies. In Pull Request Merge Strategies: The Great Debate, fellow Atlassian Nicola Paoluicci presents the merge strategies that are most popular amongst teams, along with the pros and cons of each option.
As Nicola’s post mentioned, teams at Atlassian lean towards using explicit merge commits:
Bitbucket already supports squash on merge, which results containing your merged changes. The result? A tidy list of commits – one for each merge:
, squashed merges can be undesirable in some cases: you may want to maintain a linear commit history without squashing to a single commit. For example, if your feature includes an API change and a front-end change, you might prefer to keep those changes as separate commits – but you still want a linear history without merge commits.
Fast forward merge strategy
To use the new fast forward option the next time you merge, select it as your desired Merge strategy in the merge dialog:
Default merge strategy repository setting
As a matter of team policy, some teams would prefer to always use the same strategy. To make this easier, we’ve introduced a default merge strategy repository setting.
This setting determines which merge strategy should pre-populate by default when your team members merge a pull request in Bitbucket. From your repository Settings, you can find this option on the Merge strategies page under Workflow.
We hope you enjoy! If you have any feedback to share regarding this feature, tweet us @Bitbucket. Happy merging!
Try Bitbucket Cloud
By Claire Maynard on June 4, 2018
After the announcement of Microsoft’s acquisition of GitHub, Bitbucket started to see a spike in the number of GitHub users migrating their repositories to Bitbucket. Why? Many users understand they can get everything they had on GitHub in Bitbucket plus more, and at a lower cost. Tens of thousands of customers – including 60 of Fortune 100 – turn to Bitbucket as their code collaboration solution.
Start migrating from GitHub to Bitbucket
10 reasons why teams are moving from GitHub to Bitbucket Cloud
Teams can save 4x the cost moving from GitHub to Bitbucket. For example, if you are a team of 10 on GitHub, you have to pay $205 a month, while on Bitbucket you’re only paying $50. Bitbucket also offers free public and private repositories for teams with less than 5 users. GitHub doesn’t offer a free plan for users who want private repositories. On GitHub, even an individual developer has to pay $7 a month.
2. Superior integration with Jira
It’s been known for a long time that one of the best benefits of using Bitbucket is it’s best-in-class integration with Jira – the worlds number 1 agile software development tool for teams.
GitHub has an integration too, but check out all the things you can do with Bitbucket and Jira that you can’t do with GitHub:
- Create branches directly from Jira issues and start coding quickly. Nope, you can’t do that with GitHub.
- Interact with Jira issues without leaving Bitbucket. View, edit, comment or transition Jira issues inside Bitbucket’s UI. You can even add attachments to issues from Bitbucket. Nope, GitHub can’t do that either.
- Automatically connect commits, branches, and pull requests to Jira issues by adding the Jira issue key in the commit message. You can even require Jira issue keys in your commits so all of your work stays organized.
- Connecting Bitbucket and Jira only takes 30 seconds.
3. Built-in Continuous Integration and Delivery
On Bitbucket, you get a built in CI/CD solution that is unified with your source code. There are no CI servers to set up, user management to configure or repositories to synchronize. Just enable it within the UI and you’re done. What about with GitHub? Nope. GitHub doesn’t have a CI/CD solution. You have to go through the headache of finding, installing, configuring a new tool, setting up all your users over again, and you don’t benefit from the end-to-end visibility because all your CI information lives in a separate tool.
4. Bitbucket comes with Trello
This means the moment you set up a Bitbucket account, you get a Trello board – the fastest, easiest way to organize your projects, connect your work to code, and ship software, all for free.
5. SOC 2 Type II Compliance
With SOC 2 Type II compliance for both Jira Software and Bitbucket, the availability and security of your code is guaranteed. All the benefits of working in the cloud is now matched with an industry-first level of security, confidentiality, and availability for both your work and your code. Nah, GitHub is not SOC 2 Type II compliant.
6. Seamless integrations within the UI
Bitbucket Connect allows any developer to build deep integrations within the product UI in Bitbucket Cloud. You can stay within one tool to build and ship your software meaning no more context-switching between tools and tasks to get stuff done.
7. Code aware search
Semantic search that does the grunt work for you. Code aware search analyzes your code syntax, ensuring definitions matching your search term are prioritized over usages and variable names. With GitHub, you don’t get smart sorting and could spend hours finding what you need.
8. Mercurial Support
Bitbucket Cloud has Mercurial support. Mercurial is a free, distributed source control management system like Git. Have the freedom of choice and use the distributed version control system that works for you. GitHub? Nope.
9. Great for Open source projects too
Think GitHub is the answer for open source projects? Did you know Bitbucket also offers free public repos as well and hosts several large open source projects?
10. Using Slack?
With the Bitbucket bot for Slack, teams can take action from their channel – merge, comment, and even nudge reviewers on pull requests. With the Bitbucket Stride integration, you can “poke” people reviewing your PR as well. Nah, GitHub doesn’t have that either.
Are you self-hosting? Here are six reasons teams choose Bitbucket Server:
Our enterprise offering, Bitbucket Data Center, is 4x less expensive than GitHub Enterprise. For an engineering organization of 100 on GitHub Enterprise, you’ll pay $25,000 for a year. Bitbucket Data Center costs a fraction at $6000.
2. Native integration with Jira
It’s been known for a long time that one of the best benefits of using Bitbucket is it’s best-in-class integration with Jira – the worlds number 1 agile software development tool for teams. GitHub has an integration too, but check out all the things you can do with Bitbucket and Jira that you can’t do with GitHub:
- Create branches directly from a Jira issue and start coding quickly. Nope, you can’t do that with GitHub.
- Interact with Jira issues without leaving Bitbucket. View, create, comment or transition Jira issues inside Bitbucket’s UI. You can’t do that with GitHub either.
- Automatically connect commits, branches, and pull requests to Jira issues by adding the Jira issue key in the commit message. You can even require Jira issue keys in your commits so nothing get’s lost. Then, use Jira query language to find important development details – for example, search for all Jira issues with the status of “commit”.
- Best part of all, connecting Bitbucket and Jira only takes 30 seconds.
3. Bitbucket has better mirroring
GitHub Enterprise finally added mirroring Git repositories across different geographic locations, but can it keep up with Bitbucket Data Center? Select which projects are mirrored in a geographic location and Bitbucket will automatically sync and inherit user permissions. GitHub mirrors every repository, creating a bottleneck when pushing changes out.
4. Customizable pull request workflows
Bitbucket allows you to choose between five different merge strategies, create (and require) custom merge conditions, and configure default reviewers. GitHub expects you to use GitHub flow and be happy about it.
5. Superior extensibility
The Atlassian Marketplace houses over 200 Bitbucket Server compatible apps and more than 140 for Bitbucket Data Center. GitHub has 50. Not only do we offer more apps, but you also get access to the self-hosted Bitbucket’s source code. You’ll have to keep your GitHub representative on speed-dial for similar access.
6. Turnkey active-active clustering
We believe Git should scale with you. Easily add nodes to your Bitbucket Data Center cluster as your team grows. GitHub would rather you call them first before you can have an active-active cluster.
Start migrating from GitHub to Bitbucket
Move your team to Bitbucket Server
By Kelvin Yap on
Developer efficiency is always top mind for the Bitbucket team and we’re constantly looking at ways to get you up and coding as quickly as possible. For example, knowing so many of you use Sourcetree as your Git client of choice meant it was a no-brainer for us to add a ‘Clone in Sourcetree’ button as you browse through your repositories inside the product.
We’ve been looking at ways to expand this type of functionality and today we’re excited to announce support for Xcode. It’s simpler than ever to open the code found in Bitbucket Cloud or Bitbucket Server in Xcode – as long as your repository contains a .xcodeproj or .xcworkspace file a new ‘Clone in Xcode’ button will now appear.
And it’s easy to get the button working with the newly announced Xcode 10 – simply add your Bitbucket Cloud or Bitbucket Server credentials in Xcode and away you go:
Once set up, clicking on the “Clone in Xcode” button will launch Xcode and prompt you for a location on your local machine to clone the repository to.
Give the new integration a try and let us know what you think!
Try Bitbucket free
Using Bitbucket Server? This integration is available from 5.11 onwards. For those using versions 4.0 – 5.10, you can install it via Atlassian Marketplace.
By Jim Redmond on May 31, 2018
As part of our never-ending quest to secure your repositories, Bitbucket Cloud will be disabling support for TLSv1 and TLSv1.1 effective 1 December 2018.
This will affect all HTTPS traffic to Bitbucket, including:
- Git or Mercurial traffic to bitbucket.org
- The bitbucket.org Web interface
- API calls to api.bitbucket.org
- Hosted sites on bitbucket.io
- Any other HTTPS traffic not listed here
SSH traffic to bitbucket.org or altssh.bitbucket.org will not be affected by this change.
About 85% of HTTPS requests to Bitbucket use the newest version of TLS (v1.2). This includes all recent versions of our supported browsers, and most recent versions of Git and Mercurial clients. However, that other 15% includes a number of remote CI/CD systems (such as Bamboo or Jenkins), issue trackers (such as Jira Server instances), wikis (such as Confluence Server instances), and older versions of Git/Hg clients; all of those use older versions of Java, OpenSSL, or Python’s ssl module when negotiating the secured connection to Bitbucket, and all of those will be unable to connect to Bitbucket at all once we disable old versions of TLS.
Payment processing pages have already moved from TLSv1, to comply with PCI requirements.
How can I tell if I will be affected by this change?
We’ll be contacting some teams and users directly, based on what we find in our logs. If you’d like to be proactive, though, then be sure to check all of the things that you use to connect to Bitbucket, including (but not limited to) your browser, your Git or Mercurial client, your CI/CD system, any API clients, and anything else you may have linked to Bitbucket.
- SSH connections to Bitbucket are unaffected.
- Browser connections to Bitbucket are probably unaffected, unless you use a very old browser. Wikipedia has a chart detailing TLS support in Web browsers; you should be able to check your browser’s version there. Some browsers also make connection details visible in the developer tools, or by clicking the padlock icon in the address bar.
- Bamboo, Jenkins, Jira Server, Confluence Server, or any other Java-based systems that connect to Bitbucket may be affected; you will need to check the underlying version of Java. JDK 8 is unaffected; JDK 7 versions 1.7.0_131-b31 and later are unaffected; JDK 7 versions earlier than 1.7.0_131-b31 are affected; and JDK 6 and older are all affected. (Jira Cloud and Confluence Cloud are unaffected.)
- Graphical Git or Mercurial clients, such as Sourcetree, may be affected; please check with your vendor. (If you use Sourcetree for Windows 2.5.5 or later, or Sourcetree for Mac 2.7.2 or later, then the embedded Git and Mercurial clients are unaffected. If you use a system Git or Mercurial client with Sourcetree, then you might be affected; please make sure you’re on the latest client version available for your platform.)
- The Git command line on UNIX-based systems (including macOS, Linux, and all BSDs) may be affected. You should be able to test your connection from the command line:
GIT_CURL_VERBOSE=1 git ls-remote https://bitbucket.org/
This will connect to Bitbucket using the Git client and list the connection parameters. If you see a line like “SSL connection using TLSv1.2” in the output, then you are unaffected; if that line mentions a different version of TLS, then you are affected.
- The Mercurial command line on UNIX-based systems may be affected; please check your version of Python (with “python -V”). Versions 2.7.9 and later are unaffected, and most versions earlier than 2.7.9 are affected. Affected systems may also see some text in the command-line output – “warning: connecting to bitbucket.org using legacy security technology (TLS 1.0)” – though this will only show for newer versions of Mercurial. (Please note that PyPI and all other python.org sites will enforce TLSv1.2 after 30 June 2018, so you may not be able to upgrade individual Python libraries after that.)
- Finally, if you have an API client that queries Bitbucket, then please check the libraries your client uses to connect to api.bitbucket.org.
I’ve found an affected library or client, or you’ve contacted me to tell me that I will be affected by this change. What do I need to do?
Upgrade anything that is affected, before 1 December 2018. The exact details of your upgrade will depend on what you use, and how it’s installed; we don’t have enough room here to list all the different combinations, unfortunately, but we hope that the “will I be affected” section can point you in the right direction. (We’ll remind everyone as December approaches, but if your stuff is affected then you need to start planning this out now.)
We understand that system upgrades can be complicated, especially on shared systems, but keeping your repositories secure is a priority for us. We appreciate your support and patience as we disable old, insecure versions of TLS in six months’ time.
As always, please contact our support team if you need additional information.
By Matt Ryall on May 29, 2018
In the Bitbucket team, we believe containerization is the future of continuous integration and deployment. Running your software in containers brings consistency and predictability all the way from your development environment, through your CI/CD pipeline out to production.
To help smooth the path for container-based development, I wanted to reflect back on a set of improvements we’ve made to Docker support in Pipelines over the past few months, which bring speed and new capabilities to your build process. With these improvements, Bitbucket Pipelines is now the leading choice for building and shipping Docker-enabled applications in the cloud.
is Docker all the way
Docker applications will feel at home on Bitbucket Pipelines because everything in Pipelines is built on Docker:
- Your build environment is a Docker image. No pre-baked VMs with slow startup and six-month-old dependencies. As soon as a new release of your favorite platform hits Docker Hub, you can use it in Pipelines.
- The services your build uses (databases, etc) are just Docker images. They share a network interface with your build container, so you don’t even need to worry about port mapping.
- Built-in support for , tag and push. Just enable it in your build, and we’ll run a Docker-in-Docker daemon and provide the docker command-line tool so it works out of the box.
Here’s a showing how this all fits together:
But this is just the beginning with Pipelines. From this solid foundation, we’ve been able to layer on some great features that will make your Docker builds even faster and more powerful.
Lightning fast builds thanks to comprehensive Docker caching
“My build is too fast”, said no developer, ever. We’ve built several levels of caching into Pipelines for Docker users, so your Docker builds can run as fast in the as they do locally:
- Image caching will automatically apply to all public Docker Hub images used in your build.
- Layer caching will include all images and intermediate layers used by the Docker-in-Docker daemon that powers your Docker builds on Pipelines. Enable this by adding the docker cache to your Pipelines steps, as shown below.
- Custom caches can be defined in your Pipelines configuration, allowing you to cache the things that we miss. (These are flexible enough that we actually implemented layer caching in this way.)
Among customers who have enabled Docker layer caching, we’ve seen 80% of repositories shave off more than 30% of their uncached build time – and almost half (49%) have cut more than 50% off their uncached build time. These dramatic reductions will save real time in your team’s daily feedback loop.
Docker builds up to 7GB with configurable memory limits
With two improvements that enable bigger and more complex builds, you can now use up to 7GB for building and running Docker containers in Pipelines:
- Large builds support allows you to allocate a total of 8GB of memory to your build (up from 4GB). Double memory costs you double the build minutes, so we recommend using it only where you need it.
- Configurable memory for services allows you to specify how you want to this memory allocated. We require 1 GB for your build image and our overheads, so the 7GB remainder can be allocated to service containers or to your own Docker containers.
Here’s an example of configuring 7GB for Docker operations in bitbucket-pipelines.yml:
size: 2x # double memory (8GB) for this step
- ... # do some memory-intensive docker stuff
This additional memory might make you wonder why you wouldn’t just spin up your entire application in Pipelines for some delicious integration testing. Which leads us on to…
Spin up your entire application with
If you’re using Docker heavily, you probably have a bunch of docker-compose YAML files to kick off your application in a variety of configurations. With the Docker-in-Docker daemon in Pipelines, you can now use docker-compospin up your entire application for testing.
Below is an example of using docker-compose with a 7GB memory allocation to spin up a set of services and test them out.
Note that this example has a few extra commands to install the mysql client and docker-compose binaries that aren’t necessary in a real build scenario, where you would bake your dependencies into a custom Docker image for your build environment.
size: 2x # double memory (8GB) for this step
- apt-get update -y && apt-get install -y mysql-client
- curl -L https://github.com/docker/compose/releases/download/1.19.0/docker-compose-Linux-x86_64 -o /usr/local/bin/docker-compose
- chmod +x /usr/local/bin/docker-compose
- docker-compose up -d
- docker-compose ps
- ./wait-for-container.sh build_mysql_1
- echo 'select 1' |
mysql -h 127.0.0.1 -u root -psecret testdb
- docker-compose logs mysql
This example uses this docker-compose.yml, and wait-for-container.sh – a small shell script to poll the Docker health check and wait for a container to start.
If you want a better look at how this docker-compose example fits together, check out the docker branch in my demo repository.
Try Bitbucket for your next Docker-powered project
If your team is big into Docker, you now have a list of great reasons to try out Bitbucket for your next project.
Try Bitbucket today, and enjoy the benefits of a CI/CD solution purpose-built for Docker.
Try Bitbucket free
By Aneita Yang on May 15, 2018
Last month, we announced the general availability of Bitbucket Deployments, a new feature within Bitbucket to help you keep track of the status of your shared deployment environments. With Deployments in Bitbucket, your team has every capability they need, from code hosting, code review, built-in CI/CD and now deployment tracking, to build and ship great products from within Bitbucket.
But there’s still a lot of uncovered potential for Deployments. Imagine, for example, that you push some code which triggers a pipeline that deploys to production. Halfway through, your colleague pushes more changes that also trigger a deployment – two deployments are now running!
. This gives teams confidence about the status of their environment and eliminates any uncertainty about whether deployments are running in the right order. We’ve listened to your feedback and realise how important it is for Bitbucket to just do the right thing.
we’re excited to announce that Bitbucket Deployments is the first CI/CD to automatically enforce Simply by adding deployment tracking to your pipeline, we will automatically ensure that only one deployment is in
“This is amazing! There’s nothing more frustrating than a 35min build failing because the environment is still updating”
– Ken Greeff, Software Engineer at Realhub Systems
How does the concurrency control work?
Deployment concurrency control requires you to first enable Bitbucket Deployments for your repository. With deployment tracking enabled, Pipelines will then check whether there is already a deployment in progress before starting a new one to the same environment. If there is already a deployment in progress, later deployment steps will be paused. You can manually d.
– by letting the in-progress deployment to finish executing before allowing a later deployment to be run, the status of your environment will always be known and your deployment won’t fail due to unavailable resources. Keep in mind that Bitbucket Deployments tracks the status of shared environments in the repository, and that developer’s individual test environments don’t need to be tracked.
We’re super excited to share this addition to Bitbucket with you. If you have any feedback to share, tweet us @Bitbucket. Happy deploying!
By Martin on May 10, 2018
code aware search: a semantic search that ranks results by relevance, starting with the function or type definition first. It was built this way to save time manually combing through results when looking for things like classes, interfaces, structs or enums. We’ve continued to expand it by adding a code search API so developers can make code search work for their unique needs.
Since launch, code collaborators could efficiently find the code they were searching for, but results for a file search would show usages of the filename in the code and not the actual filename. This caused a lot of effort to find the file. To fix this, we’ve launched improved file search support which now includes filename matches, extending the syntax-aware code search.
What’s new with file searches?
#1 Search results take into account filenames and paths
Files can now be found just by searching their filename or parts of the path.
If a search matches both in a file’s path and content, those results are shown first. We aim to match the developer’s search intent with smart ranking by boosting search results based on matches in the file’s name, path or code.
#2 A path modifier to refine results
A developer searching for a common phrase or name would get served overwhelming results that they would have to click through page after page to find the right result. To make this easier, a developer can now enter the path modifier, which can be used to limit the search to certain paths or exclude them.
A lot of people will have checked in node_modules and so it’s a very common match. The new path modifier supports a NOT option so the search could be updated to path:package.json -path:node_modules lodash to exclude those matches.
Bonus: A similar filter can be achieved using path anchoring, searching with path:/package.json lodash will only return results for package.json files at the root of the repository.
Try Bitbucket Cloud’s file search
If you’re ready to give our robust and relevant search a try, sign up for a Bitbucket Cloud account, create a repository, and .
If you’re already a Bitbucket customer, you can find code search with improved file search from your sidebar read further documentation on it here.
By anoland on May 3, 2018
Does it ever feel like the codebase you work in (or its core dependencies) can change in the blink of an eye? As soon as you’ve moved to the latest version, a new stable release comes out. It’s even more frustrating when it happens inside your company. Sure, it might come up during daily standup… but that doesn’t always capture the downstream impact.
Now, you can watch repositories to get an email update with the latest commits or pull request updates. We’ve even Read on to learn more, or get started with Bitbucket Server 5.10 now.
Download Bitbucket Server 5.10
Staying up-to-date with repositories
Staying on top of the latest changes across multiple repositories can be harrowing for the most seasoned developers. Monolith apps can get hundreds of pull requests in a week, and a team across the globe might make a change to a shared dependency. There has to be a better way for developers and managers to get the latest updates without having to dig through pages of pull requests or commits, right?
With the new watch repository functionality, you can receive email notifications for the repos you’re interested in (and only for those). Most developers are familiar with variations of this feature, but we wanted to offer refined control for the types of email updates you might receive.
Bitbucket Server’s watch emails can be customized to include commits to the default branch only, or all branches as well as pull request state changes, or all pull request activity. These updates can either be batched or sent immediately. Each option helps developers optimize for different goals. Batched emails reduce your inbox clutter, while immediate email updates make sure you know what’s going on as soon as it happens.
A new look for Bitbucket Server
We launched our bold new brand this past September and today we’re introducing a fresh look for Bitbucket Server and Data Center. You may have already encountered it in Confluence server. It is the same Bitbucket workflow you know with . Our new look is based on the Atlassian design language and includes updated colors, typography and icons.
Download Bitbucket Server 5.10
Improving developer productivity is near and dear to us at Atlassian – especially since we dogfood all our products. Our devs are loving how Bitbucket Server 5.10 surfaces repository updates in a more intuitive fashion so they never miss a beat, and we hope you’ll love it too.
Btw, if you want to add a little fun to your code review, we’ve also added (🦄)! Because y’know… unicorns.
Interested in the details of our latest release? Read more in our release notes.
By anoland on
Bitbucket Server is the convergence of individual work and team collaboration. Administrators ensure the git server availability, enabling developers to complete deployment cycles. Those teams operate independently but share common goals like, automating and simplifying repetitive tasks.
In Bitbucket Server 5.9, there are improvements for both admins and developers. Bitbucket admins can identify and track causes of degradation, like third-party or custom apps, with a new diagnostics tool and UI. Pull requests and code searches reflect developers’ workflow expectations and offer greater continuity when moving between the command line and Bitbucket Server. Now, you can search commits or edit commit messages when merging. Keep reading to learn more or get started with Bitbucket Server 5.9 now.
Download Bitbucket Server 5.9
Understanding Bitbucket performance
It’s 11pm and you get a Pagerduty alert. Your stomach drops in anticipation of major performance degradation or outright system failure. For Bitbucket Server administrators, we never want to be the source of your on-call nightmares. Performance degradation of a git server can impact hours of productivity or an important release, but issues caused by third-party apps frustrate even the most patient admin.
With Bitbucket Server 5.9, we’ve surfaced within Bitbucket UI. Admins can get an overview of Bitbucket system health with a summary of alerts & events for the last 30 days. Diagnostics lists events of different severities: an error, a warning, or simply worth noting. Using this new information, admins can proactively address issues which may lead to more serious problems or tackle system errors before users begin to report them.
Diagnostics also supports event filtering by node, date, or time. For persistent issues or on-going anti-patterns, this provides a level of traceability so admins aren’t stuck searching HipChat to create a timeline or identify a problematic node.
Scaling and improving search
But beneath each code or repository query lies Elasticsearch. With the bundled instance for server and clusters for data center, Elasticsearch is critical to developer productivity, but its performance is an admin responsibility. As of Bitbucket Server 5.7, we’ve added support for Elasticsearch 5.5, allowing admins to upgrade from .
Pull request enhancements
Bitbucket Server is home and hearth to pull requests and git workflows. We should know since we wrote the handbook. To make your software development team’s workflow more effective:
- commit messages can be edited on merge
- dependent pull requests can retarget your default development branch
- Jira issue details expand as a new default
What used to take clever workarounds is now a click away.
Download Bitbucket Server 5.9
Empowering administrators’ and developers’ common tasks in Bitbucket Server help software and IT teams gain the stability and performance needed to grow. Want to dive into the details of our latest release? Read more in our release notes.
By Peter Williams on May 2, 2018
As part of our ongoing efforts to improve Bitbucket Cloud for users we’re always looking at ways to help you code smarter and ship faster. With this in mind we’re proud to unveil our latest improvement, a new source browser experience designed to ensure browsing and viewing source code is more effortless and consistent in the product than ever before.
And while clarity and simplicity were at the heart of the new design, we focused on increasing performance to ensure a fast, efficient browsing and viewing experience. Let’s take a look at some of the improvements.
The new source browser experience
The repository navigation will no longer lead with the Overview; instead key components of the Overview were combined with the Source browser in order to place focus on primary user actions. No longer will you have to toggle between multiple views in order to view your README and source files.
New right sidebar
We’ve supercharged the directory listing for the files in your repository. Navigating between directories and files happens entirely on the client, so the experience should feel much snappier as a whole. “Last modified” information now links directly to the corresponding commit and, even more exciting, we now include information about the most recent commits for both files and entire directories. That large block of whitespace that was once at the top of your repository’s root directory list is now full of useful information.
Single Page Application
The new source browser now operates as a single page app which creates a more responsive browsing experience. Whether you’re navigating to a new file or directory, or switching between the various source, diff or commit history views, you’ll notice that the transitions are faster and snappier than ever.
We’re excited to release this new and improved experience in the wild and into your hands. It’s a taste of things to come as we continue to add more wonderful features to the new browser!
Try Bitbucket free