在红色、绿色和重构步骤之间自动提交git？

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

我只是想知道以前有没有人试过？我想我读过一次，但是我找不到任何参考资料

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

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

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

我的想法是，我可以在挤压时直观地扫描它，并通过逻辑更改确定将相关的红/绿/重构提交分组到哪里

在最坏的情况下，我认为这可能是一个有趣的实验，在最好的情况下，它可能会给我一种不同的方式来看待我的工作方式。

我喜欢这个想法

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

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

政府可否：

• 提交—当规范未通过且除“规范”文件外没有其他文件更改时，是否修改“红色”
• 之后，由于lib中的更新，只要规范通过，就会提交“绿色”

---

是的，我认为这将是一个有趣的实验，因为收集到的信息分析起来会很有趣。您可以查看您的平均周期时间，并查看项目（文件）中哪些部分的周期时间较慢，可以将其作为代码度量。git日志中的信息越多越好。。i、 e.哪种规格不合格等。请分享该想法的任何进展和/或结果。
哇！！信不信由你，几天前（作为一个周末项目），当我阅读单元测试时，我有一个类似的想法，我想为git构建一个模块，做类似的事情
我的想法不是完全自动化，而是一部分。例如，自定义提交将看到什么是红色并给它们一些ID，随后的绿色将看到所有红色都解决了什么问题，并在提交消息中附加适当的注释以及测试ID和红色提交
一些附加功能可能包括根据某些条件浏览这些提交

---

无论如何，如果你找到了你正在谈论的这个参考资料，请更新这个帖子。
我喜欢这个，我自己也考虑过一两次。我不确定我是否完全明白它的价值。乍一看，我以为这会使我很容易回到我最后一个已知的绿色状态。看过JUnitMax之后，它内置了“恢复绿色”功能，因此我从那以后就没有想过要自动提交。
我考虑过这种工作流。首先，我打算在每次运行规范之后提交。不过，在没有州变的情况下进行修改可能会减少噪音。