# Sourcetree fetch rebase

Ever the acolyte of Jenny Bryan when it comes to all things workflow, I try to follow Happy Git and GitHub for the useR as much as possible.

I’ve never been especially good at Git, per se, but the shell met my needs for a long time…a long time, that is, before I started working with a team that really uses GitHub for version control.

So, I decided to give Sourcetree a whirl. Though I’m definitely still wont to bork a repo now and again, I think the experiment has largely been a success.

Since I’m still in the early-ish stages of getting into a rhythm, I figured I’d write out the part that’s been trickiest for me to grok — keeping forks in sync with their “upstream” counterparts.

### The Setup

For getting a Git client set up, take a gander at the Install a Git client section of Jenny’s book. For Sourcetree specifics, the documentation, “Install and set up Sourcetree” really can’t be beat.

OK, so now you’ve got some local repos connected to Sourcetree. It should look something like this:

### Choose and open your project.

For this example, I was updating the usethis package.

You can change what branch you’re on once you’ve opened up the repo’s interface, but I do want to point out that you can already tell I’m on master from the index, since the name of the working branch is displayed on the right in the index.

To open that project, you simply double click the desired repo.

Once open, you can see where your fork of the repo is (origin/master), and where their repo is (upstream/master).

### Fetch from all remotes.1

If you don’t already have an “upstream” remote, you can set one up by clicking New Remote… in the Remotes menu.

To sync things up, you’ll want to fetch from all remotes.

### Merge and/or rebase the fetched commits.

After fetching, it’s time to either merge or rebase, depending on your needs. There’s a really nice explanation of the differences between the two in the Merging vs. Rebasing tutorial by Atlassian, which I recommend checking out if these words are foreign to you.

In this case I want to rebase, but first I need to choose the proper branch from which to do so, which is upstream/master.

After selecting the right branch, you can go ahead and click OK.

### Push your changes to master.

When this has completed, your local working copy should be up-to-date with upstream/master. However, your remote (origin/master) is still behind. This is because you have yet to push the changes.

After you click Push, double check that you are pushing to the correct fork and branch before clicking OK.

### And now you’re synchronised! 🎉

If all went according to plan, your fork should now be caught up with upstream, in which case you’re good to go!

1. Jenny Bryan wisdom: If you are on master locally and have not made any commits there that are unique to you, just pull master from upstream into it. That is the simplest. This reinforces/rewards the habit of never commiting directly to master on a repo that someone else largely controls. If you do that, you will always be able to pull straight into master. Then you can update your feature branches by merging master into them or rebasing them on master.