版本控制：多版本地獄，文件同步

Question

我想知道你通常如何處理這種情況：

我有一組實用功能。 說..5..10文件。 從技術上講，它們是靜態庫，跨平台 - SConscript / SConstruct加上Visual Studio項目（不是解決方案）。

這些效用函數用於多個小項目（15+，數量隨時間增加）。 每個項目都有一些文件或整個庫的副本，而不是指向一個中心位置的鏈接。 有時項目使用一個文件，兩個文件，有些使用一切。 通常，實用程序函數包含在每個文件和SConscript / SConstruct或Visual Studio Project的副本中（具體取決於具體情況）。 每個項目都有一個單獨的git存儲庫。 有時一個項目來自其他項目，有時則不是。 你以隨機順序處理它們中的每一個。 沒有其他人（為了簡化事情）

當您在一個項目上工作時修改這些實用程序功能文件時會出現問題。
因為每個項目都有一個文件的副本，所以這會引入新版本，當你稍后（例如一周后）嘗試猜測哪個版本具有最完整的功能時（即你在a.cpp中添加了一個函數）會導致混亂。一個項目，並在另一個項目的a.cpp中添加了另一個函數，創建了一個版本fork）

你會如何處理這種情況以避免“版本地獄”？ 我能想到的一種方法是使用符號鏈接/硬鏈接，但它並不完美 - 如果你刪除一個中央存儲，它將全部下地獄。 並且硬鏈接不適用於雙啟動系統（盡管符號鏈接會）。 看起來我需要的是像高級git存儲庫，其中項目的代碼存儲在一個本地存儲庫中，但與多個外部存儲庫同步。 但我不知道該怎么做或者是否可以用git做到這一點。

所以你怎么看？

Answer 1

通常的簡單方法是將庫作為版本控制中的項目，如果有修改，則僅編輯此項目。

然后，需要庫的其他項目可以從庫項目中獲取所需的文件。

Answer 2

我不清楚你想要什么，但也許git子模塊可能會有所幫助： http ： //git-scm.com/docs/git-submodule

Answer 3

在Subversion中你可以使用外部（我知道它不是GIT，但這些提示可能仍然有用）。 這是它的工作原理：

• 從公共代碼（\\ COMMON）拆分應用程序特定代碼（\\ MYAPP）
• 從應用程序中刪除所有重復項; 他們應該只使用通用代碼
• 通過在\\ MYAPP中添加\\ COMMON作為外部來引入應用程序中的公共代碼

您可能還有應用程序的版本。 還介紹了通用代碼中的版本。 因此，您的應用程序將在存儲庫中包含以下文件夾：

• \\ MYAPP \\ TRUNK
• \\ MYAPP \\ V1
• \\ MYAPP \\ V2

同樣，使用版本號向公共代碼添加版本，如下所示：

• \\ COMMON \\ TRUNK
• \\ COMMON \\ V1
• \\ COMMON \\ V2

或使用日期，如下所示：

• \\ COMMON \\ TRUNK
• \\ COMMON \\ 2010JAN01
• \\ COMMON \\ 2010MAR28

\\ MYAPP \\ TRUNK的外部應指向\\ COMMON \\ TRUNK，這是顯而易見的。

嘗試將公共代碼的版本與應用程序的版本同步，因此每次修復應用程序版本時，公共代碼也會被修復，應用程序版本將指向相關的公共代碼外部代碼。

例如，\\ MYAPP \\ V1的外部可能指向\\ COMMON \\ 2010JAN01。

這種方法的優點是每個開發人員現在都可以擴展，改進和調試公共代碼。 缺點是應用程序的編譯時間會隨着通用代碼的增加而增加。

替代方案（在您的版本系統中放置庫）的缺點是，公共代碼的管理（擴展，改進，調試）總是與應用程序的管理分開完成，這可能會阻止開發人員編寫通用的公共代碼（每個人都開始編寫自己的“通用”類版本。 另一方面，如果您有一個清晰而靈活的團隊，對公共代碼負全部責任，那么在最后一個替代方案中，公共代碼將受到更好的控制。

Answer 4

在配置（一般）術語中，解決方案是具有多個中繼（分支）：

• 發布
• 積分
• 發展

發布
此主干/分支包含已通過質量保證並可以發布給客戶的軟件。 發布后，所有文件都標記為“只讀”。 給出標簽以標識具有版本號的文件。

測試大師將定期或按需按順序從集成主干獲取最新（tip）版本並提交到嚴格的質量測試。 這是集成版本升級到發布版本的方式。

積分
該中繼包含最新的工作代碼。 它包含錯誤修復和新功能。 每個錯誤修復或新功能后都應標記文件。

在錯誤通過質量測試或新功能完全開發（並經過測試）后，代碼將移至集成分支。 這里的一個好主意是在集成開發人員代碼之前用集成版本標記臨時標簽。

開發這些是開發人員為修復錯誤或開發新功能而制作的分支。 這可以是移動到本地計算機上的所有文件的副本，也可以是需要修改的文件的副本（包含所有其他文件的Integration干線的鏈接）。

在中繼線之間移動時，代碼必須通過資格測試，並且必須有權移動到中繼線。 例如，未經授權，不應將未經授權的新功能放入集成分支。

---

在您的情況下，文件需要在修改后重新檢入Integration trunk，或者如果代碼與以前的版本太不相同（例如添加新功能），則需要檢查整個新分支或主干。

我一直在研究GIT和SourceSafe試圖弄清楚如何實現這個模式。 該模式易於在較大的配置管理應用程序（如PVCS和ClearCase）中實現。 對於GIT來說，重復的存儲庫是必要的（每個主干一個存儲庫）。 SourceSafe明確指出每個版本只允許一個標簽，因此未更改的文件將丟失標簽信息。