Pushing to Different Git Remotes
- 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?
Super useful! I’m pretty new to git and this is a great explanation of a what is a seemingly complicated situation. Well done with the diagrams, its especially helpful to be able to visually see what is happening. Thanks!!
Hi! Thanks for this. More pragmatic Git usage here:
http://wiki.glitchdata.com/index.php?title=Git
Hi – in your first paragraph, you refer to Upstream, Live, and Local, but the illustration also shows Origin. You also refer to Origin in the next step. You say “Origin is added for me.” Is Origin the fork you refer to in the first step?
Yes, origin is the fork of the upstream. Hope that makes it a bit clearer!
Hi,
I want to do something similar, but I want to push everything to “upstream” as in your implementation, and only track and push specific folders to “live”. Any ideas will be much appreciated.
Changes in git are (in simple terms) all or nothing. If you want to deploy some changes to one place and some to another, then you probably want to maintain different branches. I’d *really* like to know why you’d want to deploy different code to the live platform than was tested on test, this isn’t usually recommended practice!
My question was going to ask you if “Origin” referred to your fork, but someone else asked that for me down below! :)
What is the purpose of pushing to your origin if you can push to upstream? and why is upstream not just the “live” repo? I hope you understand what I’m saying. I’m still learning and trying to understand git, so to get an idea of different use cases has really helped me to learn it easier.
Thanks!