电子产品设计师如何用Git统一管理多模块项目并保留独立提交历史？

Hey Martin, great question—this is a super common pain point when managing multi-component projects, and there are absolutely ways to get the workflow you want: single GUI management, no branch switching, and preserved independent commit histories for each module. Let’s break down the best options for you, since you’re using GitExtensions/SourceTree which plays nicely with all these approaches.

Option 1: Git Submodules (Best for Pure Independent Histories) #

This is the closest match to your goal of keeping each module’s commit history 100% separate, while wrapping everything in a single "container" repository. Here’s how it works:

• Create a new empty repository (your "container" repo) and initialize Git.
• For each module (hardware, software, etc.), run:

  git submodule add <your-existing-hardware-repo-url> hardware
  git submodule add <your-existing-software-repo-url> software
  # Repeat for外壳、说明书、定价等模块
  

• In GitExtensions/SourceTree, your container repo will show each submodule as a nested entry. You can double-click any submodule to view its full, independent commit history, and commit changes directly from within the submodule’s directory—these commits will only go to that module’s original repo history. The container repo only tracks the latest commit SHA of each submodule, so you can update references when modules change.

Pros:

• Each module’s history stays completely isolated (no mixing commits between hardware/software)
• GitExtensions/SourceTree has built-in support for submodules—no need for multiple GUI instances
• You can still use each module’s repo independently if needed

Cons:

• Minor learning curve for syncing submodule updates (you’ll need to commit submodule reference changes in the container repo when modules are updated)

Option 2: Git Subtree Merging (Single Repository, Filterable Histories) #

If you prefer having everything in one single repository but still want to track module-specific commits, subtree merging lets you merge each module’s repo into a dedicated folder in your container repo while preserving their commit histories.

• Create your container repo and initialize Git.
• Add each module’s repo as a remote:

  git remote add hardware <hardware-repo-url>
  git remote add software <software-repo-url>
  

• Merge each module into its own folder:

  git subtree add --prefix=hardware hardware main
  git subtree add --prefix=software software main
  

• When you make changes to the hardware/ folder, commit them to the container repo. To view only hardware-related history, use:

  git log -- hardware/
  

Pros:

• All code lives in one repo—no separate submodule references to manage
• GitExtensions/SourceTree can filter commits by folder, so you can view module-specific history directly in the main repo view

Cons:

• Module histories are part of the main repo’s commit log (though filterable), so they’re not as strictly isolated as submodules
• Pushing updates back to the original module repos requires extra subtree push commands

Option 3: Git Worktrees (Branch-Per-Module, No Switching) #

If you want to keep each module on its own dedicated branch but avoid switching branches constantly, Git Worktrees let you map each branch to a separate directory. This way, you can edit hardware files in one folder (linked to the hardware branch) and software files in another (linked to software branch)—no branch switching required.

• Create your container repo and initialize Git.
• Create a branch for each module and populate it with the module’s content:

  git checkout -b hardware
  # 删除默认文件，复制硬件模块内容并提交
  git checkout main
  git checkout -b software
  # 删除默认文件，复制软件模块内容并提交
  

• Link each branch to a separate directory:

  git worktree add ../project-hardware hardware
  git worktree add ../project-software software
  

• In GitExtensions/SourceTree, you can add each worktree directory as a separate repo entry, or manage all branches from the main repo view. Changes in ../project-hardware will commit directly to the hardware branch, and vice versa—no switching needed.

Pros:

• No branch switching ever—each module lives in its own directory tied to its branch
• Full independent commit histories per branch
• Works seamlessly with your existing GUI tools

Cons:

• You’ll have multiple directories for your project (one per module)
• Managing many branches can get cluttered over time

Other Project Management Approaches #

If you’re open to stepping outside pure Git, here are a couple of alternatives:

• Repo Tools: Tools like repo (from Google) let you manage multiple Git repos from a single configuration file. It’s command-line focused, but some GUIs support it, and it’s great for coordinating releases across modules.
• Project Tracking Platforms: Tools like GitHub Projects or GitLab Issues can help you track tasks across modules, even if you stick with your original multi-repo setup. They add a layer of organization on top of Git without changing your repo structure.

All the Git-based options above will let you work within a single GUI instance, keep module histories separate, and avoid constant branch switching. For your use case, I’d start with Git Submodules—it’s the most straightforward way to preserve each module’s independent history while wrapping them in a single container.

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