By Steve on May 13, 2013
We’ve just changed our installer and auto-update system for SourceTree for Windows – up until now we’ve been using ClickOnce, which although quick and simple has caused problems for some people, such as those behind corporate proxy servers. As our user base has grown larger it’s becoming an increasing issue for people that needed to be resolved, hence the new installer.
If you download SourceTree for Windows now you will automatically get the new installer, which features many improvements over the previous setup:
- It’s one file. This is just simpler, particularly if you want to download once and install many times across a corporate network.
- You can install it when offline. One caveat: if you don’t have .Net 4.5 installed already (only applies to Windows 7) and you’re offline, the installer can’t retrieve it for you, so you’ll need to also download the Standalone .Net 4.5 Installer.
- The installer and auto-update system work behind all proxy servers
- You can pick the install location, unlike ClickOnce which gave you no choice.
- More robust. ClickOnce could sometimes tie itself in knots if something went wrong during the install or update, this system should avoid that.
If you already installed with the ClickOnce installer, you don’t have to grab the new installer yet (there will be one more ClickOnce bugfix update today), but we recommend doing so as soon as it’s convenient for you – you’ll be reminded at startup once the new installer updates become the only path. Installing the new version will happen alongside the ClickOnce install, and will retain all your bookmarks, per-repository settings, and any settings stored with Git itself, however your other settings in Tools > Options will be reset to the default. Once you are up and running with the new version you can simply uninstall the ClickOnce install, which will look something like the below in your Control Panel > Uninstall window:
Just uninstall the highlighted entry (the one with the ‘globe’ icon, rather than the SourceTree icon).
Switching over to a brand new installer / updater is not something we do lightly, however based on the feedback we’ve had from the community we think this is the best option for everyone for the future. We hope you continue to enjoy using SourceTree for Windows!
By Kieran Senior on May 7, 2013
After some great community feedback, we are releasing SourceTree for Mac 1.6. This is a major release that contains many new features.
Download SourceTree for Mac 1.6
Interactive Rebase
Having to bring up a terminal when you want to do an interactive rebase is painful. If you aren’t familiar with rebasing or the command-line, the pain levels up to excruciating. We asked ourselves: “How can we make this simpler and keep everything in SourceTree?” Our solution is a visual, drag-and-drop interaction:
The UI gives you visual feedback on each step of this previously advanced function. Want to re-order your commits? Want two commits to be one commit? No problem, just drag and drop the rows around.
Improved Notifications of Remote Changes
Previously, users checked for the pull counts by going into either the bookmarks view or the repository view. If your team commits frequently, you were checking there a lot. Now, the improved notifications center puts this information front and center:
Are you using OS X 10.6/10.7? No worries, we use Growl so it handles everything for you. If you’re on Mountain Lion, we use the notification centre so you’ve got more granular control over notifications. Prior to Mountain Lion, you could use Growl to control the notification granularity. We find them really useful; especially when we’re expecting changes we need in our local copy.
Atlassian ID Integration
SourceTree won’t cost you a penny but we do ask you to register to continue using it after your 30 day trial. Registration helps us gather useful statistics that we use build a better SourceTree. Still, we know registration costs you time, so we’ve improved it. We’ve redesigned registration as a two-step process from within SourceTree. No more web registration. Even better, the in-product registration creates an Atlassian ID that can you can use with other Atlassian products.
Icon Refresh
Have you noticed our new icons? They’ve been out but now we’d like to point them out. We think our new icons have a fresh look that brings SourceTree in line with the rest of Atlassian’s product family.
Mac App Store Note
A final note just to say that we no longer publish to the Mac App Store due to sandboxing restrictions. Check Steve’s blog post about sandboxing for more information.
And much more…
- You can now Log Selected… on multiple files at once.
- The push sheet in Mercurial shows which branch you’re pushing to.
- New preference show the pull count for the currently checked out branch.
- Git repositories now remember the previously selected options in the pull/merge sheets.
- Support for the latest Araxis diff/merge tools.
- The “commit merged changes immediately” setting is now remembered between pulls
- Support for longer passwords for Bitbucket, Stash, GitHub and Kiln.
Work on Windows? We’ve got that covered, too. SourceTree for Windows 0.9.2.2 is now out including git-flow support! Check out our main website for more information and download.
By Steve on May 1, 2013
Our Git Flow support in SourceTree for Mac turned out to be really popular, and it’s been one of the top feature requests from the community since we released SourceTree for Windows; so we’re very happy to announce that you can now use Git Flow in Windows as of version 0.9.2 beta!
If you’d like some more detail on what Git Flow is about and how SourceTree helps you use it, the blog post Smart branching with SourceTree and Git-flow is a good place to start. We wrote it for the Mac version, but the Windows version operates in exactly the same way and the interface looks the same too barring a few small details.
We hope you enjoy using this feature! Since the public release of SourceTree for Windows a little over a month ago we’ve been working hard to expand and improve it, and there will be plenty more updates in the weeks to come.
By Kieran Senior on April 25, 2013
You can now download SourceTree for Mac 1.6.0b3. This is a minor release addressing only a few issues. You can get this through automatic updates if you’re on 1.6.0b2. For those of you on 1.6.0b1 you’ll need to download a copy of the latest release.
Download SourceTree 1.6.0b3
See the release notes for more information on what’s included in this update.
By Kieran Senior on April 16, 2013
SourceTree for Mac 1.6.0b2 is now available for download. Automatic update from b1 to b2 is unavailable, any subsequent beta updates will be available through automatic update, however.
Download SourceTree 1.6.0b2
This update contains many enhancements and bugfixes primarily to interactive rebase functionality. Check the release notes for more information.
By Steve on March 28, 2013
We’re pleased to announce that SourceTree for Mac 1.6 beta is now available to download!
Download SourceTree 1.6 beta 1
We’ll be running the beta for a little while to collect feedback and we’d love to know what you think. Here’s an overview of some of the great features in this version:
Interactive Rebase
The git rebase –interactive command allows you to reorganise your commits after you’ve created them (but before you’ve made them public), and now you can do this inside SourceTree. Combine (squash) multiple commits together, or re-order them, simply by dragging & dropping. You can also change the commit message, or edit the content of the commits. Just right-click on a commit in the log and choose ‘Rebase children of <sha> interactively’ to kick the process off.
Notifications are Here
Now when there’s new commits to pull into your repository you don’t have to take a look at your repository window to find out – SourceTree will raise a notification to let you know, either a native Mountain Lion notification or via Growl.
Atlassian ID Integration
Previously, in order to register with Atlassian, you had to go to our website and download your license file to be imported into SourceTree. Now you can register seamlessly right from within the product itself.
Icon Refresh
Our designer gave us a treat with a new icon set making the user interface look even more satisfying!
And lots more…
- You can now “Log Selected” on multiple files at once
- The push sheet in Mercurial shows what branch you’re pushing to
- Preference added to make the pull count reflect the branch you’ve currently got checked out
- Git repositories now remember what options were previously selected in the pull/merge sheets
- The latest Araxis diff/merge tools are now supported
- The “commit merged changes immediately” option is now remembered between pulls
- Longer passwords supported for integrating with Bitbucket, Stash, Kiln, and GitHub
Check out the release notes for more information.
By Steve on March 19, 2013
The SourceTree team is thrilled to announce the latest addition to our family Atlassian distributed version control system (DVCS) family – SourceTree for Windows.
For some time now many Windows developers have been requesting a native counterpart to the SourceTree Mac desktop client. Windows developers, say goodbye to the command line and use the full capabilities of Git through SourceTree’s beautifully simple interface (and stop being jealous of what your Mac friends are using).
A simple, powerful Git client
SourceTree for Windows simplifies how you interact with Git repositories so you can focus on coding.
- Get your team up and running using common Git commands from a simple user interface
- Manage all your Git repositories, hosted or local, through a single client
- Put Git commands at your fingertips: commit, push, pull and merge with just one-click
- Use advanced features such as patch handling, rebase, shelve and cherry picking
- Connect to your repositories in Bitbucket, Stash, Microsoft TFS or GitHub
Perfect for Git newbies
SourceTree was built to make Git approachable for every developer – especially those new to Git. Every Git command is just a click away using the SourceTree interface.
- Create and clone repos from anywhere
- Commit, push, pull and merge
- Detect and resolve conflicts
- Search repository histories for changes
Visualize your repositories
SourceTree keeps track of code activity and provides an at-a-glance view of everything from projects to repositories to changesets.
Use SourceTree’s Bookmarks to get a real-time, aggregated view of all your projects and repositories. Jump directly to the changeset graph to visualize changesets across multiple branches and forks.
Powerful enough for Git veterans
SourceTree makes Git simple for everyone, but also makes Git experts faster and more productive. Review your outgoing and incoming changesets, cherry-pick between branches, create and apply patches, rebase, shelve changesets and more with lightning speed.
Git one-stop shop
Atlassian offers a full complement of tools that will help you and your dev team make the most of Git. Whether you’re working on Mac or Windows, behind the firewall or in the cloud, Atlassian’s family of Git tools will bring you the power of Git while making adoption a breeze.
Connect to the cloud or behind the firewall
Thanks to hosting services like Bitbucket, many small teams working with Git repositories begin coding in the cloud. Connect SourceTree to Bitbucket’s free unlimited private repositories to easily manage your Git repositories from the SourceTree interface.
Stash, Atlassian’s Git repository manager for Enterprises, makes it simple to manage your Git Server – behind the firewall. With powerful two-way integration, Stash and SourceTree make it easy for your team to develop with Git. SourceTree can discover and fetch your Stash repositories. And one-click clone operations get you the source you need fast.
If you don’t have Stash or Bitbucket yet, not a problem, SourceTree for WIndows works with any Git repository, including GitHub, Microsoft Team Foundation Server or your own Git server.
What’s coming next?
Windows
We received great feedback from the SourceTree for Windows private beta users (a huge thank you). We will continue to push frequent updates and features to SourceTree for Windows users. We plan to bring all the great features that are part of SourceTree for Mac to Windows as well. What can you expect in the near future:
- Mercurial support
- Git-flow support
- Custom actions
- JIRA integration
- and heaps more
Mac
We will continue to push out frequent releases for the Mac client. Stay tuned for an upcoming release featuring:
- Interactive rebase support
- Updated icons
- Desktop notifications
Get SourceTree for Free!
If you’re new to Git, or just want a handy tool to make you even faster, download SourceTree – it’s free at our brand spankin’ new website.
By Justen Stepka, Product Manager on February 14, 2013
“SourceTree makes Git a pleasure to use and we need it on Windows.”
You asked, we listened! SourceTree, our powerful Mac client for Git and Mercurial distributed version control systems, is coming to the Windows platform in the next few weeks and we want you to be part of the beta!
Early Access Program
Atlassian is rolling out an early access program to give developers an advance preview of SourceTree for Windows builds and provide feedback before our general launch. Simply give us your email address and over the next two weeks we’ll be emailing a random selection of users to provide feedback.
New to SourceTree?
SourceTree makes it easy for anyone to interact with and manage repositories, automate complex command line operations, and visualize changesets across multiple branches and forks. Host your source in Bitbucket, Stash or any other popular hosting tool and work with that source in SourceTree.
SourceTree helps with several common developer needs:
- Get a team up and running using common Git and Mercurial commands from a simple GUI
- Manage all your repositories, local or hosted, through a single, simple client
- Commit, push, pull and merge changes easily
- Advanced features such as patch handling, rebase, stash/shelve and much more
By Jeff Park on October 8, 2012
SourceTree creator, Steve Streeting, will be attending PyCon Ireland, and we’re hosting a drinkup in Dublin to meet and greet customers. Details below.
Where? The Stag’s Head in Dublin
When? Saturday, Oct 13, 2012, 7 PM
Who’s invited? Everyone! Even those not attending PyCon
Want to talk Git or Mercurial? Itching to find out how others use SourceTree? Have some feedback to share about Atlassian products? Either way, come through and have drinks on us.
Steve will also be giving away some awesome SourceTree t-shirts to the first 50 guests. So arrive early!
By Steve on August 21, 2012
As you’re no doubt aware, Git and Mercurial are great at re-integrating divergent lines of development through merging. They have to be, since their design strongly encourages developers to commit changes in parallel in their own distributed environments. Eventually some or all of these commits have to be brought together into a shared graph, and merging and rebasing are two primary ways that let us do that. So which one do you use?
What does Merge or Rebase mean?
Let’s start by defining what merging and rebasing are.
Merging brings two lines of development together while preserving the ancestry of each commit history.
In contrast, rebasing unifies the lines of development by re-writing changes from the source branch so that they appear as children of the destination branch – effectively pretending that those commits were written on top of the destination branch all along.
Here’s a visual comparison between merging and rebasing a branch ‘feature/awesomestuff’ back to the master branch (click for full size):
So merging keeps the separate lines of development explicitly, while rebasing always ends up with a single linear path of development for both branches. But this rebase requires the commits on the source branch to be re-written, which changes their content and their SHAs. This has important ramifications which we’ll talk about below.
[An aside: merging in Git can sometimes result in a special case: the 'fast forward merge'. This only applies if there are no commits in the destination branch which aren't already in the source branch. Fast-forward merges create no merge commit and the result looks like a rebase, because the commits just move over to the destination branch - except no history re-writing is needed (we'll talk about this re-writing in a second). You can turn fast-forward merges off in SourceTree so that a merge commit is always created if you want - check the 'Create a commit' option in the Merge dialog or set it globally in Preferences > Git.]
So, what are the pros and cons of merging and rebasing?
Pros and Cons
Merging Pros
- Simple to use and understand.
- Maintains the original context of the source branch.
- The commits on the source branch remain separate from other branch commits, provided you don’t perform a fast-forward merge. This separation can be useful in the case of feature branches, where you might want to take a feature and merge it into another branch later.
- Existing commits on the source branch are unchanged and remain valid; it doesn’t matter if they’ve been shared with others.
Merging Cons
- If the need to merge arises simply because multiple people are working on the same branch in parallel, the merges don’t serve any useful historic purpose and create clutter.
Rebase Pros
- Simplifies your history.
- Is the most intuitive and clutter-free way to combine commits from multiple developers in a shared branch
Rebase Cons
- Slightly more complex, especially under conflict conditions. Each commit is rebased in order, and a conflict will interrupt the process of rebasing multiple commits. With a conflict, you have to resolve the conflict in order to continue the rebase. SourceTree guides you through this process, but it can still become a bit more complicated.
- Rewriting of history has ramifications if you’ve previously pushed those commits elsewhere. In Mercurial, you simply cannot push commits that you later intend to rebase, because anyone pulling from the remote will get them. In Git, you may push commits you may want to rebase later (as a backup) but only if it’s to a remote branch that only you use. If anyone else checks out that branch and you later rebase it, it’s going to get very confusing.
Practical tips
Looking at the above pros/cons, it’s clear that it’s generally not a case of choosing between one or the other, but more a case of using each at the appropriate times.
To explore this further, let’s say you work in a development team with many committers, and that your team uses both shared branches as well as personal feature branches.
Shared branches
With shared branches, several people commit to the same branch, and they find that when pushing, they get an error indicating that someone else has pushed first. In this case, I would always recommend the ‘Pull with rebase’ approach. In other words, you’ll be pulling down other people’s changes and immediately rebasing your commits on top of these latest changes, allowing you to push the combined result back as a linear history. It’s important to note that your commits must not have been shared with others yet.
In SourceTree, you can do this in the Pull dialog:
You can also set this as the default behavior in your Preferences if you like:
By taking this approach, when developing in parallel on a shared branch, you and your colleagues can still create a linear history, which is much simpler to read than if each member merges whenever some commits are built in parallel.
The only time you shouldn’t rebase and should merge instead is if you’ve shared your outstanding commits already with someone else via another mechanism, e.g. you’ve pushed them to another public repository, or submitted a patch or pull request somewhere.
Feature branches
Now let’s take the case where you deliberately create a separate branch for a feature you’re developing, and for the sake of this example, you are the only person working on that feature branch. This approach is common with git-flow and hg-flow for example. This feature branch may take a while to complete, and you’ll only want to re-integrate it into other lines of development once you’re done. So how do you manage that? There are actually two separate issues here that we must address.
The final merge: When building a feature on a separate branch, you’re usually going to want to keep these commits together in order to illustrate that they are part of a cohesive line of development. Retaining this context allows you to identify the feature development easily, and potentially use it as a unit later, such as merging it again into a different branch, submitting it as a pull request to a different repository, and so on. Therefore, you’re going to want to merge rather than rebase when you complete your final re-integration, since merging gives you a single defined integration point for that feature branch and allows easy identification of the commits that it comprised.
Keeping the feature branch up to date: While you’re developing your feature branch, you may want to periodically keep it in sync with the branch which it will eventually be merged back into. For example, you may want to test that your new feature remains compatible with the evolving codebase well before you perform that final merge. There are two ways you can bring your feature branch up to date:
- Periodically merge from the (future) destination branch into your feature branch. This approach used to cause headaches in old systems like Subversion, but actually works fine in Git and Mercurial.
- Periodically rebase your feature branch onto the current state of the destination branch
The pros and cons of each are generally similar to those for merging and rebasing. Rebasing keeps things tidier, making your feature branch appear quite compact. If you use the merge approach instead, it means that your feature branch will always branch off from its original base commit, which might have happened quite a long time ago. If your entire team did this and there’s a lot of activity, your commit history would contain a lot of parallel feature branches over a long period of time. Rebasing continually compacts each feature branch into a smaller space by moving its base commit to more recent history, cleaning up your commit graph.
The downside of rebasing your feature branches in order to keep them up to date is that this approach rewrites history. If you never push these branches outside your development machine, this is no problem. But assuming that you do want to push them somewhere, say for backup or just visibility, then rebasing can cause issues. On Mercurial, it’s always a bad idea – you should never push branches you intend to rebase later. With git, you have a bit more flexibility. For example, you could push your feature branches to a different remote to keep them separate from the rest, or you could push your feature branches to your usual remote, as your development team is aware that these feature branches will likely be rewritten so they should not check them out from this remote.
Conclusion
The consensus that I come across most frequently is that both merge and rebase are worth using. The time to use either is entirely dependent on the situation, the experience of your team, and the specific DVCS you’re using.
- When multiple developers work on a shared branch, pull & rebase your outgoing commits to keep history cleaner (Git and Mercurial)
- To re-integrate a completed feature branch, use merge (and opt-out of fast-forward commits in Git)
- To bring a feature branch up to date with its base branch:
- Prefer rebasing your feature branch onto the latest base branch if:
- You haven’t pushed this branch anywhere yet, or
- You’re using Git, and you know for sure that other people will not have checked out your feature branch
- Otherwise, merge the latest base changes into your feature branch
I hope this helps! Please let me know in the comments if you have any questions or suggestions.
