Using Azure Repos as the primary source and GitHub as a backup mirror

A publishing platform becomes infrastructure once the repository owns deployment, DNS notes, automation scripts, and incident records. At that point, keeping code in only one remote is unnecessary risk.

The decision for HWMOON is:

Azure Repos = primary operational source
GitHub      = external backup mirror

This is not a “push everywhere and hope” model. The important part is defining which remote is authoritative.

Why Azure Repos Is Primary

The deployment workflows are already connected to Azure DevOps. Pipelines, service connections, Static Web Apps deployment, and self-hosted agents are all closer to Azure Repos than to GitHub.

That makes Azure Repos the natural primary source for:

• pull requests
• pipeline triggers
• deployment history
• Azure DevOps permissions
• operational audit trail

Moving the primary workflow to GitHub too early would create more moving parts without solving the immediate operational problem.

Why GitHub Still Matters

GitHub is valuable as an external recovery point.

The risks are not daily risks, but they are real:

• Azure DevOps organization access problems
• credential or PAT expiration
• accidental repository configuration drift
• tenant or subscription migration
• local workstation failure
• self-hosted agent failure

If Azure DevOps is unavailable or misconfigured, a recent GitHub mirror shortens the recovery path. The backup remote also makes it easier to share selected work publicly later.

Role Separation

The operating model is:

Remote	Role	What it owns
Azure Repos	Primary	PRs, pipelines, deploys, operational history
GitHub	Backup mirror	external copy, recovery point, future public portfolio

The rule is that GitHub should not silently become the deploy source. If a future migration changes that, it should be an explicit architecture change.

Practical Git Shape

The local repository can keep both remotes:

git remote -v

Conceptually:

origin  -> Azure Repos
backup  -> GitHub

Routine development still flows through Azure Repos. Backup push can be manual or automated later, but it should be observable. A mirror that nobody checks is not a real recovery mechanism.

What Not To Mirror

The repository should not contain secrets just because there is a backup remote.

Do not mirror:

• deployment tokens
• PATs
• private keys
• .env files
• unmanaged production secrets

Backup strategy does not replace secret management. It only protects source and documentation history.

Verification

A backup remote is healthy when these are true:

latest primary commit exists in Azure Repos
same commit or accepted lag exists in GitHub
repository can be cloned from GitHub
no secrets are present in mirrored source
deployment still triggers only from the intended primary remote

This is especially important for infrastructure repositories. A backup that changes deployment behavior is no longer just a backup.

Decision

Azure Repos remains the primary operational repository because it is closest to the deployment system. GitHub remains a backup mirror because it gives the project an external recovery point and a future path for public portfolio presentation.

That separation keeps the current workflow stable while reducing platform lock-in risk.