重構和非重構更改作爲單獨的簽入？

Question

您是否將重構更改與功能開發/錯誤修復更改混合在一起，還是讓它們保持獨立？大規模重構或可以使用Resharper這樣的工具執行的代碼重新格式化應該與特性工作或錯誤修復分開，因爲很難在修訂之間進行差異並在衆多重構更改中看到代碼的實際更改。這是一個好主意嗎？

Answer 1

當我記得時，我喜歡在重構後檢查以準備添加功能。通常它會使代碼處於更好的狀態，但不會改變行爲。如果我決定退出該功能，我總是可以保留更好的結構化代碼。

Answer 2

通常，我檢查何時完成了一些工作單元，並且代碼返回到編譯/單元測試爲綠色。這可能包括重構。我會說最好的做法是試圖將它們分開。我發現這很難處理我的工作流程。

Answer 3

保持簡單。

每次檢入對代碼庫應該是一個不同的單一增量更改。

這使得更容易跟蹤更改並理解代碼發生了什麼，特別是當您發現上個月11日某處出現了一個不起眼的錯誤時。試圖在300個文件重構檢查中找到一個單行更改，真的很糟糕。

Answer 4

我同意以前的回覆。如有疑問，請將您的更改分成多個提交。如果您不想讓變化歷史記錄混亂很多（並且您的修訂版本顯示爲一個原子更改），請在可以將它們分開的輔助分支中執行這些更改。如果每個變化都清楚易懂，那麼稍後閱讀差異變得容易很多（並且可以放心，沒有什麼是無意中損壞的）。

不要在修改格式的同時更改功能。如果您更改條件的含義以便可以縮進大量代碼，請在一次更改中更改邏輯並在後續更改中執行超時。 明確表示您的提交信息。

Answer 5

如果源代碼控制系統允許它.. （這並不在我目前的工作，由於源代碼控制系統不順心單個用戶檢查出一個單一的文件，以多個地點工作。）

• 我有兩個工作文件夾
• 兩個文件夾都來自同一分支結賬
• 我用一個文件夾來實現新功能的開發/ bug修復改變
• 在我做的重構其他文件夾，
• 每次重構後，我在重構文件夾檢查
• 然後更新，在我的重構合併的新功能開發文件夾

因此，每個重構是在自己的簽入和其他開發人員快速得到重構，所以有更少的合併問題。