版本化不同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的新版本时,我们将那里的versionstring更改为"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.58偏离0.59之后,您可以使用单独的"释放"分支来更改版本号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等),那么你可以没有"释放"分支.相反,您可以使用分离的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中使用版本号.它通过编译器(-DGIT_VERSION=…)的参数传递给C文件,并使用sed将其替换为脚本.

有一些规定可以覆盖"烧入"构建版本的版本号,但它们通常仅用于在工作树之外完成的构建(例如,从从tar文件中提取的树构建的构建).

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

在您的问题的附录中,您声明在进行开发时需要调整版本号.首先,我认为我所描述的"0.58释放"分支方案仍然可以为您服务.分离您的更改只需要更多的纪律.如果您认为*-release分支为"已发布用于内部测试"而不仅仅是"向客户发布(或用于外部测试)",那么它仍然有意义.总是在基础分支上进行开发(例如"0.58"),并且在进行需要特定版本号的构建之前始终将基本分支合并到发布分支(例如"0.58-release")(始终从这样的版本编译)合并发行分支).

如果你坚持将版本号更改和(非合并)代码更改放在同一行历史记录中,那么在我看来,除了你合并之外你将别无选择,只能处理冲突(除非你去git cherry-pick( Damien Wilson,或者是针对的自动编辑脚本git rebase -i).

如果您的"版本文件" 仅包含版本控制信息,则可以通过.gitattributes将Version.cpp文件标记为不可合并来缓解冲突解决.

包含Version.cpp的目录中的.gitattributes

/Version.cpp -merge

merge=binary如果合并分支之间的文件不同,那么将其标记为(相同)将始终导致冲突.合并后的工作树版本将默认为您已检出的分支的版本(不是您正在合并的分支中的版本),因此您只需git add Version.cpp && git commit完成合并(假设所有其他冲突也是解决).