Git forks and upstreams: a how-to with cool tips

Work smarter, better, and faster with weekly tips and how-tos.

There are tonsandthensome useful guides on how to keep your forks updated against the upstream repositories (and if you’re wondering why you would want to use forks in an enterprise setting, check out a few reasons here). In this blog I will introduce you to few aspects of how forking interacts with

Work smarter, better, and faster with weekly tips and how-tos.

In this blog I will introduce you to few aspects of how forking interacts with upstream: the basics, the gotcha’s, and an cool tip. To top it off I will then make you very jealous, or very eager, the choice is yours. Interested? Read on.

The base workflow to keep up-to-date and contribute

Let me start by detailing a common setup and the most basic workflow to interact with upstream repositories.

In a standard setup you generally have an origin and an upstreamremote – the latter being the gatekeeper of the project or the source of truth to which you wish to contribute to.

First, verify that you have already setup a remote for the upstream repository – and hopefully an origin too:

If you need to squash a few commits into one you can use the awesome rebase interactive at this point.

After the above, publish your work in your remote fork with a simple push:

git push origin feature-x

A slight problem rises if you have to update your remote branch feature-x after you published it, because of some feedback from the upstream maintainers. You have a few options:

Create a new branch altogether with the updates from you and the upstream.

merge the updates from upstream in your local branch which will record a merge commit. This will clutter the upstream repository.

Rebase your local branch on top of the updates from upstream and do a force push onto your remote branch:

git push -f origin feature-x

Personally I prefer to keep the history as clean as possible and go for option three, but different teams have different work flows. OBVIOUS ALERT!! You should do this only when working with your own fork. Rewriting history of shared repositories and branches is something you should NEVER do.

Tip of the day: Ahead/Behind numbers in the prompt

After a fetch, git status shows you how many commits you are ahead or behind of the remote the branch it syncs to. Wouldn’t it be nice if you could see this information at your faithful command prompt? I thought so too so I started tapping with my bash chopsticks and cooked it up.

Here is how it will look on your prompt once you configure it:

nick-macbook-air:~/dev/projects/stash[1|94]$

And this is what you need to add to your .bashrc or equivalent, just a single function:

Conclusions

I hope this basic walk-through on upstream is useful for those unfamiliar with the process. Also note that the latest uber-fresh Stash release includes fork synchronization which basically relieves the developer from all the burden of keeping up to date with its forks, check it out!