源代碼控制策略

Question

我正在尋找有關不同源代碼控制策略的概述。我只是遇到了主線政策，並希望在與團隊合作之前更好地瞭解其他人。

有人可以提供一個概述鏈接，甚至給我一些政策的名稱，所以我可以啓動谷歌呢？

Answer 1

論文"streamed lines: branching patterns for parallel software development"是關於分支模式的極好的討論，例如您提到的「主線」模式 - 它以模式形式列出選項以及討論反模式。其中一位作者是Perforce的Robert Orenstein。

Answer 2

我最喜歡的政策是「沒有顛覆承諾不引用門票+自動Trac的評論對每一個提交」：http://trac.edgewall.org/browser/trunk/contrib/trac-post-commit-hook

Answer 3

我已經取得了巨大的使用書Practical Perforce的。雖然你可能沒有使用Perforce，但我認爲第7章（軟件的演變）和第8章（基本代碼管理）可能非常有用。你可以在Google Books上瀏覽它們。

Perforce在這個問題上也有很多很棒的文章。 Software Life-Cycle Modeling寫道政策。
Perforce complete technical documentation。

而且，不，我沒有爲Perforce工作。

祝你好運， 托馬斯

Answer 4

沒有空提交信息。

Answer 5

提交每更改而不是每個文件。

這具有以下優點：

• 以後，您可以看到爲什麼這一行已在此確切的文件被更改（啊哈，這是對錯誤＃123 Bug修復）。如果您提交每個文件，則提交消息往往會描述文件中所做的更改 - 無論如何，您都可以通過diff查看。如果您提交per-change，那麼提交消息往往可以解釋爲什麼首先完成更改。
• 恢復或合併更改/錯誤修復要容易得多。
• 當你清楚地關注你正在工作的單個bug /特性/改變時，它有助於更​​好地組織你的工作。你完成後就提交。

有些人認爲這個政策會產生更多的承諾，但從我的經驗來看，您最終獲得的承諾更少。例如，您正在進行影響50個文件的重構。重構後，您只需提交一條消息「重構xyz子系統」。

對於較大的變更，您應該考慮dev-branch-per-change政策。

Answer 6

請勿簽入/提交任何破壞構建的更改。

Answer 7

我們在項目中使用了幾條實用規則作爲提交策略。這些規則有助於我們將每個修訂保持在可以部署的狀態。我們的規則類似於KDE提交策略，發佈在這裏：http://techbase.kde.org/Policies/SVN_Commit_Policy。 每個提交應該是（從較高到較低優先級）：

• 成功檢查（編譯，測試，審查，FxCop'ed等）
• 原子（應該只包含一個邏輯變化，FE單一錯誤修正，重構等）
• 非冗餘的（未使用的代碼應該加入，不要犯註釋代碼，將其刪除，不小心犯格式的變化等）
• 正確和全面評價
• 匹配的電流開發階段（例如，不應該重構b e允許在版本支持分支中）
• 儘可能小以匹配先前的規則。

我們開發了一個簡單的工具SvnCommitChecker，幫助我們在提交到svn之前檢查這些規則。我計劃在不久的將來將其發佈到sourceforge上，並提供一篇關於保持良好svn變化歷史的好處的文章。

Answer 8

這兩個基本相同：
Version Control for Multiple Agile Teams
Configuration Management Branching Strategy

我們正在使用這種策略，使軀幹穩定，使開發人員能夠做什麼，他們需要自己的分支機構。

有一些問題，因爲顛覆它不能處理Cyclic merges，但它可以通過刪除開發分支每個重返社會後回主幹工作圍繞（無關其他版本控制系統）