我们进行版本控制的方式有问题吗？

我和一个程序员团队一起担任业务分析师。我们刚刚发布了该产品的2.0版，并且正在开发3个月内发布的下一个版本（这是内部软件产品）。不幸的是，版本2.0存在一些必须修复的问题，我们将在几周内部署这些修复程序。问题在于，我们也不想部署仍在进行中且计划在未来3个月内不发布的更改。

程序员认为管理此问题的方法是仅检入缺陷代码，而新增强功能的代码将保留在开发人员的本地计算机上，直到完成。我将不得不从他们的机器上获取本地版本进行测试，因为如果他们签入代码，并且我们必须推出另一个补丁来修复缺陷，我们现在还不希望包括这些增强功能。还有一个问题，即同一代码文件同时包含缺陷修复程序和增强功能，因此他们必须在本地复制该代码文件，然后进行更改以修复错误并检查其中的一个错误，然后通过采用以下方法继续进行增强功能：他们制作的本地副本。

似乎很令人费解-是否有更好的方法来处理这种情况？我们正在使用Team Foundation Server和Visual Studio 2010。

V2.0一旦发布，就应该具有我们所谓的“稳态分支”（我们使用Perforce，而不是TFS）。对v2的任何修复都将在此分支上进行，然后传播到v3开发分支，同时还正在处理v3功能，即v2上的缺陷也将导致v3上的缺陷。

将更改长时间保留在开发人员的计算机上可能会导致集成梦are。

嗯，有很多方法可以解决类似的问题，这些问题通常由“分支”标签涵盖，每种方法都有其自身的优点和缺点。

但是开发人员选择的方法...亲爱的，我会口头引用它，以确保我不会误读...

代码...将保留在开发人员的本地计算机上，直到完成...

...上面的方式可能是唯一完全错误的方式！

对我来说，成为犯罪分子的是，对于TFS，有一个出色的，易于理解的Microsoft Team Foundation Server分支指南 -庞大而详细的文档，其中包含针对各种不同项目精心定制和说明的分支策略建议（HTML版本在这里）。

1. 您的开发人员对如何使用版本控制有根本的误解。
2. 不要讨论“正确的”版本控制软件。这不是问题。
3. 每次代码调整都会使问题更难解决。
4. 当大家都决定做正确的事情时，您无法在修复问题时继续进行代码更改。您必须停止所有开发并将代码放入版本控制中。
5. 开发人员必须感觉到足以至少坐下来谈论它的痛苦。
6. 所有版本控制软件都支持基本概念：
   • 所有代码都进入版本控制存储库。
   • 所有代码文件都有版本号。这些数字会随着代码重新签入而自动增加。
   • TAG标记一个（或一个）特定版本的所有代码文件。因此，例如，我们可以标记软件版本1。
   • 分支是从主干路 “转身” 。
     • 对分支所做的所有更改均不会影响中继。
     • 您可以选择在某个时候将分支更改合并回主干。
     • 因此，我们可以进行实验而不必担心弄乱“好东西”。
7. 大家都必须得到我所说的版本控制“信念的飞跃”。相信遵循基本规则将使事情变得简单。没有经验会让我们以为别的，相信我。
8. 这是一个不错的教程。它足够通用和完整，您无需搜索其他许多资源
   • 版本控制，更好的解释

编辑

• 将版本控制放在您的工作计算机上。
  • 您无需团队协作即可立即执行此操作
  • 即使使用团队版本控制，我还是强烈建议您这样做
  • 如果您的团队使用Git或Mercurial，则您使用的是独立的本地存储库。这就是分布式版本控制的工作方式。
  • 您可以使用团队中的其他VC软件。我们的团队使用Subversion，我在本地使用Mercurial。VC软件图元文件（“ .svn”，“。mg”，隐藏文件夹）不冲突。

您没有充当事实上的团队存储库。它用于管理您自己的工作，重构工作等，并且在团队继续完善代码库的同时，对自己进行说明。

结束编辑

您所描述的是使用版本控制的糟糕方法。应该有一个针对2.0版的分支，或者一个标签或一些标识符。这样，可以包含对该版本的修改，并且可以继续进行更多开发。

本文可以给您一些想法。它是在编写时git考虑到的，但是没有理由也不能使用它mercurial。我意识到您没有使用这两种方法，但这也是您应该考虑修复的问题。

快速解答：开发团队应该有一个独立的分公司生产，以保持部署的代码库V2.0从独立的主干线。

为了使代码保持同步，需要首先在该分支中完成所有错误修复，然后对其进行测试并部署到其他分支。

您的项目还应该具有多个环境，for health development例如Prod，Staging，QA和Dev（有时是UAT）。这些环境应在进入生产发布之前进行设置。

总而言之，准备好进行错误和修改是支持已发布应用程序的方式。

由于提到了TFS作为版本控制，因此我还整理了一些文章列表，这些文章将有助于设置健康开发环境：

• 与小型开发团队一起实施Team Foundation Server
• 欢迎使用TFS集成平台！
• TFS团队开发指南
• 搭建开发环境

不可以，因为在使用VCS时，您没有进行版本控制。

版本控制的中心概念是随着时间的推移跟踪差异，您正在计划记录一些差异，但是目前您的大部分更改尚未记录。

正如其他人所说，您应该使用分支。设置完成后，您应该检查所有功能更改（即，不是每次按键都可以，但是在您修复错误，添加功能，删除功能或以其他方式完成更改以使其仍可正常工作时）。

我是开发人员，我们为当前版本的修复提供了不同的分支代码和数据库，为增强功能和后续的后续版本提供了不同的分支代码和数据库。

修复完成后，它们将与生产合并并部署，我们将获得新的分支以再次用于增强功能。

此外，我们遵循一种做法，例如我的当前版本有10个修复程序

我写为

//Start Iteration 2, Fix No-1, Branch No-"ABC"
code where I have done changes or fixes or added new code lines
//End Iteration 2, Fix No-1, Branch No-"ABC"

类似地，对于其他修复程序，我只为更改或添加以进行修复的每一行执行此操作。然后比较并提交。同样，如果他们在同一分支上并行执行，则可以使用

//Start Enhancement -1, Branch No-"ABC" 
code where I have done changes of fixes or added new code lines
//End Enhancement -1, Branch No-"ABC" 

Ctrl+Shift+F//Start Iteration 2, Fix No-1, Branch No-"ABC" 在整个解决方案中搜索的命令和类型可以帮助您找到确切的位置，更改了代码的文件并仅使用可用于提交的新代码。