在红色、绿色和重构步骤之间自动进行 git 提交？
我总是对在我的工作流程中尝试新事物感兴趣，我认为在红色、绿色和重构步骤之间自动提交可能是一个有趣的实验，但一旦我完成特定功能（并且在推送之前），然后手动压缩提交）。
我只是想知道以前是否有人尝试过这个？我以为我读过一次，但我找不到任何参考资料。
我希望一个好处可能是更多地关注经常提交，以及能够直观地看到我的工作流程，以便我可以改进它。例如，在压缩之前，我可以查看红色和绿色之间的时间是否太长，或者我所做的代码更改数量是否大于每个步骤之间所需的数量。
我打算将其实现为 guard 插件，以便当我保存规范或库文件时，它会运行规范并使用如下提交消息提交更改：
Green: 1621 examples, 0 failures, 2 pending (1659 tests/s, 0.0006 p/test)
这个想法是，我可以在压缩时直观地扫描它，并确定在哪里通过逻辑更改对相关的红色/绿色/重构提交进行分组。
在最坏的情况下，我认为这可能是一个有趣的实验，在最好的情况下，它可能会给我一种不同的方式来看待我的工作方式。
I'm always interested in trying new things with my workflow, and I thought it might be an interesting experiment to automatically commit between red, green and refactor steps, but then manually squash the commits down once I finish a specific feature (and before pushing).
I was just wondering if anyone else has tried this before? I thought I read about this once, but I'm unable to find any references.
I'm hoping one benefit might be to focus more on committing often, as well as being able to see my workflow visually so that I can improve it. For example, before squashing I can see if my time between red and green is too long, or if the number of code changes I make is larger than necessary between each step.
I was going to implement this as a guard plugin so that when I save a spec or library file, it runs the specs and commits the change with a commit message like:
Green: 1621 examples, 0 failures, 2 pending (1659 tests/s, 0.0006 p/test)
The idea being that I could visually scan this when squashing and determine where to group the related Red/Green/Refactor commits by logical changes.
At worst I thought this might be a fun experiment, at best it might give me a different way of seeing how I work.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
是的，我认为这将是一个有趣的实验，因为收集到的信息分析起来很有趣。您可以查看平均周期时间，并查看项目（文件）的哪些部分的周期时间较慢，这可以视为代码指标。 git 日志中的信息越多越好……即哪个规范失败了等等。请分享来自这个想法的任何进展和/或结果。
Yeah, I think this would be a fun experiment to do as the information gathered would be interesting to analyze. You could look at your average cycle times, and see what parts of the projects (files) have slower cycle times which could be veiwed as a code metric. The more information in the git log the better.. i.e. which spec is failing etc. Please share any progress and/or results that come from the idea.
哇！！不管你信不信，几天前我有一个类似的想法（作为一个周末项目），当我阅读单元测试时，我想为 git 构建一个模块来做类似的事情。
我的想法不是完全自动化，而是一部分。例如，自定义提交将查看什么是 RED 并给它们一些 ID，随后的 GREEN 将查看它解决的所有 RED 内容，并在提交消息中附加合适的注释以及测试 ID 和 RED 提交。
一些附加功能可能包括根据某些标准浏览这些提交...
无论如何，如果您找到您正在谈论的此参考，请更新此线程。
Wow!! Believe it or not, I had a similar idea a few days back (to do as a weekend project), when I was reading on Unit Testing, that I wanted to build a module for git doing similar thing.
My idea was not completely automating, but rather a part. For example, a custom commit will see what are the REDs and give them some ID, and subsequent GREEN will see what all REDs does it solve, and append a suitable comment in the commit message along with the test ID and the RED commits.
Some additional functionality may include browsing through these commits based on some criteria...
Anyways, if you find this reference that you are talking about, please update this thread.
我喜欢这个，并且自己也考虑过一两次。但我不确定我是否完全看到了它的价值。乍一看，我认为这可以很容易地回滚到我最后知道的绿色状态。在看到 JUnitMax 后，它内置了“恢复为绿色”功能，因此我从那时起就没有感觉到自动提交的愿望。
I like this and have considered it myself a time or two. I'm not sure I completely see the value of it though. At first blush I thought it would make it easy to roll back to my last known green state. After seeing JUnitMax, it has the "revert to green" functionality built in, so I haven't felt the desire since to auto commit.
我喜欢这个主意。
展示新的/更新的规格可能是一个优点。 :)
对于这个插件来说，要知道代码何时达到“真正的”红色/绿色状态可能很棘手。
它会：
I like the idea.
Showing the new / updated spec could be a plus. :)
It might be tricky for this plugin to know when the code reached a "true" Red / Green state.
Would it: