Question

我总是对使用我的工作流程尝试新事物感兴趣，并且我认为在红色，绿色和重构步骤之间自动提交可能是一个有趣的实验，但是在完成特定功能后手动压缩提交（在推之前。

我只是想知道其他人是否曾尝试过这个？我以为我曾经读过这个，但我找不到任何参考资料。

我希望一个好处可能是更多地关注经常提交，以及能够直观地看到我的工作流程以便我可以改进它。例如，在挤压之前，我可以看到红色和绿色之间的时间是否太长，或者我所做的代码更改次数是否大于每个步骤之间所需的时间。

我打算将其作为guard插件实现，这样当我保存规范或库文件时，它会运行规范并使用提交消息提交更改，如：

Green: 1621 examples, 0 failures, 2 pending (1659 tests/s, 0.0006 p/test)

我的想法是，我可以在压缩时进行可视化扫描，并确定通过逻辑更改对相关的红色/绿色/重构提交进行分组的位置。

在最糟糕的情况下，我认为这可能是一个有趣的实验，充其量它可能会让我以不同的方式看待我的工作方式。

Answer 1

我喜欢这个主意。

显示新的/更新的规格可能是一个加号。：）

这个插件知道代码何时达到“真正的”红/绿状态可能会很棘手。

它会：

Answer 2

是的，我认为这将是一个有趣的实验，因为所收集的信息很有意思。您可以查看平均周期时间，并查看项目（文件）的哪些部分具有较慢的周期时间，这可以作为代码度量标准进行调整。 git日志中的信息越多越好..即哪个规范失败等。请分享来自该想法的任何进展和/或结果。

Answer 3

哇!!信不信由你，几天前我有一个类似的想法（作为一个周末项目），当我阅读单元测试时，我想为git做类似的事情构建一个模块。

我的想法并非完全自动化，而是一部分。例如，自定义提交将查看什么是RED并为其提供一些ID，后续GREEN将查看所有RED解决的问题，并在提交消息中附加适当的注释以及测试ID和RED提交。 / p>

其他一些功能可能包括根据某些标准浏览这些提交......

无论如何，如果你发现你正在谈论这个参考，请更新这个帖子。

Answer 4

我喜欢这个并且自己考虑过一两次。我不确定我是否完全看到它的价值。乍一看，我认为这会让你很容易回到我上次知道的绿色状态。在看到JUnitMax之后，它内置了“恢复为绿色”的功能，所以我没有感受到自动提交后的愿望。