Version control 回到基本点：什么是好的入住流程？

我的团队一直在为我们自己的项目工作。我编写代码，将其签入源代码管理，很少有人看到它（除了最终产品）。其他所有人都遵循相同的基本流程

团队开始成长，我们所从事的项目也在成长。我们很快就需要开始共同编写项目代码。新来的家伙在尝试执行任何签入过程时都没有成功，导致构建失败

我们中的一些人一直在谈论记录我们的流程，作为确保我们都在同一页的第一步。这将是轻阅读，不一定详细“点击这个，键入这个，现在点击那个”之类的东西。例如，我们的第一个流程文档是“如何签入代码”

在我看来，这个过程与

签入之前，确认您的代码在本地生成和执行

获取最新信息

手动解决任何冲突

确保您的东西使用上述步骤中检索到的最新位在本地构建和执行

登记入住

那么，我来回答这个问题。良好的入住流程需要哪些额外步骤？这样做真的有意义吗？我倾向于这样认为，因为假设我们都知道该做什么还没有真正奏效

---

谢谢

我认为您概述的5个步骤是确保构建不被破坏所必须执行的最小步骤

最后一步可能还需要运行任何代码验证（单元测试、样式cop、fx cop、代码格式）。您可能还希望在提交之前进行代码审查，或者提交到暂存区域进行审查

---

您可能还希望在之后执行干净的签出和构建/测试，因为这样可以捕获尚未添加的本地文件。如果您有一个构建服务器，这可能会走得太远，因为它会抓住这一点。

我敢打赌，任何假定用户会遵循它的过程都是不可取的。人类很少这样做。 但是有一个替代方案可以鼓励每个人都做你想做的事（如果合适，还可以做更多）：
1.设置一个持续集成服务器，并将其配置为编译并运行您的代码（与您希望您的人员“在本地执行”的代码相同）。
2.破坏建筑是可耻的。这样做依赖于文化；有时候分享统计数据就可以了，有时候你需要给破坏构建的人的直接经理发电子邮件，不管是什么

有了这个过程，如果正确地实施，每个人都会做它需要做的事情（例如，如果不做“获取最新信息”是有风险的，他们会学会随着时间的推移去做）

---

另一个要考虑的问题是执行对等代码审查，但这一点实际上取决于团队规模和文化是工作的（即使它总是具有成本效益的，甚至几乎不工作，根据我的经验）。

< P>而不是添加过程，为什么不说“新家伙”，并告诉他什么是期望的。当涉及到提交清单时，它们需要灵活，并为常识留出空间。我曾经遇到过这样的情况：提交字符串更改需要四个小时的构建+两个小时的自动测试。别让它变得可笑

应该很少有关于承诺的具体规则。我喜欢这些规则：

不要提交损坏的代码。它必须按预期编译和运行

合并时请注意

如果开发人员的提交破坏了构建，那么他们会感到羞耻。如果开发人员引入了合并损害，他们会感到羞耻。话虽如此，我还是喜欢准备一些工具来确保事情不会失控

• 一旦发生提交，SCM会立即向整个团队发送提交差异
• 持续集成可以立即构建。根据我的经验，每15分钟检查一次更换是不够的。通过钩子触发CI构建，或每1-5分钟检查一次更改
• 使提交历史记录易于通过浏览器访问

---

我还希望每个提交都由另一个团队成员签署。一些SCM系统可以帮助您完成此工作流程。

您似乎忘记了在签入之前通过所有单元测试的步骤…@Sam-是的，单元测试。小步说，我正在把单元测试作为过程的一部分。