摘要：說到版本控制，大多數(shù)人的大腦中都一定會立刻想到和吧，只可惜，這次的主角可不是他們雖說和雖好，對于一些項(xiàng)目也能夠進(jìn)行很好的開發(fā)，但是呢，對于某些場景，還是有些不住的比如，我們來舉一個(gè)場景現(xiàn)在我們的源碼大約有，然后呢，采用的是分支開發(fā)，主干發(fā)布

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

雖說 git 和 svn 雖好，對于一些項(xiàng)目也能夠進(jìn)行很好的開發(fā)，但是呢，對于某些場景，還是有些 hold 不住的

比如，我們來舉一個(gè)場景：

現(xiàn)在我們的源碼大約有 500M，然后呢，采用的是分支開發(fā)，主干發(fā)布，但是呢，因?yàn)槲覀兪翘峁┲虚g層 service 的，迭代周期很短，對于一些特殊的客戶，會時(shí)常有些特殊的邏輯處理，每個(gè)開發(fā)者可能會有好幾個(gè)分支進(jìn)行開發(fā)，這個(gè)樣子的話，對于這些特殊邏輯，特殊版本的管理就非常的不方便，而且，因?yàn)槊看味家鰜硪粋€(gè)分支，然后改動可能非常小，這就造成了非常大量的冗余量

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

如何解決呢？

在這里，我們引入一個(gè)節(jié)點(diǎn)（標(biāo)簽）的概念，先來說一下整體思路

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

首先，節(jié)點(diǎn)粒度我們先設(shè)定為以文件為單位，同時(shí)呢，約定我們的命名規(guī)范，文件名.節(jié)點(diǎn)標(biāo)識.php，例如 Test.v1.php

接下來呢，就會有我們原始的版本，在這個(gè)原始的版本里面，所有的文件都是 base 節(jié)點(diǎn)

所有的文件都會有一個(gè)父節(jié)點(diǎn)，最終都是繼承與 base 節(jié)點(diǎn)的

當(dāng)我們需要迭代到 1.0.1 版本的時(shí)候，我們只要把需要改動的文件 copy 一個(gè)副本，然后按規(guī)范命名，接著只需對于這一個(gè)文件進(jìn)行改動，這樣，冗余的粒度就控制在了這個(gè)文件內(nèi)

大大減少冗余的同時(shí)，還大大的提高了代碼的復(fù)用，避免了菱形依賴，不同團(tuán)隊(duì)間的跨團(tuán)隊(duì)協(xié)作也變得更加靈活

接下來，我們怎么能夠正常調(diào)用呢？

所以說，這種單體代碼庫需要一個(gè)路由引擎來驅(qū)動，這就要我們根據(jù)實(shí)際情況來實(shí)現(xiàn)了，可以直接根據(jù)節(jié)點(diǎn)表示來路由，也可以在中間加一層路由映射表，這就看具體需求了

同理，我們可以進(jìn)一步調(diào)整節(jié)點(diǎn)粒度，來控制整體的冗余，比如，粒度細(xì)化到接口級別

~~~~~~ 萌萌噠的分割線 ~~~~~~~~~

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

優(yōu)點(diǎn)：

統(tǒng)一版本控制

廣泛地代碼共享和復(fù)用

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

原子修改

大規(guī)模重構(gòu)

跨團(tuán)隊(duì)協(xié)作

靈活的團(tuán)隊(duì)邊界和代碼所有權(quán)

代碼可見性以及清晰的樹形結(jié)構(gòu)提供了隱含的團(tuán)隊(duì)命名空間

但是呢，隨著代碼量的增加，也會出現(xiàn)以下問題：

單體模型讓代碼結(jié)構(gòu)更容易理解，但卻讓代碼發(fā)現(xiàn)變得更困難

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

依賴重構(gòu)和代碼清理輔助工具，定期對無用代碼進(jìn)行清理

版本管理的重心轉(zhuǎn)移到了冗余控制上

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

代碼庫搜索工具：因?yàn)槲覀儾捎昧藛误w代碼庫，所以慢慢的代碼越來越多，代碼搜索工具就變的必不可少了

代碼發(fā)現(xiàn)工具：也是為了維護(hù)代碼庫，定期發(fā)現(xiàn)清理無用代碼

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