两个Git存储库共享公共代码

Ale*_*ulu 38 git

所以我有一个项目,其中包含客户端部件和服务器部件.我希望客户端和服务器代码位于不同的Git存储库中,以便清楚地分离代码,但是,它们共享一些文件,理想情况下,共享文件在客户端和服务器中始终是相同的.

我该怎么办呢?拥有公共代码的第三个存储库是否更好?

Tim*_*lla 30

我不会就"你应该怎么做"给出建议.但我将解释如何完成将第三个存储库与公共代码集成到其他存储库中:这是git子模块的工作.git子模块允许您在指定路径引用git存储库的快照:

git submodule add git://example.com/repository.git path
Run Code Online (Sandbox Code Playgroud)

然后创建一个提交.现在引用给定存储库的快照path.

填充子模块

  1. 执行 git submodule init
  2. 执行 git submodule update

每个已配置的子模块都将更新以匹配它应该看起来的状态.

将子模块更新为以后的提交

  1. 切换到子模块的目录
  2. 执行git pull/ git fetch+ git checkout将子模块更新为所需的提交/标记
  3. 创建一个新提交以更新.gitmodules文件中的提交

有关子模块的更多信息,请查看官方手册.

  • @DevYego 我不确定你的意思。您可以让子模块指向任何提交,而不仅仅是主分支。跟踪是本地分支与远程分支的概念,您可以在每个子模块的 git 中进行管理——它不知道它是一个子模块。 (2认同)

Sch*_*ern 11

如果他们共享共同的代码,我会看到两个明智的选择.将公共代码分离到自己的项目中,或合并服务器和客户端存储库以使它们更容易一起工作.

分离公共代码是否值得额外的努力取决于您.公共代码本身是否有意义,或者只是本产品特有的一系列功能?例如,如果你有一个共同的SSL或日期解析代码,那将是一个很好的分拆项目.或者你可能已经为配置文件解析编写了特殊的代码,即使你的项目没有人会使用它,也可以独立工作.如果你因为两个项目共享公共代码,请不要打扰,它将没有自己的方向.将其拆开只会成为服务器和客户团队开发的障碍.

是否应合并客户端和服务器是另一个考虑因素.它还归结为将它们视为单独的产品是否有意义.它们作为单独的产品有用吗?客户端和服务器的不同版本可以一起工作,还是必须是同一版本?不同的人在客户端和服务器上工作吗?你希望将所有内容保存在一个超级存储库中的事实说不.

如果你分成多个存储库(客户端,服务器,相关项目),请按照TimWolla的回答.

如果你不知道,合并将他们都一个存储库server/,client/以及common/顶级目录.如果他们的担忧纠缠在一起,就把它们放在一起.这样还可以更轻松地发现和迁移重复的代码.您可以解决它们并创建具体的"共同"项目,然后将它们分离到自己的存储库中.


Tod*_*obs 5

TL; 博士

只需使用 Git 子模块来保存您的公共代码。这就是他们打算用于的用例。存在其他选项,但主要用于同一文件系统上的存储库,并且在通过网络克隆时几乎没有优势。

通用代码与相同文件

处理公共代码的正确方法通常是通过子模块子树合并。但是,如果您拥有(并将保持)相同的文件资产,那么您可以利用支持它们的文件系统上的符号链接。这种方法至少有三个缺点:

  1. 只有一个存储库将拥有“真实”文件。另一个存储库将只包含指向文件的符号链接,该文件可能存在或可能不存在于不同的文件系统上。
  2. Windows 系统没有 Linux/Unix 风格的符号链接,因此互操作性可能是一个问题。
  3. 除非您正在处理非常大的二进制 blob,否则共享链接的空间节省可能很小,并且不值得付出努力。

您还可以研究使用替代品在同一文件系统上的存储库之间共享对象。手册说(强调我的):

您可以使用 objects/info/alternates 或 $GIT_ALTERNATE_OBJECT_DIRECTORIES 机制从其他对象存储中借用对象。具有这种不完整对象存储的存储库不适合发布以用于哑传输,但只要对象/信息/备用点指向它借用的对象存储,就可以。

这种高级用法通常用于在 Atlassian Stash 等系统上加速分叉,而不是用于共享特定的 blob,但如果您想玩电锯,这些工具就在那里。