How to Add a Second Remote to a Local Repository

Github pages is a free hosting site that is perfect for single page apps. I love using it for that. However, it is frustrating that the only way to track commits to a gh-pages repository is when you update the page or create issues, as the gh-pages takes over as the “master” branch of any other repository. And every deployment is a single commit.

The commits you make on other branches are still tracked on those branches, but it can be hard to pinpoint when you made massive changes to your repository unless you’re constantly deploying changes to gh-pages. It might help in finding when introduction of a bug might have taken place by pushing another copy of the code so you can track changes while working in a development environment. I decided I wanted to create a second repository to do just that.

This how-to assumes you already have a remote origin, but if not follow the steps to create a remote repository for your local repository here: https://gist.github.com/mindplace/b4b094157d7a3be6afd2c96370d39fad

Test that your remote origin is working by entering git remote -v in your command line. You should get something like:

origin    git@github.com:<repository> (fetch)
origin    git@github.com:<repository> (push)

Make a second repository for this code. For my purposes, it is empty. Copy the address of the second repository which should look like git@github.com: <repository> . Add a remote like you would push to an existing folder, but give it a different name instead of “origin”, which is the default.

git remote add <shortcut-name-of-second-repository> <url>

Confirm that you’ve done this correctly by again using git remote -v. I’m giving it the shorthand name second. You should see this:

origin    git@github.com:<repository> (fetch)
origin    git@github.com:<repository> (push)
<second>    git@github.com:<different-repository> (fetch)
<second>    git@github.com:<different-repository> (push)

Now switch to your intended branch for this repository with git checkout -b <local-branch-name> , add all the files you want from your working directory like git add . , make the git commit -m "<message>" and use git push <second> master. You should now see the files in the second repository along with all the commits made earlier. However, this method does have a limitation. The origin branch is still present and is still the default when you use git push so you’ll have to specify the other remote name as an argument whenever you do so. You can set the push default branch as this second remote using git push --set-upstream <second> <master> . However, this means you are permanently changing your default and will need to manually push to origin’s branch any time you desire to do so.

If you want the specific local branch to only push to the second repository remote branch, you can do so with git branch --set-upstream-to=<second>/master or /branch-you-want-to-use . This way, you can have a specific branch tailored only to push to this repository and have the other local branches pushed to the original repository’s branches. Sometimes you might receive an error because your local branch is not the same name.

The upstream branch of your current branch does not match
the name of your current branch.  To push to the upstream branch
on the remote, use
git push second HEAD:master
To push to the branch of the same name on the remote, use
git push second HEAD

In my case, I used git push second HEAD:master .

Season 2 Timeline GIF by Rick and Morty - Find & Share on GIPHY

This process can be useful for other reasons, such as keeping deployments to its own upstream branch. You can repeat this method for any number of local branches, a good method to keep track of multiple remotes. However, since this is only a local setup, any other contributors to the repository will not have the same configuration. Their deployment branch will not automatically push to the same remote. Configure your workflow however you think is best.

I am also only using this to keep copies of the code to monitor my activity on github and to help track down any code that may have been a source of bugs. The second branch only goes one way — I’m not pulling from the second remote. You may experience conflicts if you do. Otherwise, this works well and I’ve learned a little more about how git remote and local branching works. Hopefully it helps someone else out.