克隆只是一种不同的分支方式，所以这里的讨论实际上并不是关于使用这些方法中的一种。
然而，我将反对你的方法作为一个整体。你打算创建一个中心软件项目，它将在其他几个项目中扮演主要角色。虽然你可能能够通过分支或克隆来管理它，但我建议不要使用任何一个。你有几个不同的软件项目，其中一个在某种程度上对其他项目更中心。
我会使用一个存储库来存储中心内容，在某个时候标记一个可以使用的版本，然后找到一种方法来允许在某个地方使用该版本（以及任何后续版本）。
要创建"子"项目，您可以获取这样一个发布的版本，并在上面添加所有定制-但不要将中心软件填充到存储库中，只需引用使用过的版本。
这在很大程度上取决于您使用哪种语言进行开发，因为它必须利用该语言所提供的任何东西来将已发布的软件包集成到子项目中。这是依赖管理器的问题，到目前为止，每种通用语言都应该有一个依赖管理器。
另一件需要考虑的事情是：你可能不会从头开始中央项目，你可能会使用大量有用的、公开可用的库来开始。这些是另一层必须管理的依赖关系，把它们塞进中央存储库也不是最好的主意。在这里使用相同的依赖关系管理系统（取决于语言）。

我想做一些类似的事情，这个问题在搜索结果中排名很高。我正在开发一个MS Access数据库模板，其中包含用于导出对象/数据的代码（你不能在一个单一的二进制文件上做有用的比较）和更新用户的前端应用程序。在阅读了this article和一些实验之后，我认为它可以工作。（至少，这篇文章似乎达到了OP想要达到的目的。）

• • 免责声明：这是基于一个下午在一个小沙盒里的混乱。比我更高级的用户可能会提供建议（我希望）或继续指出这是一个愚蠢的差事。

首先，创建你的裸模板库。给分支起一个描述性的名字（比如，除了"master"、"trunk"或"main"之外）。这里有很多创造性的分支策略。我保持了它的简单性，并重新命名了main分支。（我所有的实验都是在本地机器上进行的。在你选择的远程主机上也做了同样的实验。"Remote"，裸库的名字都是标题大写的。）

~/Template > git init --bare --initial-branch template

建立你的裸项目库。我在项目端遇到了一些麻烦。--bare创建了很多支持文件，这些文件可以被克隆到一个新的工作副本中。当你试图将一组不同的新的支持文件推送到一个空的库中时，这些文件会碍事。如果你的远程库是通过推来创建的，你必须在那里做一个常规的init。然后编辑配置。您可能必须让此操作在本地工作，然后将远程导入到您的主机（以某种方式）

~/Project > git init
Initialized empty Git repository in ~/Project/.git/

~/Project > git config --bool core.bare true

将模板库克隆到本地工作副本。开发模板并推送更改。

~/tmpworking > clone ../Template .
Cloning into '.'...
warning: You appear to have cloned an empty repository.
done.

~/tmpworking > touch T1 T2

~/tmpworking > git add .

~/tmpworking > git commit -m "Initial template commit."
[template (root-commit) a2116f4] Initial commit.
 2 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 T1
 create mode 100644 T2

~/tmpworking > git push origin
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Delta compression using up to 24 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 217 bytes | 217.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
To ~/Template/../template
 * [new branch]      template -> template

通过克隆模板启动项目的工作副本。

~/ > git clone Template working
Cloning into 'working'...
done.

要简化工作流，请将模板分支的远程引用从"origin"更改为主项目可以使用它。您还需要更改分支的名称。在本例中，"template"是用于提取更改的远程连接的名称，"tmp"是这些更改要提取到的分支的名称。稍后，trunk分支将合并来自tmp的更改。2（这是否会引起更多或更少的混乱留给读者。3随你的便。4）

~/working > git remote rename origin template
Renaming remote references: 100% (3/3), done.

~/working > git remote -v
template        ../Template (fetch)
template        ../Template (push)

~/working > git branch -m template tmp

这篇文章强调不要从你的项目中推送模板更改。这可能有点过分，但是它强制对模板的更改来自于从该存储库中专门 checkout 的工作文件。在这个例子中，模板从~/tmpworking中获得编辑。项目通过将远程路径更改为无效值来强制执行这一点。

~/working > git remote set-url --push template no_push

~/working > git remote -v
template        ../Template (fetch)
template        no_push (push)

~/working > git log
commit 2eef44bdfae039635df56bc363914582bf4380e0 (HEAD -> tmp, template/template, template/HEAD)
Author: Jim <jim@email.com>
Date:   Sat Mar 4 03:31:33 2023 -0700

    Initial template commit.

现在我们从模板开始项目。创建主分支并切换到它。然后更改分支的远程。

~/working > git branch trunk

~/working > git switch trunk
Switched to branch 'trunk'

~/working > ls
T1  T2

现在，设置项目的远程路径，并将原始模板作为基线推送到项目，同时设置 Backbone.js 的上游路径。

~/working > git remote add origin ../Project

~/working > git remote -v
origin  ../Project (fetch)
origin  ../Project (push)
template        ../Template (fetch)
template        no_push (push)

~/working >  git push --set-upstream origin trunk
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Delta compression using up to 24 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 217 bytes | 217.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
To ../Project
 * [new branch]      trunk -> trunk
branch 'trunk' set up to track 'origin/trunk'.

您的项目已经设置了模板，并准备将更改推送到其存储库中。

~/working > touch P1

~/working > git add P1

~/working >  git commit -m "Initial project commit with templates."
[trunk f222d3c] Initial project commit with templates.
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 P1

~/working > git push origin trunk
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Delta compression using up to 24 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 256 bytes | 256.00 KiB/s, done.
Total 2 (delta 0), reused 0 (delta 0), pack-reused 0
To ../Project
   a2116f4..f222d3c  trunk -> trunk

当模板有更新时，切换到tmp分支并拉取更改，然后切换回trunk（或任何您喜欢的中介）并合并来自tmp的更改。
随着时间的推移，变更图将开始如下所示（项目变更位于左侧路径）：

~/working > git log --all --decorate --oneline --graph
*   cda1c24 (HEAD -> trunk) Merge updates from the template.
|\
| * 9718ee1 (template/template, template/HEAD, tmp) Gave T2 some love.
| * 58d6be6 Expanded line 3. Tweaked line 7.
* | 179eadd (origin/trunk) That seems to work ok. I'm sure nothing bad will happen in the future.
|\|
| * 5e3d3a2 Getting really useful.
* | 79a4d51 Resolved new feature around custom changes.
|\|
| * 24b565b Added more features.
* | 7e83f18 Custom mod to T1
* | 90d5702 P1 is coming along nicely.
* | 1b39d5b Merge template updates to trunk.
|\|
| * 7a5bb5d Fixed typos in T1.
| * 0400565 Added functionality to T1.
* | b067b46 Initial project commit with templates.
|/
* 2eef44b Initial template commit.

我假设对主项目行模板的更改（如果允许的话）不应该感染原始模板。这就是为什么我们污染了tmp分支的push引用。您可能需要考虑设置一个pre-merge-commit钩子来防止主行中的更改流回tmp分支。我也不知道合并会变得多么困难，如果他们必须编织到主线变化。（7e83f18是这样一个变化，合并进行得很好。因此，179eadd的消息。）这是Maven可以插话，并从我们的愚蠢拯救我们。
希望有人觉得这个有用。