Did you know Git remotes can have multiple URLs, so when you run a command like git push origin main, it can update more than one Git repository?
I have a few situations where I thought this would be useful, where I need to mirror code between my and my client's Git repositories, or from my repository to a hosting environment to deploy a change.
Originally I used git remote add to add a second named remote, such as client or hosting, but this needed me to push twice - once to origin and once to the second remote.
Sometimes, this meant the repositories were out of sync until the second push was done and, if someone forgot to do it, code someone else was expecting to be on the second remote wasn't available.
Adding a second URL to origin seemed like a good fix.
Pushing once would update both remotes and everything would be in sync.
But, it wasn't always the case.
If the first push to origin failed, Git doesn't stop.
It continues to push to the second repository, meaning there would be commits in one remote and not the other.
This needed remedial work, such as manually running git pull and git merge to sync everything up again - and also creating merge commits, which I'm not a fan of.
There's also no opportunity to check the CI pipeline checks passed before pushing to a hosting environment.
Having to do a manual push allows you to check the pipeline run was successful and the tests, etc, passed before pushing potentially broken code to the hosting environment.
Here's the thing
There are pros and cons to both approaches and the right option will depend on each person's and team's situation.
For now, I'm switching back to having separate remotes and doing two pushes.
- Oliver
Was this interesting?
About me
I'm an Acquia-certified Drupal Triple Expert with 17 years of experience, an open-source software maintainer and Drupal core contributor, public speaker, live streamer, and host of the Beyond Blocks podcast.