6

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

我只是想知道是否有人以前尝试过这个？我以为我读过一次，但我找不到任何参考资料。

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

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

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

这个想法是我可以在压缩时直观地扫描它，并通过逻辑更改确定在哪里对相关的 Red/Green/Refactor 提交进行分组。

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

4

4 回答 4

1

是的，我认为这将是一个有趣的实验，因为收集到的信息对分析很有趣。您可以查看您的平均周期时间，并查看项目（文件）的哪些部分具有较慢的周期时间，可以将其视为代码指标。git log 中的信息越多越好。即哪个规范失败等。请分享来自这个想法的任何进展和/或结果。

于 2011-08-15T16:59:46.987 回答
1

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

我的想法不是完全自动化，而是一部分。例如，自定义提交将查看 RED 是什么并给他们一些 ID，随后的 GREEN 将查看所有 RED 解决了什么问题，并在提交消息中附加合适的注释以及测试 ID 和 RED 提交。

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

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

于 2011-08-16T14:07:57.450 回答
1

我喜欢这个，我自己也考虑过一两次。我不确定我是否完全看到它的价值。乍一看，我认为它可以很容易地回滚到我最后一次知道的绿色状态。看到 JUnitMax 后，它内置了“恢复为绿色”的功能，所以从那以后我就没有自动提交的欲望了。

于 2011-08-17T01:24:03.837 回答
1

我喜欢这个主意。

显示新的/更新的规范可能是一个加分项。:)

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

会不会：

  • 当规范没有通过并且除了“规范”文件之外没有其他文件被更改时提交--修改“红色”？
  • 之后由于 lib 中的更新而在规范通过后立即提交“绿色”？
于 2011-08-15T16:51:43.307 回答