紅色，綠色和重構步驟之間的自動git commit？

Question

我總是對使用我的工作流嘗試新事物感興趣，我認爲這可能是一個有趣的實驗，可以在紅色，綠色和重構步驟之間自動進行提交，但是在完成特定功能後手動壓縮提交（以及推之前）。

我只是想知道是否有人嘗試過這個？我以爲我曾閱讀過這篇文章，但我無法找到任何參考。

我希望一個好處可能會更側重於經常犯，也能看到我的工作流程可視化，這樣我就可以改善。例如，在壓扁之前，我可以看到紅色和綠色之間的時間是否過長，或者如果我在每一步之間所做的代碼更改次數大於必需次數。

我要實現這個作爲guard插件，這樣當我保存規格或庫文件，它運行的規範和承諾與像提交信息的變化：

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

的想法是，我可以在擠壓時直觀地掃描這些信息，並根據邏輯變化確定將相關的Red/Green/Refactor提交進行分組。

在最壞的情況我想這可能是一個有趣的實驗，充其量可能會給我看到我是如何工作的不同方式。

Answer 1

我喜歡這個主意。

顯示新的/更新的規範可能是一個加號。 :)

這可能是棘手的這個插件，知道什麼時候該代碼達到了「真正的」紅/綠狀態。

難道：

• 犯下--amend「紅色」時的規格不傳球和不超過「規範」文件等文件中改變了嗎？
• 之後提交'綠色'只要規格通過，因爲lib中的更新？

Answer 2

是的，我認爲這將是一個有趣的實驗，因爲收集的信息會有趣的分析。您可以查看您的平均週期時間，並查看項目（文件）中的哪些部分的循環時間較慢，這些時間可以作爲代碼度量標準來查看。 git中的更多信息越好越好。即哪個規範失敗等。請分享任何來自該構思的進度和/或結果。

Answer 3

哇！信不信由你，我幾天前有一個類似的想法（做週末項目），當時我正在閱讀單元測試，我想爲git構建一個模塊來做類似的事情。

我的想法並沒有完全自動化，而是一個組成部分。例如，自定義提交將會看到什麼是RED，併爲它們提供一些ID，隨後的GREEN將會看到所有RED解決的問題，並在提交消息中附加適當的註釋以及測試ID和RED提交。

一些附加的功能可以包括通過基於一些標準，這些提交瀏覽...

不管怎麼說，如果你發現這個參考你所談論的，請更新這個帖子。

Answer 4

我喜歡這個，並自己考慮過一兩次。我不確定我是否完全看到它的價值。乍一看，我認爲這會讓我很容易回到我最後知道的綠色狀態。看到JUnitMax後，它具有內置的「恢復爲綠色」功能，所以我沒有覺得自動提交的願望。