版本控制約定和最佳實踐

Question

我目前在我的項目中使用SVN（盡管我很快會嘗試使用git），並且我了解大多數基本知識（提交，更新，分支，合並等），盡管我仍然對如何正確使用它不了解。 順便說一下，我的項目目前僅涉及我自己。

這是一個示例場景：我們有SVN服務器，實時Web服務器，開發/測試Web服務器和我的工作站。 我創建了一個包含多個新文件的新功能，並通過消息“創建新功能X”來提交它，一旦在開發服務器上簽出，我就經歷了看到錯誤，修復錯誤，提交，簽出，重復執行直到所有的錯誤都消失了。 其中一些錯誤修復程序可能是簡單的錯字。

因此，我有點困惑，因為主要功能提交似乎與微小的錯字修復提交“相提並論”（如果這很有意義），當我看到版本列表時，我可能只想查看主要更改而不是次要修復。 同樣，“有意義的提交消息”的鍵入時間可能要比實際錯誤修復時間長10倍，所以我不只是將其留空或鍵入“ er”。 這似乎不太正確。 那我想念什么呢？ 還是我只是懶惰？

Answer 1

在所有版本控制系統中，提交/修訂都是相等的，並且不會根據更改的大小為其分配重要性。 這是分支和標記出現的地方。 從分支上的上一個標記/標記一個“功能上完整的”提交集合，然后在測試/ Web服務器中對其進行標記。 （此外，我可以建議自動測試和持續集成。）

有意義的提交消息是版本控制的重要組成部分。 無論您所做的更改有多小，都請嘗試使消息有意義。 在許多開發團隊中，提交消息被固定為固定格式，並具有一些必要的信息，例如錯誤跟蹤號等。即使對於只有一個人的小型項目，現在提供適當的消息總是很好的。 在以后的Git中，您可以根據需要輕松編輯提交消息，然后再推送到中央存儲庫。 這樣，您可以在提交時提供較小的消息（請注意，我並不是說小消息不一定有意義），然后花一些時間“微調”您的歷史記錄。

Answer 2

關於最佳實踐的一本令人驚訝的好書是《 實踐Perforce》 。 這是一本有關專有版本控制系統Perforce的書，但該書繼續說明了使用Perforce的最佳方法，最終這是使用幾乎所有版本控制系統的最佳方法。

我從本書中學到了很多最佳實踐，並將其應用於其他版本控制系統，並且即使其他人從未計划使用Perforce，我也向其他人推薦了它，因為它具有一些出色的功能。最佳做法的想法。 這些包括：

• 不要使用基於環境的分支（即特殊的UAT分支，因為開發中的內容最終將最終以UAT形式出現）。
• 需要時分支，而不是之前。 這主要意味着，當發布的代碼完成時，您將分支到該發布，並且該發布中沒有的新內容將被放入代碼中。
• 釋放分支而不是樹干。 這將允許您在仍在下一版本上工作的同時進行修補程序。
• 不要嘗試挑選修復程序。 它永遠不會按預期工作。 總會有一個代碼更改取決於另一個代碼更改，而另一個代碼更改取決於您不想發布的另一個代碼更改。
• 使用可以進行自動測試並基於每個更改的持續集成系統。

我知道讀一本關於一個版本控制系統的書似乎很奇怪，但是您想要使用另一個版本控制系統，但是大多數版本控制書都是關於軟件的細節，而不是有關使用該軟件的最佳實踐。 這是涵蓋這兩個方面的幾本書籍之一，並且很多書也可以應用於其他版本控制系統。