我有一个电子商务项目,由 3 部分组成, an admin dashboard、 anapi(core)和 a storefront(frontend),dashboard和api将从开源存储库中获取,并将storefront在自己的存储库上从 0 开始开发,现在我的问题是,什么是在 git 上处理这个问题的最佳方法是什么?submodules使用开源存储库和我的前端存储库进行创建,或者fork使用开源存储库进行创建并添加前端。
我想在开源存储库中进行一些更改,但也要使其与原始存储库中可以进行的更改保持同步。
我将使用 docker-compose 来运行服务..
这是我想用作开发电子商务的模板的开源存储库,不同之处在于我想用其他技术来开发店面......
\n\n...在 git 上处理这个问题的最佳方法是什么?
\n
最好的问题通常是意见问题,因此在 Stack Overflow 上是偏离主题的。
\n从技术角度我们可以说的是:
\n分叉只是具有某些功能的克隆。这些功能由托管系统决定:GitHub 分叉、Bitbucket 分叉等在添加的功能方面并不完全 100% 相同,因为每个托管提供商都希望让您使用它们而不是其他托管服务提供商。但它们都是从克隆开始的。
\n子模块只是一个 Git 存储库。使它成为子模块的原因是其他一些Git存储库说:克隆此 Git 存储库,然后签出提交 _____(用哈希 ID 填充空白)。另一个Git 存储库\ xe2\x80\x94,其中包含克隆和签出指令的 \xe2\x80\x94,我们称为超级项目,而这个Git 存储库,我们称为子模块。
\n子模块有很多随之而来的烦恼。最大的一个是上面的空白所暗示的。超级项目 Git 存储库需要列出要在子模块中使用的确切提交哈希 ID 。对子模块所做的任何更改也需要对超级项目进行更改:您必须在超级项目中进行新的提交,以便列出新的不同的子模块哈希 ID。
\n您不能让超级项目通过分支名称引用子模块。您可以为超级项目命名,但超级项目 Git 大多数情况下不使用该名称。当它命令子模块获取一些提交时,它通过原始哈希 ID 来执行此操作。所以你不得不处理原始哈希 ID。这并没有什么问题,只是需要注意一下。
\n子模块通常有一个次要的烦恼,即要构建软件,您需要超级项目和所有子模块。获取子模块和检查正确提交的任何故障都会阻碍一切。此类故障并不常见,但确实会发生。由于超级项目不包含子模块,因此超级项目可能很小:事实上,没有自己的代码的超级项目\xe2\x80\x94(仅引用子模块\xe2\x80\x94)可能很小。
\n子树不是以上两者之一。使用 时git subtree,您需要两个普通的(未特殊处理的)Git 存储库。他们各有自己的分行,一切都如常。有时,您会git subtree使用子命令来运行:split将某些内容拆分,或者merge将某些内容重新合并。(pull和push命令是merge伪装split的,后跟单独的第二个 Git 命令。)
请记住,所有 Git 存储库主要都是提交的集合,该子split命令允许您在“更大的”Git 存储库中获取提交的集合(通常少于每个提交,但也可能是每个提交),并修改和提取其中一些提交所以它们适合“较小的”Git 存储库。同时,merge子命令获取较小存储库中的提交,将它们与之前的拆分进行匹配,找出此后的新增内容,然后“embiggens”它们以适应较大的存储库,并将它们添加到该较大的存储库中。
这意味着较小和较大的存储库都是独立的,对于子模块方法也是如此,但是较大的存储库是如此独立,以至于它根本不需要较小的存储库。它只是让它可用(如果有的话)来执行更多的拆分和合并操作。 一切都在更大的存储库中。您根本不必获取或使用较小的存储库,除非您想要进行新的拆分和/或合并。您可以将较小的存储库提供给其他人,同时将较大的存储库保留为私有;人们所做的更改添加到较小的存储库中,您可以稍后尝试使用git subtree merge.
与子模块不同,这意味着更大的(“超级项目”)存储库包含所有内容。因此,子模块不可用永远不会有任何问题,但与子模块不同,“超级项目”始终是最大的事情。您并不是指其他 Git 存储库的提交。您包含这些提交,通过merge子命令进行转换以适合您自己的“超级项目”存储库。因此,如果整个项目很小,那么您的存储库只能很小(在这种情况下,为什么要为子树烦恼?)。