如何使用Git同步已上线Vue项目与其管理版本的代码？

Great question—this is a super common scenario when building admin versions of existing apps, and you’re already on the right track considering branches vs. submodules. Let’s break down your options, their pros/cons, and which might fit your use case best.

1. Independent Branch (Simplest Starting Point) #

If your admin variant only needs minor, incremental changes (like adding admin permission checks, tweaking a few UI components, or adding admin-specific routes), a dedicated admin branch off your main project repo is the easiest place to start.

How it works: #

• Create the admin branch from your main branch:

  git checkout main
  git checkout -b admin
  

• Make your admin-specific changes directly in this branch.
• When the main branch gets updated, merge those changes into admin regularly to stay in sync:

  git checkout admin
  git merge main
  

• Resolve any conflicts (which should be minimal if you keep syncing often) and commit the merge.

Pros: #

• Zero extra tooling or Git knowledge required—just basic branch management.
• All code lives in one repo, so switching between main and admin builds is trivial.
• Easy to roll back changes or test main branch updates in the admin context.

Cons: #

• As your admin-specific code grows, merge conflicts will become more frequent and complex. Over time, the admin branch can drift significantly from main, making syncs painful.
• No clear separation between shared code and admin-only code—risk of accidentally committing admin changes back to main.

Best for: Small-scale admin customizations, teams new to advanced Git workflows.

2. Git Submodules (Clean Separation for Larger Variants) #

If your admin variant has distinct, self-contained code (e.g., a full admin dashboard layout, separate auth logic, or entirely new pages) but still relies on most of the main project’s core code (like API clients, shared components, or utility functions), Git submodules are a better fit.

How it works: #

• Create a new, empty repo for your admin project.
• Add your main Vue project as a submodule inside the admin repo—this lets you reference the exact version of the main project you need:

  git submodule add <your-main-project-repo-url> src/main-app
  

• Your admin repo will only contain custom code (admin routes, components, etc.), while the main project’s code lives in the submodule.
• To sync the main project’s updates, pull the latest changes in the submodule:

  git submodule update --remote
  

Pros: #

• Strict separation between shared main code and admin-only code—no risk of cross-contamination.
• Syncs are predictable: you choose exactly when to pull main project updates, and conflicts are isolated to the submodule (if any).
• The admin repo stays lean, focused only on its customizations.

Cons: #

• Submodules have a steeper learning curve—it’s easy to make mistakes with commits, updates, or cloning (you’ll need to use git clone --recurse-submodules for new clones).
• Deployment is slightly more complex, as you need to ensure the submodule is pulled correctly in your CI/CD pipeline.

Best for: Admin variants with significant customizations, teams comfortable with intermediate Git workflows.

3. Monorepo (Advanced Shared Code Management) #

If you anticipate both the main project and admin variant evolving independently but still sharing a lot of core code (like components, utils, or API layers), a monorepo setup is the most scalable long-term solution. Tools like pnpm, Yarn Workspaces, or Lerna can help manage this.

How it works: #

• Restructure your repo into a monorepo with separate packages:
  • packages/main-app: Your original end-user Vue app
  • packages/admin-app: Your admin variant
  • packages/shared: Shared code (components, utils, API clients, etc.)
• Both apps import shared code directly from the shared package, so updates to shared code automatically propagate to both apps.

Pros: #

• Eliminates manual sync entirely—shared code changes are available to both apps instantly.
• Clear boundaries between projects and shared code, making maintenance easier as both apps grow.
• Simplifies versioning and dependency management for shared code.

Cons: #

• Requires setting up monorepo tooling, which has a learning curve if you’re new to it.
• Initial restructuring of your existing codebase takes time.

Best for: Long-term projects where both main and admin apps will have ongoing, independent development but need to share significant code.

Recommendation for Your Case #

Since you’re starting with a copy of the main app and only need to adjust some logic/UI for admins, start with an independent admin branch first. It’s quick to set up, and you can easily sync main branch updates as needed.

If you notice that admin-specific code is growing too much and merge conflicts become a hassle, you can later migrate to submodules or a monorepo. Just make sure to sync regularly (e.g., weekly or after every main branch release) to prevent your admin branch from drifting too far.

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