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.
This update contains many enhancements and bugfixes primarily to interactive rebase functionality. Check the release notes for more information.
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:
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.
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.
Our designer gave us a treat with a new icon set making the user interface look even more satisfying!
Check out the release notes for more information.
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).
SourceTree for Windows simplifies how you interact with Git repositories so you can focus on coding.
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.
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.
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.
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.
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.
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:
We will continue to push out frequent releases for the Mac client. Stay tuned for an upcoming release featuring:
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.
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!
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.
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:
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!
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?
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?
Merging Pros
Merging Cons
Rebase Pros
Rebase Cons
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.
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.
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:
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.
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.
I hope this helps! Please let me know in the comments if you have any questions or suggestions.
Note: for brevity this article refers to Git and git-flow, but SourceTree supports exactly the same concepts in Mercurial via Hg Flow too.
In early 2010, Vincent Driessen wrote an article called “A successful Git branching model” which recommended an approach called git-flow to use git branches in your development cycle. The idea was to standardise branching and merging when developing features, handling releases and managing hot fixes, in order to be consistent and gain the advantages of git’s ‘branchy’ development model. Using many separate branches in Git gives you lots of flexibility, but it can get complex. Adopting a standardised approach has many advantages:
SourceTree 1.5 now integrates with git-flow and presents it to you in a friendly and intuitive way.
The general idea of git-flow is to use the following branch structure in your repository:
SourceTree helps you utilise these branches via git-flow actions which we will describe below.
There’s a handy new addition to the toolbar in SourceTree 1.5 (keyboard shortcut Cmd-Alt-F):
Based on the current state of the repository, the Git-flow button will bring up a dialog with the most likely action you’d want to perform next. So if you haven’t set up git-flow on this repo yet, it’ll help you do that by default. If you’re on the development branch, it will default to starting a new feature. If you’re already on a feature branch, it will offer to finish your current feature and merge it back into the development branch, and so on. You can always get to all the other git-flow actions via this button as well, but most of the time the default option will be the action you’ll want SourceTree to perform.
If you haven’t used git-flow already on this repository, the first thing SourceTree will do is initialise your repository to use it. You’ll probably just want to use the defaults in the initialisation window so that’s not covered here. For more details please see the Help section included in SourceTree. Next up, we’ll concentrate on the actions we can perform with Git-flow and SourceTree.
You can commit trivial changes directly to the development branch (‘develop’) if you like, but any time you start on something non-trivial you should explicitly start a new feature. This ‘Start Feature’ action will be the default action when you click the Git-flow button if you are currently on the dev branch.
The first thing to note is the ‘Preview’ window, which is present on all of the action dialogs and shows you what will actually happen when you confirm the dialog. In this case, a new feature branch called ‘feature/my-new-feature’ will be created (I used the default prefix when I initialised this repository). You commit your feature implementations to this branch. If you want, you can push the feature branch to your remote while you work on it (your team can decide on whether that’s normal practice or not).
If at any time you want to switch branches, either to another feature branch or to somewhere else, just use the normal mechanisms in SourceTree to do that, such as double-clicking a log entry or a branch in the sidebar. Git-flow determines your context simply from the branch you currently have checked out, so it’s fine to jump around if you like.
Eventually when you’re done implementing a feature, use the ‘Finish Feature’ action (again, this will be the default action from the toolbar button if you’re on a feature branch):
Again, the Preview shows you what will happen — the feature branch will merge into the main development branch, essentially queueing it for inclusion in the next release. Feature branches are deleted by default but you can opt to retain them if you like.
You start a release branch when you want to start preparing a new release, which probably coincides with a feature freeze. Accessing the Start Release option –either from the menu or from the toolbar action selection window — brings up the following dialog:
The preview shows that a new release branch will be created. Most of the time, you want to start the release from the latest commit in the development branch, but you can choose to base it on another commit if you wish. This essentially freezes the release, so it’s not affected by subsequent development. You can also perform preparatory tasks for the release process on this branch, such as updating the version number in source files, updating changelogs, or committing other tweaks. Once these tweaks are done, you can finish the release as described below.
Once all the adjustments required for the release are done and committed, you can conclude the release process.If you’re on the release branch already, the git-flow button will show you the following dialog:
The preview illustrates that the release branch will be merged into the production branch (‘master’ or ‘default’ normally) to indicate an update to the deployed version. Sourcetree will also create a tag here for the release. The release branch changes will also merge back into the development branch to make sure the develop branch is kept up to date.
What if you need to just fix a bug on the latest release? You don’t want to create a new release, because that will pick up the recent changes from the development branch. So instead, you can start a hot fix:
Hot fixes always start from the latest production code from the ‘master’ or ‘default’ branch. Other than that, they’re basically the same as release branches. Moreover, when you’re finished with the hot-fix, they behave the same way as finishing a release branch. The changes are merged back into both the production branch and the development branch, and a tag is created on the production branch for the hot fix release.
Git-flow is a great way to automate your handling of branch-based development in Git, and SourceTree now provides a simple and clear way to use it with an easy-to-use and intuitive GUI. Big thanks to Vincent Driessen for coming up with git-flow in the first place!
Try the Git-flow workflow yourself with Sourcetree 1.5!
Apple wowed us all at WWDC this year with the introduction of a stunningly beautiful Retina display to the MacBook Pro — cranking up the resolution to an eye-watering 2880×1800 and making all text and vector graphics immediately twice as sharp as before.
Unfortunately, bitmap graphics can’t automatically take advantage of this improvement. When placed next to this super-sharp text and line drawings, standard resolution icons look decidedly fuzzy on a Retina display, which clearly was not acceptable. So like many other Mac app developers, we’ve revisited our icons and upgraded them to look their best.
I’m glad to announce that SourceTree 1.5.1 includes, among other things, a full set of upgraded icons, meaning everything now looks crisp and lovely on Retina displays – you can see the difference by clicking on the image below. Enjoy!
Pretty, huh? Download 1.5.1 for free today!
Steve Streeting has made it his mission to reach out to SourceTree users and listen to what they have to say. In the last couple months, he’s even traveled to San Francisco from his hometown in the UK, hosting a drinkup to meet SourceTree customers face to face. He’s taken your feedback and pushed out some of the features you’ve asked for in the latest release – SourceTree 1.5!
A development model first published by nvie, Git-flow (and its Mercurial equivalent – Hg-flow) organizes your repositories by formalizing the use of feature branches, releases, and hot-fixes. SourceTree 1.5 now lets you adopt this model, so you can unclutter your repository and develop stress-free.
Sometimes, you need to revert a change that you made, but undoing an entire commit can be painful. Whether you want to reverse a change made in a line, a chunk of code, or an entire file, SourceTree 1.5 now gives you that power. Highlight the changes you want to reverse and click reverse. Take complete control over your code — the way it should be.
Bitbucket Teams let you create a shared account in Bitbucket to consolidate your team-owned repositories and organize your group’s work. SourceTree now gives you options to configure Teams settings when you create a hosted repository. Easily collaborate on code using SourceTree and Bitbucket.
In addition to bug fixes, we’ve added a couple more of the features you’ve asked for. To name a few:
Give the new release a try! Download it for free today!
Calling all eager beta testers! SourceTree’s next major release, version 1.5, is now available for you to try out in beta form. As ever we have a bunch of great new features for you, and we’d love to get your feedback.
Probably the leading headline in this release is support for git-flow and hg-flow, but there are lots of others things too, please read the full release notes for details.
Download SourceTree 1.5 beta 1
You can have both the 1.5 beta and the stable 1.4.4 release installed on the same machine if you wish, but don’t run them both simultaneously, that will cause some clashes.
We hope you enjoy using the new release! If you encounter any issues, please raise them on the JIRA tracker. Thanks!
