从 CVS 中释放工作流 concepts/limitations

Question

我正在将我们的 VCS 从 CVS 迁移到 Git，我仍在努力尝试最好地调整我们的工作流程以适应 Git，但我仍然有一些疑问。我们没有生产环境，我们会定期发布版本，并由我们的客户将它们部署到生产环境中。所以我们的工作流程与那里的团队有点不同。我们经常同时开发多个版本，在某些时候需要与更高版本集成。这是一个简单的例子：

现在，假设 V1.0 已经完成并正在向我们的客户发布。在这一点上，我们需要将这个分支与 V2.0 和 V3.0 合并，它们仍在开发中（为简单起见，我没有考虑更改可能不适用于某些分支的情况，例如，对在后来的分支中停止的功能的修复），这将创建类似于此的历史记录：

随着V1.0“关闭”，我们开始研究V1.1。我们使用 CVS 的方式，我们将有一个分支代表每个版本的 HEAD，例如V01_HEAD，从那里创建了一个新分支，例如V01_00，做一些工作，提交，切换到 V01_HEAD，从 V01_00 合并，提交，标记，切换到 V02_HEAD 并合并 V01_HEAD，提交，切换到 V03_HEAD 并合并 V02_HEAD、提交，等等。之后，我们将从 V01_HEAD 创建 V01_01 并重复循环。可以想象，保持所有内容最新是棘手、费力、痛苦的，合并冲突非常频繁，因为我们需要跟踪所有正在开发的分支，并且需要确保我们不会忘记合并到其中一个分支上层分支。在不同的分支中更改相同的代码块也很常见，因此会发生冲突。当我们有时有 4 个或更多并行开发时，挑战会增加。主分支的唯一目的是作为新版本的基础。我们还有其他挑战。想象一下，某人正在 V1.12 上工作，并对几个类进行了实质性更改。其他合作者正在研究 V2.5，其他合作者正在研究 V3.0。在合并 V1.12 之前，其他版本的工作将基于可能已弃用的代码。

同样的理念在 Git 上是否有意义，还是拥有更少和更长的运行分支更好（例如 V1、V2、V3, 等) 并在将提交合并到更高分支之前标记提交？

因为这是一个全新的开始，而且 Git 与 CVS 相比提供了更多的选择，我只是想确保我们选择的工作流程不会引入不必要的熵。我需要 Git/version 控制专家的可靠建议。

我希望我已经足够清楚地解释了这个问题。

Answer 1

是的，哲学在 Git 上也很有意义。但是你也可以设计不同的结构，因为你需要同时开发v1.x、v2.x和v3.x，你可以创建3个发布分支v1、v2和v3。 v1.0、v1.1、v1.2等版本可以通过tag和commit message进行标记，方便查找。有a successful git branch module供您参考（因为您的要求与它不同，如果您要应用此模块，则必须进行一些更改）。

C1---C2------C3------------------C7
       \       \                  \
        \       C6--C8--C10(V2)    C9--C11(V3)
         \              / ______________/
          C4-----------C5---C12---C13 (v1)
                       |     |     |
                     V1.0   v1.1   v1.2

并且在合并之前不需要标记提交，您可以通过git tag –a v1.0 <commit id> -m 'message'为历史提交添加标记。

从 CVS 中释放工作流 concepts/limitations

Freeing workflow from CVS concepts/limitations

git

version-control

cvs