- there is a gatekeeper that manages merging to here
- all developers have write access
In this case, I’m working with the second option, so I’m pushing to the upstream repo. I’m also pushing to a live repository as well, so I thought I’d outline the commands I’m using. The setup here is the main github repo, and I have my own fork of that, which is cloned onto my laptop. I can push to both that main repo, which I’ll call “upstream” (because the github documentation does and it makes sense!) and another repo that I’ll call “live”. All in all it looks something like this:
Pulling in Changes
Keeping in sync with the upstream repo is the same as it is in any setup: we want to pull everything from upstream into our local clone of our own repo, then push back to our origin. Here’s both the diagram and the commands I’d use:
git pull upstream master git push
Note that when we
git push, that’s defaulting to the origin repository to push to. In the next section, we’ll push to other locations …
Pushing Changes to Other Destinations
I’ve got remotes added with the names you see on the diagram – the origin is added for me, and I’ve added the upstream and live repos as remotes. When I make a change on my local copy, in a system with a gatekeeper I would push it to my origin, then make a pull request.
In this setup though, I have the privileges to push changes into the upstream repo, and also to the live one (which triggers a live deployment, as you might guess). I’m literally pushing to two more destinations, here’s the diagram and code for this scenario:
git push upstream master git push live master
And there you have it – once we understand what goes where, we can push and pull between the other repositories really easily. Many setups will also work with branches other than master as well, this is just a simple example – where you see “master” in the commands, you can use another branch name.
Do you have a setup like this? Or something different? I’m interested to hear about it so perhaps you could leave me a comment?