您能否就軟件團隊在版本控制環境中分支時可能遇到的問題建議一篇文章，一本書或一份會議文章？我們正在爲我們的贊助商之一創建摘要，並需要引用可敬的信息來源。到目前爲止，我通過Chris Birmele和Eric Sink發現了簡短的評論。在版本控制中我們可能會遇到分支問題？
在此先感謝！
PS。 Appleton等人的文章Branching Patterns for Parallel Software Development。看起來很基本，但相當古老。
如在Martin Fowler's Bliki中所提及的，FeatureBranch可以通過語義衝突來解決它們的問題。
我更擔心的問題是語義衝突。
的一個簡單的例子是，如果李教授改變了牧師格林代碼調用的方法的名稱。
重構工具允許您安全地重命名一個方法，但僅限於您的代碼庫。因此，如果G1-6包含稱爲foo的新代碼，Plum教授不能在他的代碼庫中告訴他沒有它。你只能在大合併中找到答案。函數重命名是語義衝突的一個相對明顯的例子。實際上他們可以更加微妙。測試是發現它們的關鍵，但合併的代碼越多，發生衝突的可能性就越大，修復它們的難度也越大。
它的衝突，尤其是語義上的衝突，使大融合可怕的風險。
查看this SO question中的語義衝突示例。
一旦被考慮進去，你也需要區分CVCS and DVCS（集中式和分佈式VCS），作爲DVCS將帶來垂直維度分支：「publication」（推/拉/遠程這意味着您可以在「同一個」分支上工作，同時仍然完全隔離，因爲您正在處理本地克隆存儲庫）。
CVCS像SVN有他們own issues與merging branches，這DVCS應該是很擅長。
看Hg Init - 它詳細解釋了爲什麼分支是在某些情況下，如何緩解這個問題很成問題。關鍵在於分支不是問題，但在不同分支上合併更改可能會消耗大量時間。
我很抱歉，我無法找到實際的語句引用，但我記得Larry McVoy說一起的「你永遠不希望分支乘以行的東西，你總是要合併再次分支回去「。你的分支機構的優秀程度越高，其中一方的變化就越可能與另一方的變化相沖突。特色分支是你的朋友，但我建議經常拉動變化以適應「幹線」或「上游」道德等值的變化，並且一定要儘快將分支合併回「幹線」或「上游」他們的需求得到滿足。
也許更簡潔地說，我一直認爲有必要之前定義的一個分支的壽命創建它。知道你爲什麼創建一個分支，它會存活多久，何時決定合併或丟棄它。