git can be configured to push and pull from multiple locations at once, allowing you to store your code on two different platforms while keeping only one local copy. Here’s how to set it up.
Remote controls, explained
The “remote control” for a branch is a URL from which your local git repository gets the changes. Your local git repository is entirely yours – it is not affected by other people’s code until they push their commits to the remote. I hope you are all using the same remote control and everything is synchronizing, but the remote control is just an endpoint. You can clone this endpoint and switch to a new remote control without much problem.
Each time you clone a new repository, the default remote control is set to “home”. You can find the remotes for any given git repository by running:
git remote -v
This will likely display the URL of your main repository on GitHub or any other service you use. If you have multiple remotes, they will also appear here.
But just because the origin is the default remote control, it doesn’t mean that you are limited to one. Why would you want two remotes? Well, a good use case is that of AWS CodeCommit. It is a hosted git repository and integrates many integrations with their EC2 calculation platform, allowing automated code deployments on your servers, directly from source code control.
However, CodeCommit is pretty clunky compared to more targeted Git providers like GitHub, GitLab and BitBucket, and doesn’t have the same CI / CD integrations that make these providers excellent. So you are faced with a dilemma: use CodeCommit as the default git solution or create your own automated code deployment pipeline yourself.
However, with multiple remotes, you can easily push the code to a second repository. Whenever you want to update your servers, you can push changes from your primary source control to CodeCommit to start the deployment pipeline.
Configuration of several remote controls
Using git this way is actually quite simple. You add remote controls the same way you would push an existing folder, except that instead of adding the “original” remote, you give it a different name.
git remote add
Then, when you want to push to the second remote control, add the name of the remote control and the branch to your push command:
git push second master
Or, change the default remote control using –set-upstream:
git push –set-upstream second master
This is the simplest configuration, however, it requires you either to pass the name of the remote control as an argument, or to change the remote control each time.
Really, if you’re using a two remote control configuration, you’ll probably want a better way to handle code transmission to your second remote. The best way to handle this in git is to create another branch for code pushed to the second upstream, such as deployments to AWS CodeCommit.
You can create a branch with checkout -b:
git checkout -b deployment
Then add the deployment remote control:
git remote add deployment
and get the main branch:
deployment master git fetch
Then you can define the upstream for the current branch by running:
git branch –set-upstream-to = deployment / master
You can repeat this process for any number of branches, making it a great method for keeping track of multiple remotes. Remember, however, that this is only a local configuration. If you transfer this branch to your main repository, the others will not have their copies of the deployment branch configured to automatically use the second remote control.
It would be ideal if the second branch is only one way, which means that you are just pushing code, not pulling new code, otherwise you might run into unexpected conflicts. Apart from that, git works perfectly with multiple remotes.