我非常喜欢Gitflow branching model
但我不知道在哪里放置TDD周期 - 我应该只使用一个功能分支并在每次写入或通过测试时提交(加上重构后)?创建一个子分支并将“已完成”单元合并到功能分支中?我是应该在每次失败的测试中进行测试还是仅在测试完成后才进行测试?
以下是我目前在功能分支上所做的事情:
答案 0 :(得分:7)
我不确定这是否具有代表性,但只是作为一名开发人员发言,我使用git-flow和这里(大致)我的工作流程来获取新功能:
@wip
(正在进行中)标记失败的高级验收测试(黄瓜)失败,以便暂时不在测试套件中,并将其提交给新分支@wip
标记,确保它通过并提交到功能分支git merge
(而非git flow finish
)将功能分支合并到开发分支中。这使功能分支留在那里,以便我可以在以后需要时更新该功能。我应该说,这是我的“理想”工作流程 - 在实际操作中我违反了这些规则:在编写测试之前提交未经测试的更改,在实际充实高级别之前开始处理部分功能验收测试等我基本上是唯一承诺该项目的人,所以我有自由这样做;如果你在一个更大的小组工作,我认为你必须更严格地坚持你所拥有的任何工作流程。
无论如何,我就是这样做的。我也热衷于听取其他人的意见,所以我提出了这个问题。
<强>更新强>
我在写完之后意识到有一种感觉,我偏离了上面的流程,这就是当我添加“功能”时,这些功能并不严格地说是普通的面向用户的类型(即不是用户的东西)会意识到)。例如,在开发应用程序的早期,我们决定使用backbone.js来构造我们的js代码 - 所以我为它创建了一个功能分支,并为各种现有的黄瓜功能添加了@javascript
标签。一旦分支完全能够(使用backbone.js)原始应用程序使用HTML视图执行的操作,我就将其合并。
我还打算切换到使用require.js,在这种情况下,我还会创建一个功能分支来执行此操作,并在完成后将其合并回来。它不会有任何高级集成测试 - 只要现有测试通过,它就会很好。
答案 1 :(得分:3)
我认为,每当您处于“绿色”或至少每个测试周期时,都会提交一个简单明了的指南:
答案 2 :(得分:2)
考虑何时应该提交的简单方法是:
这意味着它真的取决于这个人。如果你从未发现自己在其中一个阶段做过差异,也许是因为你足够快地修复它以至于你仍然可以记住你改变了什么,那么你真的不需要来提交。但是,除了输入命令所需的时间外,它也没有任何害处。
另一个替代方案是,如果你真的感觉不到一个步骤需要长期提交,那就是做一个git add
。这样,git diff
将显示自添加以来发生了哪些更改,git diff --cached
将显示之前已更改的内容。这就是我所做的,因为我更喜欢我的提交是可编译的并通过单元测试。这样,很容易回到已知的良好状态。
答案 3 :(得分:1)
我不相信有一个特定于TDD的提交工作流,我试图遵守的唯一规则是我尝试不将破坏测试的提交推送到主分支(除非它已经是破碎)。在我的功能分支上通常只测试与功能相关的测试,但是在执行合并回主控时将审查所有测试。如果我知道提交确实会使某些功能测试失效或者其他原因导致这样做,那么我只会将其指示为wip。在更实际的方面,我认为采取额外的谨慎避免将提交推送到错误的分支机构会有更多好处。
答案 4 :(得分:1)
我的工作流程非常相似,但考虑更好地利用临时区域。
这强制执行在每次提交时所有测试都通过的规则。在阶段1-3期间,我可以随时使用git checkout回滚到最后一个git add。