如何使用SVN管理源代碼？分支，合併

我們是位於不同地點的4位開發人員/好友的團隊。我們都已經開始使用ProjectX並使用Subversion創建分支A，B，C和D.如何使用SVN管理源代碼？分支，合併

我們只掌握控制源代碼版本的基本知識。另一天，我們中的一個人試圖將分支A與B，C和D合併，並且B試圖合併A，C和D.（他們甚至不知道如何合併它：D，只需右鍵單擊>合併>合併一系列修改）我們得到了一些衝突，解決了它們。再次嘗試合併，再次右鍵單擊.....）再次衝突。現在

所有的代碼已經搞砸了。我們有4個不同的代碼副本（D缺少B的功能，但有C的等等）。所以我在這裏經歷了很多線索，閱讀了SVN書籍，尤其是this article (how to branch properly)幫助我們理解了如何合併分支機構和主幹。我想我對未來有了更好的瞭解。但是，我如何擺脫現狀呢？

我的問題是：

正如我們4個人正在對同一項目，但通常在不同的位工作，我們應該有一個分支？然後創建4個工作副本，然後僅提交和更新。一旦我們準備好將主幹合併到分支，分支到主幹？按照建議在above article
能否請您提出任何工作流程，使我們可以得到我們的4個分支到主幹，然後我可以採取出口再次啓動版本從頭控制。
我也想，如果有4個分公司又來了，應該每天我們每個人/定期更新我們的分公司，並從行李箱（合併）的變化和本地更改合併回主幹？（而不是嘗試Mergin分支到分支：-D）

請建議我們應該使用什麼工作流程？所以它在維護代碼方面的最小痛苦。謝謝。

來源

2009-09-29 TigerTiger

我不會創建每個開發人員的一個分支。我推薦一個continuous integration流程，其中你們所有四個人都從一個「中繼線」中檢出並經常合併更改 - 每天多次。理想情況下，您將擁有標準化的構建工具（例如Maven，Ant等）和構建計劃程序（例如Hudson，Cruise，TeamCity等）。將這兩個工具放在SCM工具之上（Subversion），您可以通過一個流程不斷將您檢查到的所有更改建立到主幹中，並在發生問題時通過電子郵件向所有開發人員發送電子郵件。這樣可以保護您不會因錯誤更改或合併而破壞構建，同時允許您保持輕量級分支結構（即一個分支 - 主幹）。

分行使其更難以與你的隊友你的代碼更改整合。分支機構應該真正用於分支 - 創建專門管理軟件的「分支機構」。例如，如果您要發佈1.0版本的軟件，那麼從主幹創建1.0分支（開發之後但發佈之前）可能是一個好主意，因此您可以在不影響正在進行的情況下維護此版本在主幹上開發（可能爲2.0版）。

我建議抓住Pragmatic Version Control with Subversion。這是一個非常可靠的供應鏈管理概述，包含Subversion的具體細節。

來源

2009-09-29 15:18:23 SingleShot

感謝您的想法。我一定會看看你提到的所有工具。 – TigerTiger 2009-09-29 15:30:15

您應該使用一個分支主發展。這實際上不是一個分支，被稱爲「中繼線」。每個開發者都應該改變主幹。當您發佈代碼或對程序進行重大更改時，您可能需要創建分支。然後，如果您對分支進行了一些更改（比如說前一版本的補丁），並且也希望在主幹線上進行這些更改，則應該將分支合併回幹線。
除了查看更改並手動合併到一個代碼樹之外，我不知道任何更好的方法。
你不應該在你的情況下與4個分支。這不是使用版本控制系統的正確方法。

來源

2009-09-29 15:14:35 grigy

1：當我們認爲我們完成後，這意味着主幹> 1分支（我們所有人都在工作）..將這個分支合併回主幹。而且，如果需要應用補丁，然後創建一個新的分支，並在新的分支上工作，不要觸摸舊的？關於3，是的，我可以看到這個想法有多「不正確」。感謝您的回答。 – TigerTiger 2009-09-29 15:29:03

我同意你說的大部分內容，除了最後一個。沒有理由不使用分支機構，如果他們將提交可能破壞主體構建的代碼。在全部測試完成後，它可以合併到主幹。通過這種方式，所有更改都將受版本控制，但不會中斷主幹。 – 2009-09-29 15:29:36

亞當，我們正在使用另一個工具來達到這個目的。它只是標記了所有可以包含在構建中的版本。 – grigy 2009-09-29 18:44:03

一般來說，如果你們都在處理不同的軟件，你會發現最簡單的工作就是在同一個分支上工作。如果您通常不在相同的源文件或相互依賴的部分軟件上工作，則當您提交時更新工作副本或損壞的源代碼樹時，您不會發現經常遇到衝突。

SVN中的分支（與分佈式版本控制系統相對）更適合大規模，大規模的變更，這些變更可能會破壞同事的代碼或需要大量工作（在這種情況下，您希望使許多可能無法編譯的增量提交）或諸如管理版本之類的東西。

去一個單一的分支（主幹，在其他的答案中指出）。當多個人必須使用相同的代碼時，那麼第二個簽入者將手動修復衝突。在一個固定版本衝突比試圖改變幾經修改合併到，因爲它們拆分還擁有先進的多次修改的另一分支更容易多。

來源

2009-09-29 15:17:16

通常情況下，隨着工作的代碼只有4個球員，你不需要4個分公司。你可能根本不需要分支，只需將它全部放入一個樹幹並在其上工作即可。把你簽出的本地工作副本想象成你的「匿名本地分支」。如果你預計你的代碼至少兩個版本存在一定的時間

分行是有用的。例如，當您發佈2.0版本，並且您想開始2.1版本的開發時，但必須支持2.0才能實現可預見的未來。你可以開始2.1作爲一個整體的新項目，但是你會失去將修補程序從2.0移植到2.1的能力，反之亦然。所以你命名一個版本樹幹並從樹枝中分支出來。

另一種情況是，當你們中的一個開始實現一個新模塊或重新實現一個現有模塊，並知道它需要一段時間（比通常的提交週期長）並且不能保證它不會影響其他模塊人們在那段時間的代碼。然後你讓他分支，發展他的東西，然後你找出如何合併回來。這裏又一次，你有一個樹幹，你分支併合並回來。

來源

2009-09-29 15:17:20 wallenborn

爲了避免分支甚至更大的工作，你通常可以隱藏在啓用它的標誌背後的新東西。這僅在開發人員使用新功能的工作區中設置爲true，所有其他人在默認情況下都禁用（但可以輕鬆地將其打開以進行臨時測試）。 – starblue 2009-09-29 15:31:31

@starblue - flag？你的意思是在腳本中的東西？ – TigerTiger 2009-09-29 15:36:23

如果您僅限於SVN，請繼續閱讀，如果沒有，您聽起來像是Mercurial，Git或Bazaar等DVCS的主要候選人。

爲SVN，從我以往的經驗，一般最好把這裏的一切都合併到（見的例子here）樹幹。每個人都應該合併回幹線，然後從幹線合併到分支。從分支合併到SVN分支似乎是一個壞主意。

來源

2009-09-29 15:17:58

老實說，如果我們轉向Git，它確實出現在我的腦海裏。 – TigerTiger 2009-09-29 15:23:20

另一個藉口發佈到Eric Sink的鏈接source control howto。

對於我所找到的源代碼管理來說，這是最好的介紹，並且與您使用的工具無關。

來源

2009-09-29 16:14:47

最安全的策略是爲每個CR（更改請求/任務/ Bug /等）創建一個分支。流會是這樣：

甲CR通過CMT給予顯影劑（變更管理工具，如Bugzilla的）;
分析CR。如果它使得它被接受並且開發者爲它創建一個分支。分支名稱可能是這樣的：

projectName_crNumber_crCreationDate_developerId
工作完成後（經測試，COMMITED等），開發商應該鎖定分支，所以沒有人會改變，標誌着CR爲已解決（通知CR的分支名稱），並等待CM（配置管理器）將其合併到構建分支（以及其他開發分支）;
將一定數量的CR合併到構建分支（build_xxx）後，應測試此集成版本。如果一切正常，它應該被合併到卡車上。
每次幹線達到特定目標/里程碑（CR組）時都可以應用標籤。

很多細節已被省略。這是一個高質量標準的大團隊採用的工作流程。它可能對於小團體來說不夠靈活。但是，大多數這些任務可以通過現有工具自動化和安排。

來源

2011-06-02 14:14:42

如何使用SVN管理源代碼？分支，合併

回答

相關問題