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!
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.ā©