什么是TDD的好git工作流？

>创建一个特征分支
>写入失败的高级验收测试(黄瓜)失败与一个@wip(工作进行中)标签，所以它现在被遗漏在测试套件之外，并提交到新的分支
(有时)写rspec请求测试用于边缘情况的集成测试，并将其提交到特征分支
>为特征的各个组件编写下级测试(rspec / jasmine)，并为每个粗略定义的“单位”写入下级测试(rspec / jasmine)，提交到特征分支
>当功能完成后，通过验收测试，取出@wip标签，确保它通过并提交到功能分支
>使用git merge(而不是git flow finish)将特征分支合并到开发分支中。这使得功能分支在那里，所以我可以稍后更新功能，如果需要的话。
>一旦分支合并开发，travis-ci将运行完整的测试套件，如果有任何问题，我会收到一封电子邮件。 (我只包括我的.travis.yml文件中的开发和主分支。)

我应该说，这是我的“理想”工作流程 – 在实际实践中，我打破了这些规则：在编写测试之前提交未经测试的更改，在实际完成高级验收测试之前开始部分功能的开发，我基本上是唯一承诺这个项目的人，所以我有自由去做;如果你在一个更大的团队工作，我想你必须更严格地坚持你所拥有的任何工作流程。

无论如何，我该怎么做我也很乐意听别人的话，所以我提出了这个问题。

更新：

在写这个之后，我意识到有一种我偏离上述流程的感觉，那就是当我添加“功能”时，这并不是严格地说正常的面向用户的类型(即不是用户意识到的东西)的)。例如，在开发应用程序的早期，我们决定我们想使用backbone.js来构建我们的js代码 – 所以我为它创建了一个功能部件，并且添加了@javascript标签到现有的黄瓜功能。一旦分支大致能够(使用backbone.js)，原始应用程序正在使用HTML视图，我将它合并回来。

我也打算使用require.js，在这种情况下，我也会创建一个功能部门来完成这个操作，一旦完成它的合并就可以了。不会有任何高级别的集成测试 – 只要现有测试通过，这一切都很好。