Skip to main content

Setting an upstream Git branch

First posted in Development and Git; updated 1st April 2021

There’s no such thing as syncing in Git, but setting an upstream branch is about as close as it gets. What that means is you match a branch on your local development environment to a branch on the remote repository (repo), up in GitHub, GitLab or wherever.

Pushing and pulling without an upstream

By default, you can push and pull changes from any branch on your remote to the local branch you’re currently sitting on.

So if you’re checked out on a branch called my-great-feature you can push a branch of the same name to the remote like this:

git push origin my-great-feature

If a branch called my-great-feature doesn’t already exist up there, that command will create one with that name, based on your local branch.

To push more changes up there, just repeat the command.

If you’re working with someone else, or have been working on the same branch from two separate machines, you can pull changes down like this:

git pull origin my-great-feature

I tend to push my work up to the remote when it’s ready for PR (Pull Request), so my feature branches don’t typically live all that long once they’re on the remote repo. That means I’m generally happy to write those longer commands when pushing and pulling.

Pushing and pulling with an upstream

Every now and again, if I know I’ll be pushing and pulling a fair bit over the life of a feature (or setting up a ‘forever’ branch like develop or staging), setting an ‘upstream’ makes things quicker.

The flag to set an upstream branch is --set-upstream-to; that’s a lot to type! Luckily there’s a shorthand:

git push -u origin my-great-feature

This creates a branch on your remote called my-great-feature and links it to your currently checked out local branch via the -u flag. If the my-great-feature branch already exists up on your remote, it just creates the link between it and your local branch.

It’s worth mentioning here that your local branch has to be called my-great-feature for this to work. If you want your remote branch to have a different name to your local branch, say our-great-feature, you need to be explicit:

git push -u origin my-great-feature:our-great-feature

From there on in, when you push and pull from your local my-great-feature branch, you won’t need to tell Git the name of the the remote repo and branch you’re pushing/pulling to/from again: all you need is git push and git pull!

Accessibility in your inbox

I send an accessibility-centric newsletter on the last day of every month, containing:

  • A roundup of the articles I’ve posted
  • A hot pick from my archives
  • Some interesting posts from around the web

I don’t collect any data on when, where or if people open the emails I send them. Your email will only be used to send you newsletters and will never be passed on. You can unsubscribe at any time.

More posts

Here are a couple more posts for you to enjoy. If that’s not enough, have a look at the full list.

  1. Alt text for CSS generated content

    There’s an interesting feature in Safari 17.4 that allows content added with CSS to have ‘alt’ text. I’m not sure how I feel about this.

  2. The accessibility conversations you want to be having

    In most companies, accessibility conversations centre around WCAG compliance, but that’s just the start. Thinking beyond that is where you want to be!