git can be configured to push and pull from many locations at once, enabling you to store your code on two different platforms while only maintaining one local copy. Here’s how to set it up.
The “remote” for a branch is a URL from where your local
git repo fetches changes. Your local
git repo is entirely yours—it isn’t affected by other people’s code until they push their commits to the remote. Hopefully, you’re all using the same remote and everything syncs up, but the remote is just an endpoint. You could clone that endpoint and switch to a new remote without much issue.
Whenever you clone a new repository, the default remote is set as “origin.” You can find the remotes for any given
git repo by running:
git remote -v
This will probably display the URL of your main repository on GitHub or whatever service you’re using. If you have multiple remotes, they’ll show up here, too.
But just because
origin is the default remote, it doesn’t mean you’re limited to one. Why would you want two remotes? Well, a good use case is AWS’s CodeCommit. It’s a hosted
git repository, and has many integrations with their EC2 compute platform, enabling for automated code deployments to your servers, directly from source control.
However, CodeCommit is pretty clunky compared to more focused
git providers like GitHub, GitLab, and BitBucket, and doesn’t have the same CI/CD integrations that make those providers great. So, you’re stuck with a dilemma—use CodeCommit as your default
git solution, or build your automated code deployment pipeline yourself.
However, with multiple remotes, you can easily push code to a second repository. Whenever you want to update your servers, you can push the changes from your primary source control to CodeCommit to start the deployment pipeline.
Setting Up Multiple Remotes
git this way is actually quite simple. You add remotes in the same way that you would push an existing folder, except instead of adding the “origin” remote, you give it a different name.
git remote add <name> <url>
Then, when you want to push to the second remote, add the remote name and branch to your push command:
git push second master
Or, switch the default remote using
git push --set-upstream second master
This is the simplest setup, however, it requires you to either pass the remote name as an argument, or switch the remote every time.
Really, if you’re using a two remote setup, you’ll probably want a better way to manage pushing code 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
git checkout -b deployment
Then, add the deployment remote:
git remote add deployment <url>
and fetch the master branch:
git fetch deployment master
Then, you can set 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 to keep track of multiple remotes. Remember, though, that this is only a local setup, so if you push this branch to your primary repository, others won’t have their copies of the deployment branch configured to use the second remote automatically.
It would be ideal if the second branch is only one way, meaning, you are only pushing code, not pulling new code, otherwise you may run into unexpected conflicts. Other than that,
git works perfectly fine with multiple remotes.