更改源格式時提交嗎？

Question

即使您只是在改變諸如空白，代碼格式等內容時，是否接受實踐？

Answer 1

是的。如果您需要執行空白更改，則在僅包含此類清理的單獨提交中執行這些更改是最佳做法。這可以避免嘗試查看實際代碼更改的巨大差異的哪些部分存在問題，以及哪些部分只是格式化（整體）更改。

這就是說，你應該嘗試這些樣的變化保持在最低限度，只有做到這一點在所有的時候是必要的，兼容任何編碼標準在貴公司/社區/項目中使用/等

Answer 2

是的，只要所涉及的各個存儲庫之間存在某種一致性，否則會由於格式化而產生衝突，使得任何合併更加困難。
至少有一個單獨的提交有助於識別未來合併期間潛在衝突的真實來源。

如果它不是「你的」代碼（即其他一些其他格式化標準的回購將不得不合並你所做的），你可以利用git attribute filter driver及其塗抹/清除機制。

^{（來源：Pro Git book：Customizing Git - Git Attributes）}

在塗抹步驟中，您可以申請您格式的代碼，並在清洗步驟重新申請的通用格式標準。

Answer 3

是的！是!作爲一個單獨的提交，請！ （這些類型的編輯往往會觸及很多代碼，並且人們需要知道提交/更改集/修補程序/是否純粹出於重新格式化的原因，而沒有針對實際代碼進行更改）。

Answer 4

G '天，

是的。但請不要作爲一個專門用一條消息，說明你已經

• 更改後的格式提交，
• 通過代碼格式化，例如運行代碼Perltidy，有關實際使用的設置的說明，
• 等

什麼比格式更改與功能更新，這樣做跨版本差異提供了一個可憐的S/N比合並更糟糕！

順便說一下，我想知道爲什麼要對現有代碼的格式進行更改。它不應該被檢入，如果它格式不好，首先！

沒有什麼比別人誰經歷改變格式良好的來源沒有其它的原因，而不是工作更糟：

他們認爲
• 括號屬於對「如果」語句的行，或
• 他們不喜歡 「擁抱別人的」，或
• 等
• 等

這樣的宗教表述「一個真正的風格「通常認爲缺乏在團隊中工作的編碼經驗和經驗。

HTH

歡呼聲，

Answer 5

的答案已經在這裏做解釋爲什麼它可以提交格式更改問題的一個好工作。我認爲一種解決方案是編輯器支持，以允許用戶在保存文件時查看格式良好的代碼，同時最小化格式更改。

我問過一個相關的問題關於這...

• Is there a text editor that will "pretty print" for display without changing the underlying text?

如果有好的答案來了那裏，這個問題的觀衆可能也有興趣。