Blog

So, I’m in a couple of projects where all developers have push access to a Github repository, but we’d like all developers to move over to using a pull-request based workflow to encourage code reviews. This often results in people just doing work in a branch, pushing the branch to the common repo and then doing a PR from there.

This works fine, but creates a lot of branches in the main repo. Also we’ve had minor incidents where people forgot to create a branch, and pushed unreviewed commits directly to the master branch. I usually recommend people to do their work in a fork – a copy of the codebase under your github account.

Now, if you go ahead and clone your fork into a new folder on your local machine, when you already had a working setup towards the original repo in another folder, you’ll need to change a lot of things, paths in your IDEs and editors etc, probably download half an internet worth of NPM packages and so on, so it’s much simpler IMHO to just update the “remotes” on your current repo workspace folder to look like they would if you’d cloned your fork.

This is achieved like this. Let’s assume the original repo is https://github.com/megacorp/enterprisey and you already have a working setup in the folder C:\dev\megacorp\enterprisey

• Create your fork by browsing to the https://github.com/megacorp/enterprisey repo in Github, and press the “fork” button
• Then select your github user as the destination of the fork. This will create a fork named https://github.com/your_username/enterprisey
• Then, in your original working folder (C:\dev\megacorp\enterprisey) run the following git commands;

git remote set-url origin https://github.com/your_username/enterprisey.git
git remote add upstream https://github.com/megacorp/enterprisey.git

That’s it! The only change in workflow after that, is that you need to remember to say git pull upstream (or git fetch upstream) to get the latest stuff from the common repo (the megacorp one, that is). Now, there are ways to configure git to default pulls to upstream instead of origin, but I don’t think it’s an improvement.

The whole point of this will be that, now, when you do git push it’ll send your stuff to your fork, instead of to the common repo, which keeps the number of branches in the common repo down, as well as minimizing the risk of pushing unwanted stuff to your common master.

Then when you want to do a PR from your fork to the common master, it’ll be just as simple as before, as github already knows about your fork, and will prompt you if it notices a new branch in your fork.