使用 GIT 进行源代码控制时，何时应在 TDD 中提交更改？ [关闭]

Question

我们正在讨论如何在 SAFE for SCRUM 中使用 TDD 构建我们的开发工作流程。尽管事情结构良好，但我不清楚何时应该在本地进行一次提交更改，以及何时推送它们。

是否应该每天都这样做/在此期间是否可以在本地进行小型提交，是否应该向上推？标准做法是什么？

框架对“何时”和“多久”有什么规定？

Answer 1

考虑在 GIT 中使用开发和功能分支。

您的主分支应始终包含该软件的工作可部署版本。所有“开发”都可以在开发分支上完成，并且只有在准备发布时才合并到主分支中。

• 开发人员创建自己的功能分支，并应根据需要（定期）检查此功能
• 每个功能完成后，将功能分支合并到开发中
• 当你有足够的功能时，合并到 Master 中发布

使用 TDD 不应影响您的签到策略。总体目标是始终有一个有效的构建。

Answer 2

如前所述，我支持开发和功能分支。 SAFE 要求每天提交的粒度。这意味着服务器端分支。还要求这些提交具有“工作代码”。在 TDD 下，这意味着测试通过了。

所以政策是：

(1) 至少在 sprint 结束之前发生合并的开发分支 (3w AFAIK)

(2) 涉及的开发人员在一天结束时提交工作代码的功能分支

(3) 每个提交都必须是工作代码

(4) 本地每个人都可以保留自己的历史记录，例如具有 non-working-code 的不同分支，但应该向上推动提交。

点 (1) 和 (2) 实际上在 SAFE 中是开放的，但 (3) 和 (4) 不是。

请记住，TDD 规定测试应该在代码开发之前编写，但这并不总是可能的，并且在 scrum 下可以重复它们，但总是在代码演化之前。