Hey Daniel,

Great question—managing shared code across dozens (soon hundreds) of repos is tricky, especially when you're just getting started with Git/GitHub. Let's break this down for you.

Do branches that never merge into Master make sense for your workflow? #

Short answer: They can work in the short term, but they're not a sustainable long-term solution for your goal of reducing workload.

If you keep your shared CSS/JS in a separate branch (instead of merging to Master) and have your independent styles branches reference that shared branch, you can isolate shared code changes. But as you scale to 150 repos, you'll quickly run into pain points:

• You'll have to manually sync that shared branch across every single repo whenever you update the shared code.
• It's easy to end up with inconsistent versions of shared code across repos (some might be on an old commit of the shared branch, others on the latest).
• Debugging becomes harder because you can't easily track which version of shared code each repo is using.

So while this approach might work for 30 repos, it'll become a nightmare once you hit 150. Let's look at better alternatives.

Better solutions to reduce code change workload #

Since your core goal is to minimize the effort of updating shared code across all repos, here are the most practical approaches for your CSS/JS stack:

1. Publish shared code as a private npm package

This is the most scalable option for front-end shared code. Here's how it works:

• Create a dedicated repo for your shared CSS/JS (variables, utility classes, etc.).
• Package it as a private npm package (you can use GitHub Packages if you're using GitHub, since your repos are private).
• In each of your project repos, install this package via npm install @your-username/shared-styles (or whatever name you choose).
• When you update the shared code, bump the package version (following semantic versioning) and publish the update. Then, projects can upgrade the package whenever they're ready.

This eliminates manual copying of code across repos—every project just pulls the latest shared code via npm. Plus, versioning makes it easy to track which projects are using which version of your shared code.

2. Use Git Submodules

If you prefer to keep shared code in a Git repo without packaging it, submodules let you embed your shared code repo inside each project repo as a subdirectory:

• Add the shared repo as a submodule with git submodule add <shared-repo-url> src/shared.
• When you update the shared code, push those changes to the shared repo, then run git submodule update --remote in each project repo to pull the latest version.

Submodules are a bit more hands-on than npm packages, but they work well if you want to keep shared code in Git without a build/packaging step. Just be aware that your team will need to learn basic submodule commands.

3. Use Git Subtree

Subtrees are a friendlier alternative to submodules—they merge the shared code directly into your project repo's history, so there's no extra .gitmodules file or separate submodule commands:

• Add the shared repo as a subtree with git subtree add --prefix=src/shared <shared-repo-url> master.
• To pull updates from the shared repo: git subtree pull --prefix=src/shared <shared-repo-url> master.
• To push changes from your project back to the shared repo (if needed): git subtree push --prefix=src/shared <shared-repo-url> master.

This feels more like working with a normal directory in your repo, which is easier for Git beginners.

4. Switch to a Monorepo

If you're open to restructuring, a monorepo (one big repo containing all your projects and shared code) can drastically reduce overhead:

• Create a single repo with directories like shared/ (for your CSS/JS) and projects/project-1/, projects/project-2/, etc.
• Use tools like npm Workspaces or Yarn Workspaces to manage dependencies between projects and the shared code.
• When you update the shared code, all projects in the monorepo immediately have access to the changes—no need to sync across repos.

Monorepos are great for scaling to 150 projects because you only have one repo to manage, and shared code changes are instant across all projects. The downside is that the repo will get large, but GitHub handles large repos well, and tools like TurboRepo can help with build performance.

Optimizing your current workflow #

Right now, your process of checking out Master, changing remotes, installing dependencies, and committing is very manual. Any of the above solutions will replace that with a one-time setup per project, followed by simple updates when shared code changes. For example:

• With npm packages: New projects just run npm init + npm install @your-username/shared-styles.
• With submodules: New projects run git clone <project-repo-url> + git submodule init + git submodule update.

Final takeaway #

Avoid relying on non-merging branches for shared code—they won't scale to 150 repos. Instead, go with an npm package (most scalable for front-end) or Git submodules/subtrees if you prefer Git-native tools. If you're ready for a bigger change, a monorepo will make your life much easier long-term.

Good luck with scaling your projects!

内容的提问来源于stack exchange，提问作者webprogrammer