Up

You want to have one primary GIT service (e.g. GitHub, GitLab, BitBucket, etc.) but duplicate that repository to another service/repository.

1. GIT push mirroring.
2. Multiple remotes.
3. Single remote, multiple urls/services

With GIT push mirroring, the primary repository automatically updates an secondary repositories when it receives changes.

See the documentation for configuring push mirroring provided by your primary GIT service (the process is specific to the service).

PROS:

• GIT command execution is the same as always.
• Setup is done once by the DevOps person, instead of on each development machine.

CONS:

• Requires support from the GIT service. For example, GitLab only includes Git Mirroring in it's paid packages.

This is simply adding multiple remotes to your local repository and pushing changes to each one after the other.

1. Execute the following command to add a second remote (repeat as needed)

git remote add <remote name> <git url>

2. Perform your GIT command(s) twice, once on each remote.

PROS:

• None

CONS:

• Easy to forget to send each GIT command twice.

This method adds multiple destination urls to a single GIT remote definition so any GIT command (e.g. push) only needs to be executed once.

1. Execute the following commands to add a new url to the origin remote (assuming your existing remote is called "origin").

git remote set-url --push --add origin <secondary service url>
git remote set-url --push --add origin <initial remote url>

IMPORTANT: The --push option tells GIT to only push to this remote. If you leave it off, all commands will be executed on all urls (e.g. pull commands would pull from both remote repositories).

NOTE: The second command is necessary as the first will override the push url of the original.

PROS:

• GIT command execution is the same as always.

CONS:

• Initial setup on each development machine is a bit more complex.