Pull Sourcetree

Repository Management

A free Git GUI client for Windows and macOS. Use the full capability of Git and Mercurial in the SourceTree desktop app. Manage all your repositories, hosted or local, through SourceTree's simple interface. GitHub pull requests are just branches. So you can get at least them by just adding them to your fetch spec. See Basically, PRs are at `refs/pull/./head`, while the branches you're used to working with are at `refs/head/.`.

CMD+0

Opens the Repository Browser window.

CMD+SHIFT+H

Show the Repository Browser and select the Remote section.

Prompts to add selected repositories to the Repository Browser.

UI Customization

CMD+SHIFT+K

Toggle the current repository's sidebar (branches, tags, and more.)

CMD+CTRL+W

Toggle the current repository's command history to view details.

CMD+1

Switch to the file browser and commit preparation area.

CMD+2

Switch to the primary commit history browser area.

CMD+3

Switch to the commit history search area.

Toggle the visibility of branch labels in commit history graphs for all repositories.

Toggle the visibility of tag labels in commit history graphs for all repositories.

Toggle the visibility of the Build Status column in the History view for the current repository.

Pull Sourcetree

Git Actions

CMD+SHIFT+F

Retrieve the current repository's branches, tags, and history from the remote server.

Start interactively updating a branch's content to align with another.

Connect another repository to act like a descendent of the current repository, instead of a remote dependency.

CMD+SHIFT+-

Remove the selected item(s) from the staging area prior to committing.

Mercurial Actions

CMD+SHIFT+U

Retrieve the current repository's state from the remote server.

Save an archival copy of the repository.

Repository Actions

Configure and migrate the current repository to Bitbucket Cloud.

CMD+SHIFT+,

Configure settings for the current repository.

CMD+R

Reload the current repository's commit history graph, file status, and build status.

CTRL+OPTION+R

Reload the current repository's status from the remote server.

CMD+SHIFT+C

Go to current repository's File Status view, focus the message editor, and populate with a message template if available.

CMD+SHIFT+R

Begin reverting one or more of the current repository's in-progress changes.

CMD+SHIFT+S

Save the current repository's in-progress changes for later use.

War thunder youtube. CMD+SHIFT+P

Send local commits for the current repository to the remote server.

CMD+SHIFT+L

Retrieve any new commits for the current repository from the remote server.

CMD+OPTION+U

Switch to a particular branch or revision in the current repository.

CMD+SHIFT+B

Create a new branch from the currently active branch.

CMD+SHIFT+M

Start the process of combining the target branch into the active one in the current repository.

CMD+SHIFT+T

Create a new tag for the active branch and commit in the current repository.

Connect a new remote server to the current repository.

Connect another repository as a dependency for the current repository.

CMD+SHIFT+W

Open the remote server's website (if available) for the current repository.

CMD+OPTION+P

Start a pull request on the remote server for the current active branch.

Item Actions

CMD+SHIFT+O

Open the selected item(s) for the current repository.

Open a new Finder window with the selected item(s) for current repository highlighted.

CMD+CTRL+T

Open a new Terminal window to the directory for the current repository.

Space

Display a preview of the selected item(s)'s contents if possible.

Open the assigned application (see Preferences) to display the item's changes.

Save the current repository's in-progress changes as a file for transfer or later use.

Take the contents of a patch (file or text) and merge them into the current repository if possible.

CMD+SHIFT+=

Add the selected untracked item(s) to the current repository's index, making them available for commit.

CMD+Delete

Remove the selected item(s) from the current repository's index and on-disk; requires a commit to save.

CMD+OPTION+SHIFT+=

Combines the Add and Remove actions (see their entries) into a single task for all the selected item(s).

Remove the selected item(s) from the current repository's index; requires a commit to complete.

Create entries (specific patterns, file types, or other designations) for items that should be ignored completely in the current repository.

Ensure the selected item(s) are included in the current commit and focus the message editor, populating with a message template if available.

CMD+OPTION+R

Begin reverting in-progress changes for the selected item(s).

Begin reverting the selected item(s) to a specific point in their history.

Proceed to the next step of an in-progress action such as rebasing or grafting.

Stop an in-progress action such as rebasing or grafting.

CMD+OPTION+L

Show a list of commits specific to the selected item in reverse chronological order.

CMD+OPTION+B

Display the contents of the selected item, as lines, with the latest commit's information (author, date, metadata) alongside.

Create a copy of the selected item(s) in the current repository using appropriate source control mechanisms.

Move the selected item(s) from one location to another (including renaming) in the current repository using appropriate source control mechanisms.

Resolving Conflicts

Open the diff for the conflicted item(s) in the application specified in Preferences -> Diff.

Choose the contents of the current branch when there's a conflict.

Choose the contents of the branch that you are merging when there's a conflict.

Cancel an in-progress merge.

Update the selected item(s) to indicate conflicts were resolved manually.

Update the selected item(s) to indicate a conflict or other problem exists still.

Git LFS

Configure the necessary changes to enable Git LFS for the current repository.

Add or remove the selected item(s) from the Git LFS index and storage when pushing.

Fetch any LFS changes from the remote for the current repository and then checkout appropriate files.

Retrieve LFS changes from the remote for the current repository.

Retrieve large file content from the Git LFS storage endpoint to replace existing placeholder files in the current repository.

Remove LFS item(s) that have been checked out into the current repository. This frees up space if they are unused.

Git/Hg Flow

Configure Flow prefixes for the current repository.

CMD+OPTION+F

Begin the next Flow action based on what's currently in progress for the current repository.

Create a branch with the feature prefix and specified name.

Wrap up the in-progress Flow feature branch.

Create a branch with the release prefix and specified name.

Wrap up the in-progress Flow release branch.

Create a branch with the hotfix prefix and specified name.

Wrap up the in-progress Flow hotfix branch.

Text Formatting

CMD+OPTION+-

Wraps the selected text in Markdown syntax for a header.

CMD+OPTION+SHIFT+-

Inserts the Markdown syntax for a single line.

CMD+B

Wraps the selected text in Markdown syntax to be bold.

CMD+I

Wraps the selected text in Markdown syntax to be italicized.

CMD+L

Inserts the Markdown syntax for a bullet at the start of selected text.

CMD+OPTION+O

Inserts the Markdown syntax for a number sequence at the start of selected text.

CMD+'

Wraps the selected text in Markdown syntax to be formatted as code.

CMD+OPTION+K

Wraps the selected text in Markdown syntax for a link, focused to edit the URL portion.

Notes

  • New user? Check out Getting Started with Sourcetree.
  • Need help? Join the Atlassian Community today!
  • Created in January 2018 by Brian Ganninger.

The core idea behind the Feature Branch Workflow is that all feature development should take place in a dedicated branch instead of the master branch. This encapsulation makes it easy for multiple developers to work on a particular feature without disturbing the main codebase. It also means the master branch will never contain broken code, which is a huge advantage for continuous integration environments.

Encapsulating feature development also makes it possible to leverage pull requests, which are a way to initiate discussions around a branch. They give other developers the opportunity to sign off on a feature before it gets integrated into the official project. Or, if you get stuck in the middle of a feature, you can open a pull request asking for suggestions from your colleagues. The point is, pull requests make it incredibly easy for your team to comment on each other’s work.

The Git Feature Branch Workflow is a composable workflow that can be leveraged by other high-level Git workflows. We discussed other Git workflows on the Git workflow overview page. Git Feature Branch Workflow is branching model focused, meaning that it is a guiding framework for managing and creating branches. Other workflows are more repo focused. The Git Feature Branch Workflow can be incorporated into other workflows. The Gitflow, and Git Forking Workflows traditionally use a Git Feature Branch Workflow in regards to their branching models.

Pull Sourcetree

How it works


The Feature Branch Workflow assumes a central repository, and master represents the official project history. Instead of committing directly on their local master branch, developers create a new branch every time they start work on a new feature. Feature branches should have descriptive names, like animated-menu-items or issue-#1061. The idea is to give a clear, highly-focused purpose to each branch. Git makes no technical distinction between the master branch and feature branches, so developers can edit, stage, and commit changes to a feature branch.

Sourcetree delete commit

In addition, feature branches can (and should) be pushed to the central repository. This makes it possible to share a feature with other developers without touching any official code. Since master is the only “special” branch, storing several feature branches on the central repository doesn’t pose any problems. Of course, this is also a convenient way to back up everybody’s local commits. The following is a walk-through of the life-cycle of a feature branch.

Start with the master branch

All feature branches are created off the latest code state of a project. This guide assumes this is maintained and updated in the master branch.

This switches the repo to the master branch, pulls the latest commits and resets the repo's local copy of master to match the latest version.

Create a new-branch

Use a separate branch for each feature or issue you work on. After creating a branch, check it out locally so that any changes you make will be on that branch.

This checks out a branch called new-feature based on master, and the -b flag tells Git to create the branch if it doesn’t already exist.

Update, add, commit, and push changes

On this branch, edit, stage, and commit changes in the usual fashion, building up the feature with as many commits as necessary. Work on the feature and make commits like you would any time you use Git. When ready, push your commits, updating the feature branch on Bitbucket.

Push feature branch to remote

It’s a good idea to push the feature branch up to the central repository. This serves as a convenient backup, when collaborating with other developers, this would give them access to view commits to the new branch.

This command pushes new-feature to the central repository (origin), and the -u flag adds it as a remote tracking branch. After setting up the tracking branch, git push can be invoked without any parameters to automatically push the new-feature branch to the central repository. To get feedback on the new feature branch, create a pull request in a repository management solution like Bitbucket Cloud or Bitbucket Server. From there, you can add reviewers and make sure everything is good to go before merging.

Resolve feedback

Now teammates comment and approve the pushed commits. Resolve their comments locally, commit, and push the suggested changes to Bitbucket. Your updates appear in the pull request.

Merge your pull request

Before you merge, you may have to resolve merge conflicts if others have made changes to the repo. When your pull request is approved and conflict-free, you can add your code to the master branch. Merge from the pull request in Bitbucket.

Pull requests

Aside from isolating feature development, branches make it possible to discuss changes via pull requests. Once someone completes a feature, they don’t immediately merge it into master. Instead, they push the feature branch to the central server and file a pull request asking to merge their additions into master. This gives other developers an opportunity to review the changes before they become a part of the main codebase.

Code review is a major benefit of pull requests, but they’re actually designed to be a generic way to talk about code. You can think of pull requests as a discussion dedicated to a particular branch. This means that they can also be used much earlier in the development process. For example, if a developer needs help with a particular feature, all they have to do is file a pull request. Interested parties will be notified automatically, and they’ll be able to see the question right next to the relevant commits.

Once a pull request is accepted, the actual act of publishing a feature is much the same as in the Centralized Workflow. First, you need to make sure your local master is synchronized with the upstream master. Then, you merge the feature branch into master and push the updated master back to the central repository.

Pull requests can be facilitated by product repository management solutions like Bitbucket Cloud or Bitbucket Server. View the Bitbucket Server pull requests documentation for an example.

Example

The following is an example of the type of scenario in which a feature branching workflow is used. The scenario is that of a team doing code review around on a new feature pull request. This is one example of the many purposes this model can be used for.

Mary begins a new feature

Before she starts developing a feature, Mary needs an isolated branch to work on. She can request a new branch with the following command:

This checks out a branch called marys-feature based on master, and the -b flag tells Git to create the branch if it doesn’t already exist. On this branch, Mary edits, stages, and commits changes in the usual fashion, building up her feature with as many commits as necessary:

Mary goes to lunch

Sourcetree pull rebase

Mary adds a few commits to her feature over the course of the morning. Before she leaves for lunch, it’s a good idea to push her feature branch up to the central repository. This serves as a convenient backup, but if Mary was collaborating with other developers, this would also give them access to her initial commits.

This command pushes marys-feature to the central repository (origin), and the -u flag adds it as a remote tracking branch. After setting up the tracking branch, Mary can call git push without any parameters to push her feature.

Mary finishes her feature

Sourcetree

When Mary gets back from lunch, she completes her feature. Before merging it into master, she needs to file a pull request letting the rest of the team know she's done. But first, she should make sure the central repository has her most recent commits:

Then, she files the pull request in her Git GUI asking to merge marys-feature into master, and team members will be notified automatically. The great thing about pull requests is that they show comments right next to their related commits, so it's easy to ask questions about specific changesets.

Bill receives the pull request

Bill gets the pull request and takes a look at marys-feature. He decides he wants to make a few changes before integrating it into the official project, and he and Mary have some back-and-forth via the pull request.

Mary makes the changes

To make the changes, Mary uses the exact same process as she did to create the first iteration of her feature. She edits, stages, commits, and pushes updates to the central repository. All her activity shows up in the pull request, and Bill can still make comments along the way.

If he wanted, Bill could pull marys-feature into his local repository and work on it on his own. Any commits he added would also show up in the pull request.

Pull Sourcetree

Mary publishes her feature

Once Bill is ready to accept the pull request, someone needs to merge the feature into the stable project (this can be done by either Bill or Mary):

This process often results in a merge commit. Some developers like this because it’s like a symbolic joining of the feature with the rest of the code base. But, if you’re partial to a linear history, it’s possible to rebase the feature onto the tip of master before executing the merge, resulting in a fast-forward merge.

Some GUI’s will automate the pull request acceptance process by running all of these commands just by clicking an “Accept” button. If yours doesn’t, it should at least be able to automatically close the pull request when the feature branch gets merged into master.

Meanwhile, John is doing the exact same thing

While Mary and Bill are working on marys-feature and discussing it in her pull request, John is doing the exact same thing with his own feature branch. By isolating features into separate branches, everybody can work independently, yet it’s still trivial to share changes with other developers when necessary.

Summary


In this document, we discussed the Git Feature Branch Workflow. This workflow helps organize and track branches that are focused on business domain feature sets. Other Git workflows like the Git Forking Workflow and the Gitflow Workflow are repo focused and can leverage the Git Feature Branch Workflow to manage their branching models. This document demonstrated a high-level code example and fictional example for implementing the Git Feature Branch Workflow. Some key associations to make with the Feature Branch Workflow are:

Git Pull Sourcetree

  • focused on branching patterns
  • can be leveraged by other repo oriented workflows
  • promotes collaboration with team members through pull requests and merge reviews

Create Pull Request Sourcetree

Utilizing git rebase during the review and merge stages of a feature branch will create enforce a cohesive Git history of feature merges. A feature branching model is a great tool to promote collaboration within a team environment.

Go one click deeper into Git workflows by reading our comprehensive tutorial of the Gitflow Workflow.

Next up:

Gitflow Workflow

Start next tutorial