在git中“分叉”自己的项目

Question

我目前遇到以下情况：我需要维护一个存储库，其中包含与子目录基本相同的多个版本的项目。让我们调用开发/最重要的项目“main”和其他项目“sub_1”，...，“sub_n”。

版本是截然不同的，但大致相同：想想像Android 2.1的Android项目，而不是你开发的2.2+，IE6的改进的CSS样式表，大客户的自定义构建，这些的东西。每个版本通常都有一个“主”文件的子集，只有很小的修改。

目前我正在使用以下方法更改项目中的文件：

• 对于0≤i≤n
• 查看文件sub_i使用
• 使用main
中正确的文件覆盖sub_i使用的文件
• 区分更改，忽略属于main的更改，但将“patch”sub_i重新应用于文件

显然，这个过程很乏味且容易出错。我已经搜索了几种方法来实现这一点，基本上有以下几点：

• 我现在在做什么。
表示理由不太理想
• 分支。这看起来最有希望，但我不知道如何只分支存储库的一部分。 （如果我做了一个完整的分支，我仍然没有办法有效地合并文件）
• 子模。这些可能有用，但据我所知，它们只用于完全外部项目，而不是用于同一存储库的副本

有谁知道这样做的正确方法？

请注意，维护/ main和/ sub_i（git存储库作为root）目录结构是可取的，因为更改它可能会破坏很多东西（不是软件本身，而是主要是构建工具等）。

Answer 1

Subrepo方法

当我理解你的时候，你的回购看起来像这样：

root
+ main
+ sub_1
+ sub_2
+ sub_N

主要行为类似于某种库或框架，而sub_1..sub_N或多或少是同一软件的不同分支。一种解决方案是将main作为sub_1..sub_N的子模块放置，所以最后树看起来像

root
+ main (=submodule)
+ source of sub_X, = on branch sub_X

此处所有sub_1..sub_N文件夹都是单个仓库的不同分支，而您的主/文件夹是不同的仓库。如果所有sub_X文件夹都是从公共库中派生出来的话，这是一种可行的方法，并且很容易在这个公共库上进行开发，并且可以从公共库到sub_X分支进行合并以分发这些更改。但是这种情况有一个很大的缺点：它需要每个使用这种结构开发的人都知道他做了什么，因为在sub_X分支上的开发不容易通过合并分发到公共基础或其他sub_Y分支，因为合并操作不仅会将新更改传输到其他分支，还会将sub_X分支与base或sub_Y不同的更改传递给其他分支。所以一般来说我会反对这种做法。

专业化

另一种方法是隔离sub_X更改，并创建一个基本版本，其中包含sub_1..sub_N中相同的所有内容，以便sub_X文件夹仅由专门的内容组成。如果这是一种可用的方式，这取决于您的开发/部署策略。

真正的分支

由于您写道sub_X文件夹是main的副本，因此它看起来main已经充当所有sub_X文件夹的公共基础。如果是这种情况，您可以将不同的文件夹更改为分支。你可以通过

实现这一目标

1. 为主文件夹（git checkout -b main）
创建分支
2. 删除所有sub_X内容
3. 将所有main / *内容移动到/

4. 提交

每个sub_X文件夹
6. 基于main（git checkout -b sub_x main）
创建一个sub_x分支
7. 删除除sub_X文件夹以外的所有文件夹
8. 将所有sub_x内容移动到/
9. 提交

之后你有一个这样的版本图：

 -o-o-(past history) - main -- sub_1
     /                      \--sub_2
 -o--                       \--sub_N

然后，您可以在主分支上开发新功能，并将这些功能合并到sub_X分支。多分支设置的主要原因是，始终需要为新开发确定正确的起点，因为合并操作将在分支之间传输不需要的更改，如果您没有使用正确的起点。正确的起点是修订版，它是所有分支的祖先，其中应该进行新的更改。如果你想为影响所有sub_X分支的东西开发一个bug修复，你需要在main中开发这个bug修复，因为main是所有sub_X分支的共同祖先。 OTOH如果你有一些非常特殊的sub_23，那么在sub_23分支上开发东西是正确的。