23

我非常喜欢Gitflow 分支模型

，但我不确定将 TDD 循环放在哪里——我是否应该在每次编写或通过测试时（加上重构后）简单地使用功能分支并提交？创建一个子分支并将“完成”单元合并到功能分支中？我应该提交每个失败的测试还是只有在它通过之后？

这是我目前在功能分支上所做的：

  1. 编写测试，提交
  2. 由于不存在的接口，测试可能会产生错误，修复此问题，修改提交
  3. 使（现在只有失败的）测试通过，修改提交
  4. 重构，新提交
  5. 转到 1
4

5 回答 5

9

我不确定这是否具有代表性，但作为一名开发人员，我使用 git-flow，这是（大致）我的新功能工作流程：

  • 创建功能分支
  • 编写失败的高级验收测试（黄瓜）并带有@wip（正在进行的工作）标签，因此它现在被排除在测试套件之外，并将其提交到新分支
  • （有时）为边缘案例的集成测试编写 rspec 请求测试，并将其提交到功能分支
  • 为功能的各个组件编写较低级别的测试（rspec/jasmine），并为每个粗略定义的“单元”提交到功能分支
  • 当功能完成足以通过验收测试时，取下@wip标签，确保它通过并提交到功能分支
  • git merge使用（而不是）将功能分支合并到开发分支中git flow finish。这会将功能分支留在那里，因此我可以稍后在需要时更新该功能。
  • 一旦分支合并到开发中，travis-ci 就会在其上运行完整的测试套件，如果有任何问题，我会收到一封电子邮件。（我只在我的 .travis.yml 文件中包含了开发和主分支。）

我应该说，这是我的“理想”工作流程——在实际实践中，我经常打破这些规则：在编写测试之前提交未经测试的更改，在实际充实高级验收测试之前开始处理部分功能，等等。我基本上是唯一一个致力于该项目的人，所以我可以自由地这样做；如果您在一个更大的团队中工作，我认为您必须更加严格地坚持您拥有的任何工作流程。

无论如何，我就是这样做的。我也很想听听其他人的意见，所以我赞成这个问题。

更新：

写完这篇文章后，我意识到我在一种意义上偏离了上述流程，那就是当我添加“功能”时，这些“功能”并不是严格意义上的面向用户的普通类型（即不是用户会意识到的东西）的）。例如，在开发应用程序的早期，我们决定使用backbone.js 来构建我们的js 代码——所以我为它创建了一个特性分支，并@javascript为各种现有的黄瓜特性添加了标签。一旦分支大致能够（使用backbone.js）执行原始应用程序使用HTML 视图所做的事情，我就将其合并回来。

我还计划改用 require.js，在这种情况下，我还将为此创建一个功能分支，并在完成后将其合并回来。不会有任何高级集成测试——只要现有的测试通过，一切都很好。

于 2012-08-16T11:21:21.297 回答
6

我认为一个好的和简单的指导方针是在你每次“绿色”时提交，或者至少在每个测试周期提交：

  • 红色 -> 绿色 -> 重构 ->提交
  • 或红色 -> 绿色 ->提交-> 重构 ->提交
于 2012-08-17T11:00:55.887 回答
4

我的工作流程非常相似，但请考虑更好地利用暂存区。

  1. 写一个测试，git add。
  2. 由于不存在的接口，测试可能会产生错误，修复这个，git add。
  3. 使（现在只有失败的）测试通过，git commit。
  4. 重构，git commit 修改。
  5. 转到 1。

这加强了每次提交时所有测试都通过的纪律。在阶段 1-3 中，我可以随时使用 git checkout 回滚到最后一个 git add。

于 2016-06-09T09:19:46.517 回答
2

考虑何时应该提交的简单方法是：

  1. 我可以用有意义的提交消息来描述我正在提交的内容吗？
  2. 我是否有任何理由想回到这一点或从这一点出发？

这意味着它真的取决于人。如果您从未发现自己在某个阶段进行了差异化，也许是因为您修复它的速度足够快以至于您仍然可以记住您所做的更改，那么您实际上不需要提交。但是，除了键入命令所需的时间之外，它也没有任何害处。

如果您真的不觉得某个步骤值得长期提交，另一种选择是只做一个git add. 这样，git diff将显示自添加以来发生的变化，并git diff --cached显示之前发生的变化。这就是我所做的，因为我更喜欢我的提交是可编译的并通过单元测试。这样，很容易回到已知的良好状态。

于 2012-08-16T13:04:40.710 回答
1

我不相信有特定于 TDD 的提交工作流，我尝试遵守的唯一相关规则是我尽量不要将带有损坏测试的提交推送到主分支（除非它已经损坏）。在我的特性分支上，通常只测试与特性相关的测试，但在执行合并回主控时，所有测试都会经过审查。如果我知道提交确实导致某些功能测试被破坏或其他原因导致它如此，那么只有这样我才会将其指示为 wip。在更实际的方面，我认为特别注意避免将提交推送到错误的分支会带来更多好处。

于 2012-08-16T13:14:45.057 回答