How to make a bidirectional GitHub Repository Sync
Briefly

How to make a bidirectional GitHub Repository Sync
"I had a main repository ( primary-repo) and needed a mirror ( mirror-repo) for white-label deployment. The obvious culprits did not work: Git forks? No way. Everyone sees it's a fork, and GitHub Actions get wonky Manual syncing? If you enjoy repetitive labor and midnight rollbacks, sure One-way mirroring? Close, but I needed bidirectional due to reasons (organizational politics, mainly)"
"Organizational boundaries - Some outside collaborators need repo access to particular branches, without exposing the entire codebase White-label isolation - Each brand seems standalone Compliance stuff - Some customers require code in specific GitHub orgs/repos Independent pipelines - Each brand's secrets, configs, and CI/CD workflows are theirs alone The Nitty-Gritty Bi-directional sync - Repos must sync both ways Triggering the workflow - Sync needs to trigger CI/CD automatically Conflict resolution - We're engineers, we create conflicts"
"I split this into three reusable GitHub Actions: setup-git-sync -Configures SSH keys, Git remotes, all the boring setup check-sync-changes - Checks if repos actually differ (saves CI minutes) sync-branches - Does the actual rebase and push to both repos The Implementation Step 1: SSH Keys GitHub PAT pushes don't run workflows. It's a security measure to prevent infinite loops. But SSH deploy keys? They trigger workflows nicely."
A main repository and a mirror repository needed to remain identical while allowing changes from either side and triggering automatic deployments. Organizational boundaries, white-label isolation, compliance, and independent pipelines required separate repos and pipelines per brand. Requirements included bidirectional synchronization, automatic CI/CD triggering, conflict resolution, efficiency in GitHub Actions minutes, and observability. The solution used three reusable GitHub Actions: setup-git-sync, check-sync-changes, and sync-branches. SSH deploy keys were used because GitHub PAT pushes do not run workflows; deploy keys trigger workflows and avoid infinite-loop prevention. The approach checks for differences before syncing and rebases and pushes branches between repositories.
Read at Medium
Unable to calculate read time
[
|
]