Git:分叉vs子模块vs子树

Question

我有一个电子商务项目，由3部分组成，一个admin dashboard，一个api(core)和一个storefront(frontend)，dashboard和api将从开源存储库中提取，而storefront将从自己的存储库中从0开始开发，现在我的问题是，在git上处理这个问题的最好方法是什么？使用开源存储库和我的前端存储库创建submodules，或者对开源存储库执行fork操作并添加前端。

我希望在开源存储库中进行一些更改，但也要使其与原始存储库中的更改保持同步。

编辑1

我将使用docker-compose来运行服务。

​

​

编辑2

This是一个开源仓库，我想用它作为模板来开发我的电子商务，不同的是我想用其他技术来开发店面……

Answer 1

...在git上处理这个问题的最好方法是什么？

最好的问题通常是意见问题，因此在Stack Overflow上是离题的。

从技术角度来看，我们可以这样说：

• A fork只是一个具有某些功能的克隆。功能是由托管系统决定的: Bitbucket forks、GitHub forks等在添加的功能方面并不完全相同，因为每个托管提供商都希望让您使用它们，而不是其他提供商。但它们都是从克隆开始的。

Git

• A子模块只是一个Git存储库。它之所以成为一个子模块，是因为其他一些Git存储库会说：_clone this Git repository，然后签出提交_____ (在空白处填入一个哈希ID)。Git存储库-其中包含克隆和签出指令的存储库-我们称之为超级项目，而这个_other存储库，我们称其为子模块。

子模块有一堆烦恼随之而来。最大的一个是上面的空格所暗示的。superproject Git存储库需要列出在子模块中使用的确切提交散列ID。对子模块进行的任何更改都需要对超级项目进行更改:您必须在超级项目中进行新的提交，以便列出新的和不同的子模块散列ID。

您不能让超级项目通过分支名称引用该子模块。您可以将名称添加到超级项目中，但超级项目Git大多不使用该名称。当它命令子模块获得一些提交时，它是通过原始散列ID来完成的，所以你不得不处理原始散列ID。这没有什么错，只是需要注意的事情。

子模块通常有次要的烦恼，即为了构建软件，您需要超级项目和所有子模块。在获取子模块和检查正确的提交时出现的任何问题都会使一切都停滞不前。这样的毛刺并不常见，但它们确实会发生。由于超级项目不包含子模块，因此超级项目可以很小:实际上，没有自己的代码的超级项目-只是指向子模块-可以很小。

• 子树不是上面的两个。在使用git subtree时，您需要两个普通的(没有特殊处理的) Git存储库。他们每个人都有自己的分支机构，一切照常。有时，您会使用子命令运行git subtree：split拆分某些内容，或运行merge将某些内容重新组合在一起。( pullandpushcommands aremergeandsplitin disguise, followed by a separate second Git command.) The split subcommand lets you take a collection of commits—remember, all Git repositories are primarily collections of commits—that's usually less than _every commit_, but could be _every commit_—in the "bigger" Git repository, and modify and extract some of those commits so that they'll fit in the "smaller" Git repository. Meanwhile the merge subcommand takes the commits in the smaller repository, matches them up against an earlier split, figures out what's new since then, and "embiggens" them to fit back into the larger repository and adds them to that larger repository. What this means is that both the smaller and larger repositories are self-contained—which was true with the submodule approach—but that the _larger_ repository is _so_ self-contained that it _never needs the smaller repository at all_. It just has it available, _if_ it has it available, to do more split-and-merge operations. _Everything_ is in the larger repository. You don't have to get or use the smaller repository at all, ever, unless you want to do a new split and/or merge. You can give the smaller repository out to others, while keeping the large one private; changes people make to _add to_ the smaller repository, you can try to take back later withgit子树merge. Unlike submodules, this means the larger ("superproject"-ish) repository _contains everything_. So there's never any problem with the submodule not being available—but, unlike submodules, the "superproject" is always the biggest thing around. You are not _referring to_ some other Git repository's commits. You _contain_ those commits, as transformed by themerge`子命令适合您自己的“超级项目”-ish存储库。因此，只有在整个项目很小的情况下，您的存储库才会很小(在这种情况下，您为什么还要费心使用子树呢？)。