Why I Built RepoFileSync

The Problem That Wouldn't Go Away

I kept running into the same problem. Every project I worked on that had more than a handful of repositories had the same pain point: keeping shared files in sync.

ESLint configs, CI workflows, Dependabot settings, license files, editor configs — these files need to be the same (or at least consistent) across every repo. And they never are.

It starts small. You update the ESLint config in one repo, forget to update it in two others, and a week later someone opens a PR that passes linting in their repo but would fail in the repo next door. Multiply that by 20 or 50 repos and it becomes a constant low-grade headache.

Why Existing Approaches Fall Short

I tried everything before building RepoFileSync.

Monorepos

The obvious answer is "just use a monorepo." And for some teams, that works. But monorepos come with real costs:

• You lose fine-grained access control between projects
• CI gets complicated fast — you need tooling to figure out what changed and what to build
• Repository size becomes a problem over time
• Teams lose autonomy over their release cycles

If you already have 30 separate repos with different teams owning them, migrating to a monorepo is a massive undertaking that most organizations will never prioritize.

Copy-paste scripts

The next thing I tried was writing shell scripts that would clone repos, copy files, commit, and push. This works exactly once. Then someone changes the directory structure in one repo, or a file needs slight variation for a specific project, or the script fails silently on repo #17 and you don't notice for a month.

Scripts also don't give you any visibility. You can't easily answer "which repos have the latest version of this file?"

GitHub's reusable workflows

For CI workflows specifically, GitHub's reusable workflows and composite actions help. But they only cover Actions files — they don't help with ESLint configs, Prettier settings, Dependabot configs, license files, or anything else.

Template repositories

GitHub template repos are great for setting up new repos, but they're a one-time copy. Once a repo is created from a template, there's no ongoing connection. Update the template and existing repos don't get the change.

What I Actually Wanted

The tool I wanted was simple:

1. Define which files in a source repo should be synced to which target repos
2. When a source file changes, automatically open PRs in the target repos with the update
3. Let teams review and merge on their own schedule
4. Show me a dashboard of what's in sync and what's drifted

That's it. No migration, no restructuring, no new CI paradigm. Just keep files in sync across repos through pull requests — the workflow developers already use.

How RepoFileSync Works

RepoFileSync does exactly that. You connect your GitHub account, pick a source repo, define sync rules for specific files, and select target repos. When you trigger a sync (or when it detects changes), it opens PRs in each target repo with the updated files.

The key design decisions:

• PR-based: Changes go through pull requests, not direct pushes. Teams review and merge. Nothing happens without approval.
• Selective syncing: You pick exactly which files to sync. Not everything needs to be identical across repos.
• Dashboard visibility: You can see at a glance which repos are up to date and which have pending PRs or have drifted.
• No migration required: Works with your existing repos as they are. Install, configure rules, sync.

Who This Is For

RepoFileSync is for teams managing multiple GitHub repositories that share common configuration. If you've ever spent an afternoon updating the same file across a dozen repos, or discovered that a security policy was missing from half your repos, this is the tool I wish I'd had.

It's not a replacement for monorepos if a monorepo genuinely fits your team. It's for everyone else — the teams that have multiple repos for good reasons and need a practical way to keep them consistent.

What's Next

I'm building RepoFileSync in the open and iterating based on real usage. If this problem resonates with you, I'd genuinely like to hear about your setup and what would make this tool useful for your team.