对不同 git 分支进行版本化的最佳方式

Question

我们有以下场景：我们的游戏 OpenLieroX 有几个基本版本；现在是 0.57、0.58 和 0.59。对于每个基本版本，我们都有一个单独的分支。每个这样的基础版本都有多个版本（例如 0.57 beta1-beta8 和 rc1、0.58 beta1-beta9）。

当我们开发新东西时，我们正在使用最高的基础版本分支（现在是 0.59）。当我们修复一些报告的错误时，我们会在发生错误的最早版本（主要是 0.58）中进行修复。有时，我们总是将 0.58 中的所有更改合并到 0.59 中（只要我们仍然维护并在旧分支上进行更改）。

这一切都工作得很好，直到涉及到一些我们只想在 0.58 中而不是在 0.59 中进行的更改。到目前为止，这种情况只发生在一种情况：版本号。我们有一些包含版本号的 Version.cpp 文件（以及其他一些文件）。因此，当我们想要推送 0.58 的新版本时，我们将其中的版本字符串更改为“0.58 beta10”（或其他）。现在，当我们进行从 0.58 到 0.59 的常规合并时，也会应用此更改。目前，我们通过使用正确的版本号再次覆盖它来修复此类情况（或者在其他错误提交的情况下，可能会恢复）。

关于这种不需要的更改的细节对我来说似乎有点难看。我们处理这个问题的方式总体上是不好/不常见的吗？获得相同结果的最简单方法是什么？在 0.59 中挑选所有 0.58 的提交会需要更多的工作。

---

还有一个进一步的细节可能会让事情变得更加复杂：在处理代码时，我必须设置即将发布的版本号。这是因为我们有一个网络引擎，我们可能引入了一些新功能，并且代码中有一些检查，例如“if(client->version() >= Version(X,Y,Z)) ...” 。现在，当我们引入新事物时，通常意味着在某些时候也进行此类检查。 （但我们试图避免旧分支中的这些更改。）

另一个问题是我们不只是向上计算版本（例如 0.58.1、0.58.2，...），而是这样计算：0.58 beta1， 0.58 beta2, ..., 0.58 betaX, 0.58 rc1, ..., 0.58, 0.58.1, 0.58.2, ... 这是因为我们想将其标记为实验性的开始（beta 阶段），然后标记为大多稳定或稳定。在某些罕见的情况下，即使在两个不同的测试版之间也可能会发生严重的变化（可能是网络协议）（当然，我们会尽力避免它们，但有时没有的话是不可能的）。

Answer 1

使用额外分支

0.59 与 0.58 不同后，您可以使用单独的“release”分支来处理 0.58 中的版本号更改。每个版本（最新版本除外）都有自己的“发布”分支，该分支仅包含来自基础分支的合并以及更新外部版本号的更改。分支结构可能如下所示：

                A--------o--B                  0.58-release
               /        /
...--o--o--o--o--o--o--o--o                    0.58
      \        \        \  \
       \        \        \  \            C     0.59-release
        \        \        \  \          /
         o--o--o--o--o--o--o--o--o--o--o--o    0.59
                                  \     \
                                   o--o--o     0.60

• A 标记软件“0.58 beta9”
• B 标记软件“0.58 rc1”
• 0.58 具有尚未发布的更改
• C 标记软件“0.59 beta1”
• 0.59 具有尚未发布的更改发布的
• 0.60 尚未完全更新到 0.59

或者，如果您非常严格地只在 A、B、C 等处进行更改，从而更改外部版本号（没有重大代码更改，这些更改属于“基础”）分支：0.58、0.59 等），那么你可以不用“release”分支。相反，您可以使用分离的 HEAD 或临时分支（在版本控制后删除）来进行外部版本更新提交并将其保存在标签中。

                A        B
               /        /
...--o--o--o--o--o--o--o--o                    0.58
      \        \        \  \
       \        \        \  \            C
        \        \        \  \          /
         o--o--o--o--o--o--o--o--o--o--o--o    0.59
                                  \     \
                                   o--o--o     0.60

• A 为软件添加标签“0.58 beta9”，标签为 0.58-beta9
• B 为软件添加标签“0.58 rc1”，标签为 0.58-rc1
• C 为软件添加标签“0.59 beta1”，标签为 0.59-beta1

就像 Git 一样

你也可能会看Git 进行自己的版本控制的方式。

对于从 Git 工作树完成的构建，版本号是从 git describe HEAD 的输出生成的。 Makefile 知道如果版本号发生变化，哪些文件需要重新编译/重建，并且它始终运行 GIT-VERSION-GEN 脚本以确保其具有最新版本号。通过包含生成的版本文件，可以在 Makefile 中获得版本号。它通过编译器的参数传递到 C 文件 (-DGIT_VERSION=…)，并使用 sed 将其替换为脚本。

有一些规定可以覆盖“烧录”到构建中的版本号，但它们通常仅适用于在工作树之外完成的构建（例如，从从 tar 文件中提取的树完成的构建）。

将版本字符串更改与其他更改混合

在问题的附录中，您声明需要在开发时调整版本号。首先，我认为我和 seh 描述的“0.58-release”分支方案仍然适合您。只是需要更多的纪律来区分您的更改。如果您将 *-release 分支视为“发布用于内部测试”而不仅仅是“发布给客户（或用于外部测试）”，那么它仍然有意义。始终在基础分支（例如“0.58”）上进行开发，并且在进行需要特定版本号的构建之前始终将基础分支合并到发布分支（例如“0.58-release”）（始终从这样的版本号构建）合并发布分支）。

如果您坚持将版本号更改和（非合并）代码更改放在历史记录的同一行中，那么在我看来，您别无选择，只能在合并时处理冲突（除非您使用 gitcherry-pick（根据 Damien Wilson，或针对 git rebase -i 的自动编辑脚本）

如果您的“版本文件”仅包含版本控制 。信息，您可以通过使用 .gitattributes 将包含

的目录中的

/Version.cpp -merge

Version.cpp标记 Version.cpp 文件标记为不可合并，从而缓解冲突。如果合并后的分支之间的文件不同，这样（与merge=binary相同）总是会导致冲突，合并后的工作树版本将默认为您检查的分支的版本。 out（不是您要合并的分支中的分支），因此您只需 git add Version.cpp && git commit 即可完成合并（假设所有其他冲突也已解决） ）。

Answer 2

看起来你正在做的事情是正确的方法（对于这个结果）。但也许你应该重新考虑你的版本系统。

您可以添加构建版本，0.58.1、0.58.2 等。这样您就可以添加任意数量的内容，并且您仍然可以将其统称为“0.58”，即使它有一个内部版本号。

发布后，您可以添加 beta、RC 等，但这不是版本控制系统应该关心的事情。

版本“0.58.3 (beta1)”仅表示版本 0.58.3。 beta1 部分是人类信息，而不是版本控制系统问题。

Answer 3

如果我理解这个问题，听起来您想包含来自不同分支的提交的某个子集。如果是这种情况，您可能只需要运行 gitcherry-pick 并仅应用您想要的提交。

有关该命令的更多信息，请参见 git 文档< /a> 和 Git Ready。

Answer 4

棘手的部分是将版本指定与底层代码隔离。

您可以将版本指定分支浮动在已发布代码分支的顶部，这样您就可以随时安全地将所有代码从已发布分支 (0.58) 合并到主分支 (0.59) ，而不混合冲突的版本名称。该版本指定分支永远不会合并回已发布的分支；当您想要在版本化版本中包含新代码时，您只需将其重新设置为已发布分支的顶部即可。

您可以使用 .git/config 文件中的以下条目轻松安排此操作：

[branch "0.58-release"]
        remote = .
        merge = refs/heads/0.58
        rebase = true

这样，您的发布分支称为“0.58”，并且您可以使用“0.58-release”进行版本化构建“ 分支。当需要进行发布构建时，您可以发出以下命令：

git checkout 0.58-release
git pull
# Edit the version-designating file.
git commit -a -m'Updated version.'

对版本指定文件的所有更改仅存在于“58-release”分支上，并且可以使用 git rebase 安全地向前移动/代码>。或者，如果您希望对版本指定文件的每次更改都坚持“0.58”分支中的代码状态，则可以将“0.58”分支合并到“0.58-release”中分支而不是在“0.58”之上重新构建“0.58-release”。