logo标签列表

版本控制实践

version-control
5

在我的现任工作中，主管的惯例是只检查生产就绪的代码。最近我参与的项目涉及3个不同开发人员的工作，其中一些文件重叠。这意味着尽管某些更改需要一天时间，但仍需手动集成更改。我想知道这是否是常见做法，并获得有关如何改变这种做法的建议，因为很多时候我的意见在大局中并不重要。

11个回答
4
您可以使用不同的方法来处理此情况，具体取决于您的源代码控制系统。
私有分支：允许您在进行工作时检入和处理代码，并在适当的时候进行合并。
Shelvesets / 打包的变更集：允许您存储变更集并将其发送进行审核 - 确保在检入之前它们已经准备就绪。
至于这是否是一种适当的工作方式，我们不允许在没有事先审核的情况下将代码检入主分支。要通过审核，您的代码必须通过各种自动化工具的测试，并且必须被您的同行评审人接受。对于某些定义为“生产就绪”的情况，这就是所需的。因此，我们做了类似于您的做法。但是，我们使用私有分支来确保在此过程中仍然可以进行检入，并且其他检入不必干扰。
如果“生产就绪”意味着在集成环境中进行了测试，那么听起来您可能需要暂存分支或类似的东西。
2

应该对提交的代码进行单元测试，但是对我来说，“生产就绪”意味着它已经通过了集成和系统测试。在代码冻结之前无法进行这样的测试，因此我不明白你如何在每次提交之前都进行这样的测试。

2

首先，将版本控制系统从VSS切换到更可靠且功能丰富的工具。请参阅如何说服公司转换其源代码控制

然后应用已知的良好实践：

  • 经常提交代码
  • 经常获取他人的更改以简化合并
  • 使用快速的单元测试确保每个更改都达到最低标准
  • 要求提交的代码始终能够构建，并始终通过测试。

现在你还没有“生产就绪”：在部署之前仍需要几周时间进行测试和修复。缩短这段时间对您和客户都很有帮助，因此请投资于：

  • 高质量的自动验收测试。
1

在代码库中建立一个测试分支，将非“生产就绪代码”在修改和测试完成后进行检入，这不是个好主意吗？

主干应该永远不会有破坏构建并未通过单元测试的代码检入，但分支不必遵守所有这些限制。

0
我个人不会赞成这种做法，因为有时候这是与经验不足的开发人员一起捕捉问题代码的最佳方式（通过在他们工作时看到它），而且当你“早早地和经常”提交代码时，如果你决定之前所做的某些更改实际上是一个更好的想法，你可以回滚到你之前所做的更改。
0

我认为这可能与我们使用的版本控制工具VSS以及缺乏学习分支相关。我非常喜欢每晚提交代码的想法，以帮助开发并避免“Going Dark”。我可以看出他对主干可能会有所抵触，但也许可以建立一个开发SS，在代码准备好投入生产时将其移动到生产SS。

0

从我所见到的实践来看，“生产质量”这个术语被用作一种“恐吓工具”，以确保人们害怕破坏树的顶部，说实话这并不是什么坏事，因为树的顶部应该尽可能地正常工作。

我认为最佳做法是，您只应将不同（即分离的）功能组件合并到树的顶部。如果对相同源文件的增量存在显着重叠，我认为这可能表明项目管理已经崩溃，那些开发人员应将其更改合并到单独的集成分支中，然后再进入主要的源代码。一个开发人员说他们对自己的东西进行了单元测试是无关紧要的，因为他们测试的东西已经变了！

试图在您的主线代码行上解决整合问题必然会阻碍其他无关提交。

0

假设您正在使用集中式版本控制系统（例如Subversion），并且假设您有一个“主干”概念（其中最新的良好工作代码存放）：

如果您在“功能分支”/“实验分支”上开发新功能，则可以提交远未完成的代码。 （当功能完成时，您将良好行为的结果提交到“主干”中。）

但是，如果将非编译/明显不起作用的代码提交到“主干”或“发布分支”，则您将无法赢得受欢迎的竞赛。

Pragmatic Programmers有一本名为Pragmatic Version Control using Subversion的书，其中包括有关分支的建议部分。

0

早期及经常性检查有两个主要原因 -

1- 可能使代码集成更容易

2- 如果你的电脑爆炸了，你数周的工作不会消失

0

@bpapa

定期将工作文件夹备份到服务器可以避免丢失一天以上的工作。

@tonyo

让我们看看需求文档是在我们编码完成后的第二天才完成的。这告诉你我们的项目管理情况吗？

我们是一个小店，所以尽管你可能认为变化很容易，但这里有些人对旧方式固执不变。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接