Our goal with SourceTree is to move towards a cleaner, simpler interface for developers new to Git while keeping all the powerful features advanced users love. The last release was a step in that direction. We’re excited to share with you our future plans, but first let’s take a step back and look at how far we’ve come:

SourceTree in 2012

SourceTree in 2015

We’ve made huge strides in improving usability and UI consistency throughout SourceTree, but we’re just scratching the surface.

Addressing approachability and “interface bloat”
There’s no doubt that Git has a steep learning curve. SourceTree has always helped by offering an excellent visual counterpart to the command line interface. We don’t “dumb down” Git, but we believe we could do a better job of making SourceTree more approachable for new users.

Many SourceTree users asked us to tackle SourceTree’s “interface bloat”. One way we tackled this problem was with data. By thoroughly looking at the click data, we found a set of buttons that were rarely used in the toolbar. We surveyed roughly 180,000 unique users and found that the “Reset”, “Add”, “Remove”, “Add Remove”, and “Git Flow” buttons, each individually, were used by less than 5% of those surveyed. So we created some new mockups without these buttons in the UI and tested these mockups with our existing users for over six weeks. They loved it!

Don’t worry, we did not remove any functionality, all of those options are still accessible via right click and the “Repository” and “Actions” menus.

Modern design across two platforms
We’re trying to make SourceTree for Windows as beautiful as the OS X App, and we finally approached a point of convergence. Windows users – we promise that a bright future is ahead. Here is a sneak peek:

Want to see more? Grab some time on our calendar and give us 1:1 feedback. Looking forward to speaking with you soon!

We’re thrilled to launch a new beta release process for our upcoming SourceTree releases. This will give you an opportunity to engage directly with the SourceTree team and provide feedback on future updates. If you’re interested in becoming a trusted tester and would like to get early releases from SourceTree, join this google group. We’re still hammering out the program’s last few details, and will share updates here soon.

We look forward to working with you. Thank you for your support!

Last week we announced a new beta program for SourceTree, and I want to thank everyone who signed up to be a trusted tester. We received a lot of interest and are in the process of building a few new features and improvements for you to try out. For those who haven’t signed up yet, don’t wait too long. We’re still accepting trusted testers, get in now by signing up here.

In the coming weeks, we’ll release our first SourceTree Beta and want to give you a look behind the curtains at the testing process, both internal and external, so you can see how the beta program will work.

Step 1: Alpha

SourceTree Alpha is where we turn your feedback in to features that we test internally. SourceTree Alpha will not be available for public download. However, in one off cases, we will reach out to a few trusted testers for early feedback.

Step 2: Blitz!

1 Mississippi, 2 Mississippi, …, BLITZ!!! 

Once we determine a set of improvements that are ready for a public release, we will build a beta candidate. The beta candidate will go through intensive acceptance testing with our QA team- essentially making the beta candidate feel like a college quarterback on their first day against the top-ranked NLF defense.

Step 3: Beta

All systems go! When the beta candidate passes internal acceptance testing, it’s ready for our beta community to give it a spin. Initially, the SourceTree Beta will be available for download from our public repository and will not replace your production copy. Your version of SourceTree and the SourceTree Beta will be able to run side by side, and each instance will offer updates independent of each other. Beta releases will have features in early preview that may have stability or performance issues so they will be kept separate from production.

The best part of the beta program is the feedback loop. To make feedback reporting seamless for the trusted testers, we’ve implemented Fabric and BugSplat (tools that make crash reporting easy) in SourceTree for OS X and Windows respectively. Another option is to report any issues with the label “trusted_tester” via our Trusted Tester Issue Tracker.

Step 4: Early Access

Once we’ve confirmed there aren’t any show stoppers reported by our trusted testers, the most current version of the SourceTree Beta (Early Access build) will be made available for public download via www.sourcetreeapp.com or https://www.atlassian.com/software/sourcetree/overview, rather than prompting users with an in-app update. To get notified about Early Access builds, follow us on Twitter. Please note that Early Access versions of SourceTree are considered production ready and will replace your existing copy of SourceTree.

Step 5: General Availability

The final stretch! We will take this last week to make sure nothing falls through the cracks before we prompt you with in-app updates. Assuming all systems are pointing to ‘go’, roughly one week after being made available for early access, the last Early Access version of SourceTree will be made the official production version.

Sign up to become a trusted tester in the SourceTree Beta

Now that you know the process, we would love you to be a part of it. Our never-ending goal is to make SourceTree the best Git and Mercurial client out there, and we’re only at our best with your contributions and your feedback. So, if you haven’t already, sign up to become a trusted tester today and keep an eye out for the newest updates from SourceTree.

SourceTree Beta 1 is here! Over the past couple of weeks, we’ve announced a beta program and given you a look behind the curtains. The wait is over. Today, those of you who’ve signed up to be a trusted tester will get access to SourceTree Beta 1. In our first beta we’ve addressed:

• Several bug fixes
• Updated icons to include color and increased contrast
• Force Push on Windows
• Improved reliability and localizations on OS X
• Commit Templates with markdown on OS X
• Crash reporting via Bugsplat and Fabric

Haven’t signed up to be a tester yet? There’s still time! Register today and get access to new features before they’re made generally available. Thanks for being part of the SourceTree team.

A couple weeks ago we shared our beta development process. And If you’ve joined our beta program, you must be thinking, “when is SourceTree going to get to step 4: Early Access?” To elaborate a bit, an Early Access build is a production-ready build which has been tested by you, our Trusted Testers. We want to give you a heads up that SourceTree 2.2.5 for OS X and 1.9.1.1 for Windows will be available for download at www.sourcetreeapp.com in the coming days. Here are a few things to look out for in the update. The following will be available in OS X first, with Windows soon to follow later.

• Embedded Mercurial 3.7.3 – In addition to addressing security fixes from Mercurial, we’ve done some Hg housekeeping:  
  • Attic removed – While working on this upgrade we found that hg-attic, the Mercurial extension SourceTree used for shelving changes, was no longer compatible. SourceTree has now migrated to Mercurial’s built-in shelving implementation. Unfortunately, the two formats are incompatible and this means hg-attic and its contents are no longer supported in SourceTree. However, existing hg-attic shelves are not lost and are listed on the side bar under a new heading “SHELVED BY HG-ATTIC”. They are treated as standard patches with limited functionality to view, import or delete. We recommend applying any hg-attic shelves you have in your repos as soon as possible or convert to the new format by importing and creating a new shelve.
  • No support for hgattic extension – From the next release onwards, v2.2.5 on OS X and v.1.9.2 on Windows, SourceTree will not support hgattic extension and recommend versions of Mercurial 3.7.3 or higher .
• Embedded Git 2.8.1 on OS X build – Many of you might have seen errors which include the path “Users/mbasaralusrinivasa/workspace/git-scm/git-274/…”. Well, this is the path at which we installed Git 2.7.4 and was bundled with SourceTree 2.2.4. We had to address the Git security issues quickly and since an officially maintained build of Git was not available at the time, we built it ourselves. We later realized that there were some binaries that referenced the local install path which was visible in some error logs. To fix this, we bundled the (now) official Git 2.8.1 binaries.

If you notice any issues or bugs in the Early Access build, please feel free to file them at jira.atlassian.com. And if you haven’t already, please join our beta program to get access to a ton of features before they are made generally available.

Dear Readers,

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

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

Customer support

For any technical issues, please visit our support center.

Feature requests and bug reporting

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

Atlassian Answers

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

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

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

When it comes to rolling out new software updates, the SourceTree team is always looking to deliver a better experience to users with minimal disruption. In the past we announced a beta program for SourceTree, detailed how we deliver releases, and now we’re modifying how we roll updates out to users. By progressively rolling out updates we aim to deliver new features and functionality to users in a more robust fashion.

What’s the plan?

Where we used to roll a new update to all users on day one, we’re now progressively rolling out updates to users. This staged approach offers the SourceTree team granularity during a release, allowing us to scrutinize each update for bugs and showstoppers before it hits critical mass.

The general flow of a build through our release pipeline is common across both Windows and Mac platforms. The below diagram – using our upcoming 2.4 macOS release as an example – outlines our process and describes the granularity of our new staged rollout in more detail.

Once a release leaves beta it’s progressively rolled out to groups of users over a period of a few weeks, with time in-between for fixes to be implemented where necessary.

How did we implement it?

The implementation is slightly different for Windows and macOS platforms, but aim to achieve the same goals:

• no dependency changes
• client self-assigns update group
• ability to release in stages (group 1 at 5%, group 2 at 15%, etc.)
• no impact on existing alpha/beta distribution
• minimal file duplication on server
• no need for a self-made web service
• automatable process

Windows

Having implemented Squirrel.Windows for SourceTree’s beta program, we’ve decided to move GA releases from AdvancedInstaller to Squirrel as well. Why Squirrel? We were attracted by its focus on simplicity and felt it aligned well with our goal of improving the installation process for users:

Windows apps should be as fast and as easy to install and update as apps like Google Chrome. From an app developer’s side, it should be really straightforward to create an installer for my app, and publish updates to it, without having to jump through insane hoops.

We’ve found it very easy to integrate Squirrel with our FAKE-based build process and CI. The resulting installer is much smaller, quicker to run, has a cleaner footprint, and comes with the added bonus of removing the requirement for Admin rights to install. Overall we felt the user install experience is much improved.

For progressive rollouts, Squirrel comes with built-in staged rollout functionality. SourceTree generates a release percentage for this local install; this defines which part of the release schedule the instance falls into. SourceTree will check at start up for any new updates, or the check can be manually triggered via the Tools/Options/Update tab. After each update, SourceTree will regenerate a new release percentage, ensuring a random distribution of updates.

macOS

For macOS we weren’t able to find any existing options that met our needs. But Sparkle, the update framework we’re already using, does include a number of hooks for customizing the experience, so we decided to build our own from that. In order to utilize staged updates we only need to take advantage of a single method:

Inside this method we use some randomization to choose groups; that logic is encapsulated in a thoroughly unit tested class (which we’re considering open sourcing if there’s interest). On launch, a user’s group is assigned and cached, clearing when it’s a new app version (2.3.2 → 2.4, not 75 → 76).

On the Server

What happens on the server end is largely unchanged from what we have today. We’ve added new copies of feeds and tweaked release notes so they work in concert with randomization to make staged updates possible.

• direct download and update zip files – a release is uploaded like normal, access to them is managed by feeds; no duplication necessary
• appcast (update) XML feeds – Appcast.xml stays (legacy, no further updates), AppcastAlpha.xml and AppcastBeta.xml stay the same, adds AppcastGroup0.xml through AppcastGroup5.xml
• release notes – ReleaseNotes.html stays (legacy, no further updates), ReleaseNotesAlpha.html and ReleaseNotesBeta.html stay the same, now we use version specific release notes like 2.3.2.html

Build release process

Unsurprisingly, we continue automating via Fastlane:

This former “early access” lane runs a relatively similar process as before: it takes the current version + build info and makes sure the appcast and release notes have been updated properly. If it’s already present no build is produced but the appcasts and release notes are prepared.

Iterating On Our Process

It’s been great revisiting the initial CI and deployment processes we put in place for the beta program and expanding upon them. Figuring out the path of least resistance and what options might work presented a fun challenge and our Fastlane suite is better than ever. Now that we’ve landed this important bit of infrastructure we look forward to the many successful deployments and exciting changes in SourceTree’s future!

We’ve been hard at work squashing bugs, fixing crashes, patching and upgrading parts of SourceTree for Windows in version 1.9.9. Remember that annoying memory leak in the TreeView? Patched. Want support for Git LFS 1.5.2? We’ve added that. Feel free to check that Spell Checker checkbox too – we’ve provided safeguards to protect against Windows’ own spellchecker performance issues. Performance when switching tabs have been improved too. And that’s just the tip of the iceberg.

We want to give a big shout out to members of our Beta community. Your participation helps us identify and fix the biggest pain points; thank you! And if you’re interested in joining the beta program you can do so here.

Download 1.9.9.20 today to get these improvements.

Download SourceTree for Windows

There have been a few reports of memory leaks in recent versions of SourceTree for Windows. We understand these kinds of issues can adversely affect the SourceTree experience and are important to identify and address. Memory leaks can be tough to handle, and is compounded with applications written using a managed language (like SourceTree) as lifetime tracking of objects tend to be fairly complex. Here’s one such memory leak that we fixed in 1.9.9 for Windows that we released last week.

Identifying the leaky object

How does a memory leak appear? Most of the time it’s a fairly simple case of “I created some objects, and when I was done using those objects something was still referencing them”. In this case, identifying what was leaking in SourceTree was an easy task:

Hint: the sidebar isn’t showing more than 100 items and there’s only a single SidebarNode for each item…

Determining the cause

Most of the time the cause of a leak is easy to spot:

• An event handler is still subscribed
• The object is not being removed from a list or is still held on to as a direct reference
• An unmanaged object wasn’t disposed/cleaned up

However, the real difficulty isn’t figuring out if you have a leak – the challenge lies in figuring out what’s causing it to happen. In this case, I suspected that our UI library that quickly draws the sidebar was doing something wrong, and that it might be holding onto objects that it shouldn’t. After looking at the memory dump it was clear that assumption was correct:

That’s more than 4x the correct number of nodes. Okay, so now we know that it involves the SidebarNode and the TreeNode objects. The TreeNode holds a reference to the object it’s showing to the user, so something must be keeping a reference of it around, which is keeping our massive count of SidebarNodes around too.

After taking a peek into the the TreeNode class, there were a few issues (oops):

• A subscription to an event handler wasn’t unsubscribed
• The TreeNode objects were added to a cache and never removed from that cache

To make sure these two things were actually causing the leak, we created a simple demo app was created that added and removed items in the tree thousands of times. Creating a small test app made it much easier to track where the nodes were created, and why they didn’t get cleaned up properly. It also ensures we can test this again in the future to prevent regressions. After running the tests, it appeared that the leak was fixed. As mentioned earlier this fix has been rolled out in 1.9.9 for Windows, and should address the memory issues we were seeing. Check it out for yourself!

Download SourceTree for Windows

We’ve added a ton of new features and improvements in this release:

• Manage your bookmarks easily with a new and colorful tab design
• Huge performance improvements
• Pixel-perfect per-monitor DPI support

Tabs and Header

We implemented a new tab-centric design to increase vertical space and to give readability to the the repository you’re currently working in. The new header design gives you an additional 20px vertically, while the removal of the bookmarks sidebar gives you 250px horizontally.

Before (left) and after

The New Tab….Tab

The repository browser now lives in the New Tab. The old sidebar crammed repository names and had a confusing relationship to your remote repositories. Now you have a dedicated experience for both in a full window. This approach also frees up more space to focus on code once you’re in a repository.

Performance

SourceTree for Windows 2.0 is screaming fast. We improved performance by adding a hybrid LibGit2 handler for most git operations. In many cases, performance for most operations increased by almost 2x. Look how fast reading stashes are with LibGit2!

Workflow

Many primary feature workflows have been rethought and improved. Compare the steps needed for creating a remote repo in the current version of SourceTree, vs the new workflow. In 2.0, creating a remote repository and managing your remote accounts is front-and-center rather than living 2-3 menus or pop-up dialogs deep.

Before (left) and after

Design

Animations, more vibrant colors, improved contrast, and per-monitor DPI support are just a few of the improvements we’ve made. Note the removal of the Windows 2000 era pinstripes, vivid colors, and branch label readability improvements. We’ve improved contrast in many areas by tweaking our use of gray colors, and added accents to window dialogs and notifications.

 Before (left) and after

Per-monitor DPI support

On systems that support per-monitor DPI settings (Windows 10 Anniversary), SourceTree will automatically adjust icons and text to be crisp and pixel perfect when the window is moved between monitors. SourceTree will still use high-DPI icons and scale properly even if your OS doesn’t support per-monitor DPI and you still have a high-DPI monitor or laptop.

 Before (left) and after

Sidebar

Readability has been improved on the sidebar, with more spacing between text and increased vertical spacing.

Before (left) and after

Additionally, the ahead/behind indicator will now float on the right-side of the sidebar, and will be visible even if there’s a scroll-bar in either direction.

Before (left) and after

Download the beta and check out all the new improvements today!

Download SourceTree for Windows 2.0 beta

Connect to your Bitbucket or GitHub accounts securely and with ease in the latest versions of SourceTree for Windows and Mac. These versions of SourceTree fully support OAuth 2.0. Users with Two-Factor Authentication (2FA) enabled can connect to both services via OAuth and be guided through the standard two-factor login flow. Navigate to the Account Management screen to update your already connected accounts from Basic to OAuth today!

Windows

Mac

Also, gone are the days of manually creating and storing SSH keys via command line. Released in version 2.4 for Mac, SourceTree automates the whole process with a single click of a button. Whenever you edit an existing account or add a new one you’ll notice a new “Generate Key” button on the Account Details screen. Click that button and we’ll take care of the rest.

Download the latest versions of SourceTree for Mac and Windows and take advantage of these new features (and various bug fixes/enhancements) today!

Download SourceTree free

It’s an exciting time to be a Windows developer using SourceTree. We’ve seen steady adoption of SourceTree for Windows and today more than half our users come from Windows – impressive for a tool that used to be Mac only! Since launching the 2.0 beta in January and acting on the feedback we’ve received since, we’re excited to announce that SourceTree for Windows 2.0 is now generally available.

Alongside refreshing the UI with a new and improved design, we’ve also listened to all the feedback you’ve provided and focused on making SourceTree for Windows 2.0 the fastest version yet. And that’s not all, as we’re proud to announce support for Microsoft’s Git Virtual File System, making the process of working with unusually large repositories easier than ever before.

Improved user experience and modern look and feel

The first major change you’ll see in SourceTree is the new design. We gathered a lot of feedback around the user experience so not only have we updated SourceTree with a modern look and feel, we’ve also overhauled tabs to improve your repository browsing experience, with a specific focus on finding and cloning your remote repositories. We’ve added more vibrant colors, improved workflow for common operations, and we’ve increased performance by refactoring the bookmarks sidebar. Look out for a separate blog that explains the design in more detail.

Blazing fast performance

Many of you have voiced your concerns about the performance of SourceTree on Windows and we heard you loud and clear. By adding a hybrid LibGit2 handler under the hood for most git operations we were able to improve performance in some cases by almost 2x. Here are the performance tests we ran comparing 2.0 to 1.10 – the results speak for themselves:

And by all means don’t take our word for it, give 2.0 a try and see for yourself just how much faster performance is in this new release!

Support for Git Virtual File System

For all the great things about Git, a common complaint is how difficult it can be to work with large repositories. Git Large File Storage (LFS) helps alleviate these issues when your repository contains large files, but doesn’t help when you have lots of files or content in your repository. To help with this Microsoft announced Git Virtual File System (GVFS) at Git Merge this year, which “virtualizes the file system beneath your repo and makes it appear as though all the files in your repo are present, but in reality only downloads a file the first time it is opened.” So for those working on large repositories that typically deal with a small section of the codebase, using GVFS means you only download what you need rather than the entire repository. This in turn results in faster performance for common operations like checkout and status and improves the experience of using Git as a whole.

With GVFS support in 2.0 you can now utilize SourceTree with Git repositories that have GVFS enabled (e.g. Visual Studio Team Services), enabling you to combine a beautifully simple UI alongside a great technology that makes handling large repositories easier than ever. We’re excited to support GVFS in 2.0, and the same sentiment is shared by Microsoft:

“We’re excited that GVFS is supported in a widely used git client like SourceTree, and we love the new look and feel in 2.0.”

Jeremy Epling, Principal Program Manager on Microsoft TFS & Visual Studio Team Services

Get started today

We’re proud to continue supporting all of the Windows developers out there using SourceTree, and we hope you’re as excited as we are about all the great new features and improvements in SourceTree for Windows 2.0. Upgrade or download it today and tell us what you think!

Download SourceTree free

Performance was one of the key things we wanted to address while working on SourceTree 2.0 for Windows. It was a cause of frustration for many of you, and we knew we could do much better to improve your experience with SourceTree. Rather than focus on one performance attribute or one git command, we took a holistic approach. We looked at reducing the visual complexity of the UI, as well as the speed of many Git operations you love and use every day.

Visual Complexity

Visual complexity can be described as the number of elements displayed in an application; the more elements you have in your user interface, the more complex it is. SourceTree uses Windows Presentation Foundation (WPF) to render its user interface and the elements contained within. With WPF, interface elements are part of a composition tree, with each element in SourceTree’s interface adding one or more composition nodes to said tree. Whenever an element changes in the UI (e.g. an event occurs or an operation is performed in SourceTree) both a layout and redraw pass typically happens, as the tree is walked and rendering instructions executed for each composition node.

For visually complex applications (hello, SourceTree!) these passes look, from a user’s perspective, as stutters in the UI. So the general rule of thumb in light of this, along with the feedback we’ve received around performance, was to reduce the number of elements in SourceTree’s UI. We wanted to reduce the visual complexity of the application without losing the benefits of seeing the most important elements at the same time. We’ve actually been working at reducing this complexity for quite some time. So how do those elements stack up in SourceTree 2.0 for Windows compared to older versions?

Visual Complexity Across Versions – Corefx Repo

SourceTree Version 1.9/10: 1760 visual tree elements

 
How was it done?

• The file diff was rewritten to a custom text display control, which is now virtualized (only visible elements are part of the tree)
• The sidebar was rewritten to a custom virtualized tree view
• Bookmarks sidebar had a few icons removed

SourceTree Version 2: 1414 visual tree elements

How was it done?

• Bookmarks sidebar removed as it’s now in the “New Tab”
• The log view pills were rewritten to draw via custom function rather than have visual tree elements

Caching File Lists

Another improvement we made was the caching of views between the “File Status” and “Log / History” view. Before 2.0, switching between these views would cause the file lists to refresh each time, something that could take a few seconds depending on how many files you had. In 2.0, these views are no longer recreated when switching, eliminating the stuttering you used to see as the lists were refreshed.

SourceTree Version 1.9/1.10: No Caching

 
SourceTree Version 2.0: Caching

Git Performance

The performance of individual Git functions has a tremendous impact on the overall responsiveness of the application. SourceTree frequently runs background tasks, so any improvement typically has a cascading effect on higher-level features. For 2.0 we decided to add a hybrid LibGit2 handler for most Git operations in order to improve performance for most operations.

The results speak for themselves:

And of course you’ll also see improvements in other features you know and love like Git LFS support, bundles, SVN support, and interactive rebasing.

Try SourceTree 2.0 for Windows today

SourceTree 2.0 for Windows is a sign of things to come and we’re excited to see our hard work bear fruit in the hands of all of our users. We’re not done yet and will continue to work harder on further performance improvements, and if you have any feedback we’d love to hear from you.
 
Happy Coding!

Download SourceTree free

Starting Tuesday, May 9th, we will be supporting SourceTree through the new Atlassian Community.

Dedicated support via Atlassian Community

In the past we focused on providing support to SourceTree users with their various setup and configuration issues via support.atlassian.com. Analysing many of these resolutions, we realised that the nature of these support requests didn’t necessitate private contact and the community as a whole could benefit from this knowledge being made public. As a result, we’re dedicating our support staff to focus on offering the same support you know and love via Atlassian Community instead.

Get involved

The additional benefit of this change is the ability for the broader SourceTree community to contribute, learn, and share their knowledge with one another. If you’re keen to learn more from the SourceTree community, take the next step and watch the collection. We’re committed to making sure you get an equivalent quality level of support via Atlassian Community, with the added benefit of your fellow SourceTree users sharing their knowledge and insight of the product as well.

SourceTree 2.0 brings massive wins not only for performance, but for design. In this release, we’ve continued to address the number one customer feedback theme: UI complexity. To this end, we’ve brought some much needed consistency and simplicity to the interface.

A proper home for tabs

The Windows App always used tabs for navigating between open repositories, but we knew that those tabs weren’t quite right. The toolbar sat above everything else in the UI, but it only really belonged to the open repo (tab). We’ve swapped those panels so that tabs now live at the top of the hierarchy, much like browser experiences that you are no doubt familiar with.

Here we can see a sort of “topological map” of the various UI panes, charting where we’ve been and where we’re going. As you can see, things were pretty cluttered before. We’re moving toward a more logical and simple layout with more room to review your code.

Familiar paradigms

Through testing and feedback, we learned just how much of a pain the bookmarks pane was.

• Many first-time users would struggle cloning or opening repositories.
• There wasn’t enough horizontal space to read the name of the repository in a narrow vertical layout.
• The bookmarks pane took up a lot of valuable screen space, but was seldom used once the repositories were open in tabs.
• The remote repository listing was disconnected and hard to find.

It became clear that repository lists needed their own dedicated experience. Because we were already using tabs, adding a plus button was a natural fit. If you’re familiar with how to open a new tab in a browser, you’re familiar with SourceTree.

A glimpse at the future

SourceTree 2.0

Coming soon

So what’s next? Here’s a look at where SourceTree is headed.

• The awkward footer tabs will be grouped in sidebar, like the Mac App.
• The committer info panel will be cleaned up.
• View options will be moved to the view menu.
• Density view options.
• We are exploring more ways to help you manage lots of repositories and stay up-to-date with outstanding push/pulls.
• Diffs will get nicer colors and layouts. ✨
• If Build 2017 is any indication, we’ll replace all panels with transparent blurry “Acrylic.” (Just kidding)

As always, we’re listening closely to your feedback. Reach out on our community site and tell us what you think.

Download SourceTree free

Many macOS apps like SourceTree are distributed outside of the Mac App Store and provide in-app updates via a popular open source framework – Sparkle. Using Sparkle, SourceTree pushes out updates to all users simultaneously whenever the 

 file is updated. While suitable for its intended purpose, these days many web services favor rolling out updates to groups of users in an incremental fashion, providing a safety valve for issues not found during testing or that crop up unexpectedly. Smoother releases were something our team wanted to implement in order to minimize impact these issues can have on the entire user base. The team explored options and ultimately decided to build our own utilizing Sparkle and fastlane, and we’re proud to announce the open sourcing of the code that progressively rolls out new updates for SourceTree.

What’s in the box

From the beginning we sought to have a minimal footprint for these changes, delivering the functionality we wanted with minimal disruption. Each component is easily digestible and ready to be tweaked for your needs. While written in Objective-C it works just as well in Swift via bridging – in fact, the demo app and all unit tests are written purely in Swift!

• PRGUpdateHelper – the primary class encapsulating randomized group management logic
• PRGGroupPercentageTransformer – simple transformer for mapping group numbers → logical percentages
• NSString+PRGHashing – simple category for generating a SHA1 hash
• ProgressiveUpdater (demo app) –  a small app that demonstrates how to use the class and visually verify results

Once the client was aware that multiple feeds were available we needed to make sure the appropriate feeds were actually there. We were already using the equally well-known toolset, fastlane, for distributing our builds (along with several other tasks) so it was natural to take advantage of its richness.

This project includes a distilled version of our distribution logic in the Fastfile. Default lanes such as alpha and beta generate builds tailored to those updates and there’s now one called custom which provides one-off builds for testing that disable updating. The star of the show is the update lane which takes a percentage and builds the appropriate deploy artifacts for uploading to your server. When brought together these lanes make it efficient to manage testing across a range of options and ensures a smooth rollout to your users with minimal fuss.

Airbags aren’t optional

We implemented phased releases in SourceTree because of substantial, potentially disruptive changes that were underway in the 2.4 release. We added OAuth 2 authentication and an SSH Helper to make setup simple and easy, but complicated challenges around topics such as these have the potential to create problems despite good intentions. We released 2.3.2 in late October with the phased release functionality baked in and, in early December, we started rolling out 2.4 to an increasingly large group of users based on the timeline we discussed previously.

Is it working? Absolutely. We’ve had a manageable flow of reports coming in through our various support and bug report channels along with monitoring comments on Twitter and elsewhere to follow up with users encountering problems. These reports have been invaluable in hardening 2.4 for general consumption. Less than 25% of users have been offered the update, and with the telemetry received so far we’ve shipped at least 5 builds with a lot of reliability, usability, and functionality improvements that traditionally would have necessitated one or more rapid dot releases. Rather than cause a large amount of churn for everyone, we’ve now got an additional airbag in place beyond our Trusters Testers beta group that provides a bit more peace of mind for users and breathing room for us.

In the end we hope others will benefit from having these resources at their disposal. If you’re updating your app outside of the Mac App Store you should definitely check it out. There’s a public Git repo available via our Atlassian Labs group on Bitbucket that’s a quick clone away, and it’s the same code used in SourceTree today. We encourage you to file bug reports and feature requests via the repository’s public issue tracker and pull requests are always welcome!

Upgrade your updates today!

A “non retina-burning” update for SourceTree on macOS has been on our radar for a long while, and recently our senior designer Joel Unger came up with a mock-up on how it might look. We went back and forth on limitations and compromises (i.e. the old expectations versus reality phase) while exploring the concept during ShipIt, Atlassian’s well known hackathon. From there it then entered the development pipeline because even the worst compromise we’d found, potentially losing customization of the toolbar, wasn’t enough to deter 70+% of respondents to a quick Twitter survey.

Engineering Discussion

There are a variety of ways to implement dark themes on macOS. These range from the basic, applying an NSAppearance at the top level of a window and letting it cascade through stock controls like FaceTime, all the way through the ‘off-limits’ way by utilizing ProKit, a well known private framework used during my time at Apple that provided apps such as Final Cut Pro the ability to customize every element of their appearance. Our discussions focused on what limitations and compromises we wished to take, ranging from the use of color (black or tones thereof? custom colors?), how much content was themed, and deciding on how much custom UI to implement versus what options were available out of the box.

With the goal of offering the best user experience possible without saddling us with additional overhead in the future, we ultimately chose to use custom colors (midnight blue tones in this case) throughout, while maintaining all existing functionality with minimal custom UI. While it was the option that proved the most challenging to implement, we felt it would ultimately provide the best value to users by maintaining desired functionality present in the system by default versus other, more straightforward options available. We also decided to focus only on the primary windows a user interacts with rather than focusing on all windows and sheets throughout the app as it exponentially increases the size and scope of such a feature.

Taming the Beast

With the decision made, what did we change and how?

• color management: similar to ProKit, a theme coordinator provides a centralized location for colors which alternate based on either the specified theme or automatically for current theme. When changing the current theme this broadcasts it to allow elements to respond appropriately. This design has made it easy to iterate on the colors and assets with our designer while minimizing code churn and testable logic. When the time came to revise our branch color selection algorithm we also migrated it to theme coordinator, making it testable alongside the rest of the feature in our unit test suite.
• window, toolbar:  one of the first major hurdles was changing the toolbar and corresponding window chrome such as tabs. We use a standard NSToolbar with unified titlebar which supports a handful of themes from macOS and has a wealth of functionality including accessibility and customizability. macOS defines their NSAppearance under the covers in a manner similar to ProKit using bundles with compiled .car files. While there is an API to specify an arbitrary bundle for an appearance and additional ones that aren’t exposed in the system UI there is no guarantee as to their stability so we stuck with NSAppearanceVibrantDark or NSAppearanceAqua typically. Ideally the entire window would pick up the same dark blue tonal quality in combination with that. To accomplish this we ended up choosing the ‘vibrant dark’ appearance, which composites with a darkened blur and materials, and reverse engineering a color that worked with it. Once we’d found a proper color to composite it was a matter of finding where to make that change. In the debugger we were able to catch which layer(s) are composited against and then change accordingly as you can see in the above screenshot in a cauliflower blue.
• asset swapping: SourceTree uses a large number of images throughout the app from its vibrantly themed sidebar to the customized toolbar to file statuses and these need to respond properly, swapping to the theme-appropriate variant and ideally living in the Xcode-optimized asset catalog format instead of continuing the legacy of raw files in Resources.
• scrollers: the next major hurdle we encountered was theming scrollers – these have a default state, background, borders, and even a separate track when scrolling; each of these elements had to be teased apart and themed accordingly.
• the long tail: all those are just a few of the highlights that knocked out the first 80%… after that we had to start poking into the various nooks and crannies to get dividers, backgrounds of containers, customizable per-theme diff colors, buttons, and font colors just right. This is where the aforementioned view debugger really shined as it made it possible to visualize and navigate the disparate bits that composed a given area such as the multi-part diff view sometimes.
• … one more thing: our MVP covered the repo window that’s the lifeblood of developer workflows but it’s not the only one you might keep on-screen. To round out the experience we hopped onto the Repo Browser code as well and were able to leverage the prior work to quickly theme this window too, keeping your screen cool and consistent.

Living with Change

You can give the dark theme and corresponding revised light theme (both of which we consider beta) by downloading it directly from our website. Phased releases are beginning tomorrow in coordination with these “How It’s Made” discussions and we welcome your feedback to review and potentially incorporate in 2.6.1. We’re listening and want to make this the best experience possible as you switch SourceTree from day to night.  

Download SourceTree free

The best software development tools aid you in your development and stay out of your way as much as possible. They also provide all the context you need to get work done, removing the need to switch between tools to work out what’s going on or what to do next. Sourcetree is built to aid those new to distributed version control, like Git and Mercurial, as well as to provide advanced users a visual interface from which to work with their repositories. Today we’re providing greater awareness into your builds with the beta of our integration with Bitbucket Pipelines. Now build statuses appear in Sourcetree for macOS, giving you greater context and confidence in the quality of your code.

It’s a first for any Git or Mercurial client and we’re excited to share the fruits of our labor.

Build status at your fingertips

With modern software development practices, like CI/CD or DevOps where everyone is responsible for code quality, it’s important that information is easily accessible to everyone. Bitbucket Pipelines empowers these teams to build, test, and deploy their code directly within Bitbucket Cloud, and it was a natural fit to bring that all important information into Sourcetree for macOS. We’ve removed the context switch or two away from your workflow to see a build’s status within Bitbucket Cloud’s UI, and brought it from right where you commit.

And best of all, Sourcetree utilizes notifications in macOS to update you when a build finishes, so it’s really one and done when you push a commit.

Sourcetree for macOS not only provides the same at-a-glance information about the most recent status and runs in your commit graph, but it also allows you to peek into details for any of the runs associated with that commit. You only need to visit Bitbucket Cloud to dive into the specific logs for a run, and even that’s just a simple click away.

Get started today

The Pipelines integration for Sourcetree for macOS is in beta today, and will slowly roll out to users in the next release in a few weeks’ time. We’re excited to help you improve the quality of your code and add vital context to your workflow. Download the beta, give the integration a try and let us know what you think!

Download the beta

P.S. Want to be amongst the first to find out about new fixes and features like this in the future? Be sure to join our trusted-testers mailing list.

Modern software development practices like CI/CD and DevOps help the whole team be responsible for code quality. However, success in this environment depends on important information being accessible to everyone, instantly. Our Sourcetree team has taken this idea to heart in macOS by providing greater visibility into your builds, giving you more context and confidence in the quality of your code.

All you need to get started is a Bitbucket Cloud account, with Bitbucket Pipelines enabled, and you’ll be viewing the status of builds in Sourcetree in no time!

Let’s walk through how to make this happen.

Sign up for Bitbucket Cloud

Our Sourcetree integration with Bitbucket Cloud now provides visibility into the status of your builds.

Bitbucket Cloud is distributed version control, code review, continuous integration, and much more for software teams across the globe. Bitbucket Cloud includes free unlimited private repositories with nearly an hour of build time per month to enjoy built-in continuous delivery with Bitbucket Pipelines.

Step one of seeing build status in Sourcetree is signing up for a Bitbucket Cloud account.

For those with a Bitbucket Cloud account already, feel free to skip to the next section. If you’ve just signed up for a Bitbucket Cloud account, follow these instructions to import an existing repository of yours – you won’t be able to enable Bitbucket Pipelines and build without one!

Getting started with Bitbucket Pipelines

Bitbucket Pipelines empowers teams to build, test, and deploy their code directly within Bitbucket Cloud.

Here’s how to get your first build in your repository in 3 simple steps:

Step 1 Click the Pipelines icon, then click Start using Pipelines to access our language templates.

Note: Pipelines won’t work with an empty repository so you’ll need to add at least one file to get Pipelines building.

Step 2 Choose a language template and edit the bitbucket-pipelines.yml file which defines your build.

Step 3 Click Commit file and watch Pipelines start building.

If you don’t want to use the wizard to commit the file or you want to test the configuration locally first, check out this guide for more information.

Viewing build status in Sourcetree

Now that you’ve got Bitbucket Pipelines enabled in your Bitbucket Cloud repository, the last and final step to see build status in Sourcetree is to add the repository (or pull the changes) in Sourcetree.

Step 1 Navigate to Preferences → Accounts, click Add, and fill in the details in the dialog.

Step 2 Open the repository you enabled Pipelines on from the Repository Browser, or by using Cmd + O to select it on disk.

Step 3 Click Pull in the toolbar or use Repository → Pull… from the main menu.

And that’s it! You can now see the status of builds for a commit without having to leave Sourcetree. If you’re stuck at all head over to the Atlassian Community for some help getting up and running.

We listened closely to all of your feedback about the pain points that remained in the 2.x release of Windows, and the resounding chorus was… performance, performance, performance! While we’d already integrated LibGit2 with great success it wasn’t a panacea. We knew we could do better but needed more data.

Under the covers

We began by adding the Process Log, which helps you clearly understand how Sourcetree is using Git and Mercurial. It can also help diagnose issues like long-running, orphaned or duplicate processes. It’s also for those who might be curious about how things work behind-the-scenes without opening Task Manager or a terminal window to dig deeper. Using this new utility we were able to identify and resolve a number of subtle bugs that were unexpectedly consuming precious computing resources.

Depending on others

The heart of a repository lies in its commit graph. Another thing we learned, from both benchmarking instrumentation and the Process Log, was that submodule loading performance was slower with LibGit2 than calling out to the Git executable. We tracked down some issues that were responsible for these slowdowns; fixing them resulted in the dramatic 3 – 4x speed boost you see below; darker bars represent the improved times.

But wait, there more… we chose to use the Boost library as our benchmark because it contains over 100 submodules and were able to reduce the time it takes to scan for and show changes from 26 seconds to just 2 seconds. That’s more than an order of magnitude faster! Normally we’d put a gif of the difference here to demonstrate the impact but we decided to save you from an infinite spinner.

Jump around, jump around

If you’ve ever seen the dreaded ‘Fetching Commits’ banner and felt frustrated as Sourcetree does a bunch of work – good news, it’s largely a thing of the past. The change sounds a bit logical when talking through it… any “jump” will now use the date of the commit as a reference point for loading. Now we can typically run a single command instead of continually loading our way to the selected commit with an unbounded number of commands. While both styles can be effective at loading the graph dynamically, especially given our performance boost above, we’ve eliminated any potential for it to be rather annoying to jump thousands of commits back in your history, instead responding nimbly regardless of your repository’s size or shape.

Take it to 11

As a bit of icing on the cake we also improved the experience for tabs by reducing the time it takes a tab to first load by 100ms and more noticeably by adding a smooth animation when working with them.

We’re incredibly proud to share the 2.4.8.0 release with all our users to help them save countless developer hours and increase their productivity. Download it today from our website to enjoy one of the most stable, responsive, and performant experiences for Sourcetree on Windows to date.
 

Download SourceTree free