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.
Remotes, Explained
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:
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
Using 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.
Then, when you want to push to the second remote, add the remote name and branch to your push command:
Or, switch the default remote using –set-upstream:
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 checkout -b:
Then, add the deployment remote:
and fetch the master branch:
Then, you can set the upstream for the current branch by running:
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.
