（注：這個問題是不特定的顛覆 - 我只是用它做爲一個例子）源控制最佳實踐 - 定期從倉庫更新你的工作拷貝
我知道「SVN更新「命令（或其他系統中的類似命令）將更新您的工作副本，並對存儲庫中的文件進行任何更改。我也知道，在源代碼管理中，最好的做法是定期進行svn更新，以確保在最終提交（簽入）這些更改之前獲得最新的一組更改。
這個最佳實踐的另一種方法（也許這將是一個最壞的做法：>）將是在提交（簽入）時間管理潛在衝突只有，而不是定期在您編輯文件。
似乎最好的做法是採取一種「悲觀」的方式來儘早且經常地處理衝突，而不是僅在提交時管理衝突並在稍後管理所有積累的衝突的「樂觀」方法。
難道我陳述的最佳實踐與正確替代的意圖是什麼？
就我個人而言，我開始工作時每天更新我的工作副本。我發現衝突很快找到並且很快就能解決。
是的，很悲觀。此前，更小，更全面的變化更容易
這當然取決於有多少其他開發人員使用相同的代碼，以及他們與您正在使用的模塊一起工作的可能性。 （我目前唯一的一個我的工作我的項目，例如，我不幾乎一樣頻繁刷新當別人都在那裏了。）
聽起來是正確的。當然，如果你經常犯下這種情況，而不是等到你有很多變化，那麼這兩種方法是相同的。
權，隨着分佈式版本控制方法的興起，出現了一種傾向，以「熄燈」的有些人會說，走下車和你自己的東西的工作，並擔心以後合併它的越來越多。
很多人，包括我自己，會說，這將導致更多的衝突，這都比較難解決，因爲你基本上是在一個不同的分支操作，因此在不同的方向發展。
定期更新可以確保你不會去遙遠的其他人的路徑，但很多人覺得這破壞了分佈式版本控制的靈活性。
有一箇中間地帶的東西 - 你可以保持在一個分支的更改，從正在進行中的主幹變化分開。這在git中是非常容易的，在顛覆中不那麼容易（我會說）。這可以讓你做的就是定期從中繼線獲取更改，而不會自動「冒着」本地更改與中繼提交衝突混淆。我認爲，這是你爲什麼不會想要更新的核心 - 也就是說，因爲你還沒有爲他們做好準備。你會看到發生了變化，但這是一件很好的事情。在獨立分支上進行更改意味着您可以嘗試合併上游更改，但如果它們不匹配，則可以中止合併並繼續在代碼上工作一段時間，直到您準備好真正花費精力解決衝突。
它是肯定是這樣的，早些時候你重新調整你的代碼與主幹兼容（通過svn更新或合併更改），解決衝突就越容易。等到您準備好提交更改以發現所有內容都已經從您的下面移開 - 您將花費更多時間來查看日誌，試圖弄清楚更改的內容以及如何正確應用他們對你已經認爲是好的代碼，並且，那麼你需要重新測試你的代碼與新的變化！如果你一直在合併，那麼你已經測試了這個版本。
<<這是什麼讓你做的是定期從中繼拉變化沒有自動「冒」你的本地變化被幹擾與幹線衝突提交。我認爲，這是你爲什麼不想要更新的核心 - 也就是說，因爲你還沒有爲他們做好準備。 >>您提出了一個有趣的觀點，我也在考慮 - 在完成特定「單位」的工作之前，拉動其他人的變更絕對是一個缺點。儘管平衡看來，這種下降似乎超過了與更新和合並有關的好處。 – Emilio 2010-02-12 20:31:13
我認爲這一切都取決於代碼中的依賴關係的數量以及同時處理相同代碼的開發人員數量。如果你有很少的開發人員使用相同的代碼，那麼你可以花更長的時間，而不需要與存儲庫中的代碼「合併」。我個人喜歡等到我的發展結束，只要不需要幾周時間就可以完成。如果需要數週時間才能完成，則應將功能拆分爲更小的部分，並使用更多的增量方法，以便您檢入新代碼並更頻繁地合併。
另一種方法是在你自己的分支工作，而不是幹線。這樣，唯一的合併是在您的功能/錯誤修復/完成時完成的。沒有其他人會在你的分支上作出承諾，所以你是安全的，直到你完成。每次在電腦前每前
=>多年的無故障使用單片機的。
根據需要隨時更新。至少每天早上。而且，每次你的隊友告訴你。每當你知道某人在你工作的地區犯了什麼事情時，
提交之前。從來沒有曾經提交的東西，直到你已經更新到最新的版本庫，並儘可能確保你的提交不會破壞任何東西。
就像多次提到上述，我的建議是相似的：
第二點是非常im同樣也是一樣：只要「某事」在起作用，它就必須承諾，文獻說「不要盲目」即，不要在你的硬盤上繼續開發一個月，直到它完美爲止（它永遠不會是:-)）
這是Continuous Integration背後的基本思想（Martin Fowler的網站上有很多材料和非常明確的解釋） 。
太最後幾點：
在我以前的工作中，產品部門的一些人會拒絕每天更新（甚至每天幾次），因爲他們在說：「行李箱壞了，如果我更新，我會放鬆我的一天」。他們是對的！這是不可接受的！ 這就是爲什麼強調只有工作代碼應該被提交（或推送給DVCS人員）非常重要：爲了幫助強制執行此操作，我設置了每日構建，這將在每次提交時開始（使用免費軟件buildbot工具但存在數十種類似的工具）。通過按需提交的構建和測試，可以更容易地確定主幹沒有損壞;無論何時構建或（簡單）測試失敗，剛剛提交的人員都會收到一封電子郵件，他們必須立即解決問題或恢復。網站摘要（在buildbot詞彙中稱爲瀑布）在這裏供大家看到。總而言之，在開發人員之間建立並相互信任確實是一種心態，但是一旦你到了這一點，相信我，你永遠不會想回來：發展速度更快，但協調性更強，人們很樂意貢獻相同的代碼，而不是單獨在他們的工作站上工作一個月！值得嘗試走這條路（恕我直言）。
同意，只要你不與世界另一端的人一起工作，他們偶爾會犯下非編譯代碼，並需要「明天」修復;）不是從個人經驗或任何其他方面發言...... – Fry 2010-02-12 20:17:49
每次資料庫被「破」成迷你醜聞。 （當然，容忍一次性錯誤）。這些開發人員遲早會學習。 – Bozho 2010-02-12 20:45:20
也是那裏（但後來，這就是更新更新是什麼;-) – 2010-02-12 21:07:18