說到版本控制，大多數人的大腦中都一定會立刻想到 git 和 svn 吧，只可惜，這次的主角可不是他們

雖說 git 和 svn 雖好，對于一些項目也能夠進行很好的開發，但是呢，對于某些場景，還是有些 hold 不住的

比如，我們來舉一個場景：

現在我們的源碼大約有 500M，然后呢，采用的是分支開發，主干發布，但是呢，因為我們是提供中間層 service 的，迭代周期很短，對于一些特殊的客戶，會時常有些特殊的邏輯處理，每個開發者可能會有好幾個分支進行開發，這個樣子的話，對于這些特殊邏輯，特殊版本的管理就非常的不方便，而且，因為每次都要拉出來一個分支，然后改動可能非常小，這就造成了非常大量的冗余量

于是，這個場景中，冗余量、大量迭代版本的管理，就上升到了我們的一個主要問題

如何解決呢？

單體代碼庫

在這里，我們引入一個節點（標簽）的概念，先來說一下整體思路

現在，我們就拋棄 git 和 svn 的思想，把所有的代碼都放在一起，通過控制 節點粒度 來控制整體的冗余

首先，節點粒度我們先設定為以文件為單位，同時呢，約定我們的命名規范，文件名.節點標識.php，例如 Test.v1.php

接下來呢，就會有我們原始的版本，在這個原始的版本里面，所有的文件都是 base 節點

所有的文件都會有一個父節點，最終都是繼承與 base 節點的

當我們需要迭代到 1.0.1 版本的時候，我們只要把需要改動的文件 copy 一個副本，然后按規范命名，接著只需對于這一個文件進行改動，這樣，冗余的粒度就控制在了這個文件內

大大減少冗余的同時，還大大的提高了代碼的復用，避免了菱形依賴，不同團隊間的跨團隊協作也變得更加靈活

接下來，我們怎么能夠正常調用呢？

所以說，這種單體代碼庫需要一個路由引擎來驅動，這就要我們根據實際情況來實現了，可以直接根據節點表示來路由，也可以在中間加一層路由映射表，這就看具體需求了

同理，我們可以進一步調整節點粒度，來控制整體的冗余，比如，粒度細化到接口級別

好了，下面就來分析一下這種單體代碼庫的優劣

**優點：**

> * 統一版本控制

> * 廣泛地代碼共享和復用

> * 簡化依賴管理，避免菱形依賴

> * 原子修改

> * 大規模重構

> * 跨團隊協作

> * 靈活的團隊邊界和代碼所有權

> * 代碼可見性以及清晰的樹形結構提供了隱含的團隊命名空間


但是呢，隨著代碼量的增加，也會出現以下**問題**：

> * 單體模型讓代碼結構更容易理解，但卻讓代碼發現變得更困難

> * 開發人員需要能夠查看代碼庫，找到相關程序庫，并看看如何使用它們以及誰編寫了它們。這就需要有代碼搜索和代碼瀏覽工具

> * 依賴重構和代碼清理輔助工具，定期對無用代碼進行清理

> * 版本管理的重心轉移到了冗余控制上


所以說呢，對于管理，我們就需要開發一套額外的自動化工具了，比如說：

> * 代碼庫搜索工具：因為我們采用了單體代碼庫，所以慢慢的代碼越來越多，代碼搜索工具就變的必不可少了

> * 代碼發現工具：也是為了維護代碼庫，定期發現清理無用代碼

可能根據大家的實際情況，也需要一些其他的自動化工具

---