我们怎么做版本控制有什么问题吗？

Question

作为业务分析师，我与一组程序员一起工作。我们刚刚发布了2.0版本的产品，并正在开发下一个版本，将在3个月后发布(这是一个内部软件产品)。不幸的是，2.0版本有一些问题需要修复，我们将在几周后部署这些修复程序。问题是，我们也不希望部署仍在进行的更改，并且计划在3个月后才会发布。

程序员决定，管理这些缺陷的方法是，只有针对缺陷的代码才会被签入，而新增强的代码将保留在开发人员的本地机器上，直到它们完成为止。我将不得不从他们的机器上测试本地构建，因为如果他们签入了代码，我们必须推出另一个修补程序来修复缺陷，我们还不想包括这些增强。同样的问题是，相同的代码文件同时包含缺陷修复和增强，因此他们必须在本地复制代码文件，然后进行更改以修复bug并签入该错误，然后通过获取它们所做的本地副本继续进行增强工作。

这似乎相当复杂-有更好的方法来处理这种情况吗？我们使用和Visual 2010。

Answer 1

V2.0应该有我们所称的‘稳定状态分支’(我们使用Perforce，而不是TFS)。对于v2的任何修复都会被发送到这个分支，然后传播回v3开发分支，而v3特性也会被处理，也就是说，v2上的缺陷也会导致v3上的缺陷。

在开发人员的机器上进行更改很长一段时间可能会导致集成噩梦。

Answer 2

多途径可以处理这样的问题，通常由“分支”标签来处理，每个问题都有各自的优点和缺点。

但是你的开发者选择的方法..。哎呀，我会口头引用，以确保我没有误解.

密码..。将被保存在开发商的本地机器上直到它们完成..。

像上面这样的...the方式可能是唯一一个完全错误的方法！

对我来说，这几乎是犯罪行为，对于TFS来说，有一个优秀的、易懂的、分支指南 --庞大而详细的文档，其中包含针对各种不同项目(这里的版本)的精心定制和解释的分支策略建议。

Answer 3

1. 您的开发人员对如何使用版本控制有一个根本的误解。
2. 不要讨论“正确”的版本控制软件。这不是问题所在。
3. 每一次代码调整都会使问题更难解决。
4. 当你们决定做正确的事情时，您不能在修复事情时继续进行代码更改。您必须停止所有开发，并将代码放到版本控制中。
5. 开发人员一定感到了足够的痛苦，至少可以坐下来谈谈。
6. 所有版本控制软件都支持基本概念：。
   • 所有代码都进入版本控制存储库。
   • 所有代码文件都有版本号。当重新签入代码时，这些数字会自动递增。
   • 标记标记特定版本的所有代码文件。因此，我们可以标记软件版本1发行版，例如。
   • 树枝是从主树干上“转开”的。
     • 对分支所做的任何和所有更改都不会影响主干。
     • 您可以在某个时候将分支更改合并回主主干。
     • 因此，我们可以不用担心搞砸“好东西”，就可以进行实验。

7. 你们必须得到版本控制“信仰的飞跃”，正如我所说的。相信遵循基本规则，事情就会一帆风顺。缺乏经验会让我们不这么想，相信我。
8. 这是一个不错的教程。它是通用和完整的，所以您不需要浏览许多其他来源的
   • 版本控制，更好的解释

编辑

• 将版本控制放在您的工作计算机上。
  • 你现在就可以做好团队协调。
  • 即使有团队版本控制，我也强烈推荐
  • 如果您的团队使用Git或Mercurial，您将使用独立的本地存储库。这就是分布式版本控制的工作方式。
  • 您可以使用与您的团队不同的VC软件。我们的团队使用Subversion，我在本地使用Mercurial。VC软件元文件(".svn“、".mg”、隐藏文件夹)不冲突。

您并不是作为一个事实上的团队存储库。它用于管理您自己的工作、重构工作等，并在团队继续使用FUBAR代码库时亲自进行CYAing。

端编辑