有贊電商移動代碼 VCS 的演進

最新 06-12

我們有幸在一個毫無疑問以 git 作為 VCS 的開發時代，git 為我們提供了太多想像力，解放了我們許多的生產力。

有贊使用自搭 git 伺服器的方式為所有的項目提供版本管理，而我們現在的產品——微商城/微小店/有贊買家版，都是基於我們的 git 倉庫進行管理的。

開天闢地

隨著公司規模和產品的發展，我們的倉庫變得越來越大，feature 越來越多，2016 年我們團隊在評估現有的代碼之後，決定開始模塊化的改造。

模塊化首當其衝的就是對 VCS 的需求產生變化，一個看上去非常簡單的 repo 可能已經不再滿足我們的需求，因為我們需要不同的模塊能足夠產品化，能夠進行獨立維護，能夠為我們的新需求提供強有力的支持，順便還能幫我們快速定位到問題轉到相關負責人的手中，這是我們的願景。

我們為模塊化做的第一件事（以 Android 為例），就是在當前的項目中，為不同的業務模塊，新建好不同的文件夾（Project），把不同業務的代碼，從一個巨大的代碼庫中，慢慢剝離開，一點一點的落地到相應的 Sub Project 裡面，好讓我們對各個業務的邊界有明確的認識。

萊剋星頓的第一聲槍響

在這個時候，我們花了很大的時間完成這項工作，在第一階段完成之後，看見清晰的目錄結構不禁沾沾自喜，但是，挖坑的弊端接踵而至——首先，Gradle 編譯的時間大大的加長了，一次編譯完成的時間足夠你去喝一杯熱氣騰騰的咖啡。每一次的產品迭代中，產品一個新需求，我們會使用 Git Flow 的標準新建一個新的分支，在分支下實現新需求，寫完代碼，等待編譯，安裝到手機上，自測，然後改 Bug，再循環。

沒錯，在沒有 TDD，暫沒辦法進行自動化測試的條件下，我們活的非常艱難，實現業務很像是在浪費生命，我們的時間如此值錢，怎麼能荒廢在天書…啊呸， compile 裡面？於是我們渴望把我們的生產力繼續解放，不能為了頭腦清楚而捆綁了手腳。

同時，我們的倉庫在業務模塊分支的開發中，分支表現的混亂不堪，經常需要一堆人聚在一塊解決合并的時候模塊的衝突的問題，現在這個樣子，好像根本沒有解決問題嘛。

巨大倉庫的改造

我們這時候維護了一個非常巨大的倉庫，每一次的分支提交，都有潛在的可能對對方造成影響。你可能在這個分支上「不小心」改了某一行別人分支的代碼，這並不是符合預期的（unexpected），結果在合并代碼的時候，就得問對方，這塊是不是你改過的，我應該選擇哪一

塊的代碼，這樣的分支合并，在比較小的項目里，可能問題表現的不明顯，因為就算變動，也是有限的幾行代碼，但是在代碼數量級高許多的項目中，它就有可能是一種災難了。我們這個時候希望把倉庫拆出來，這樣使用 VCS 去統一管理各個模塊，而不是讓他們都寄宿在一個大 repo 里。

在這之前，我們已經了解過 git submodules 的優缺點，如果使用 git submodules 進行改造的話，成本的確是非常小的，它的整個模型如下：

但是我們知道，git submodules 是在中維護一個對的一些指針，如果子 module 代碼發生了更改，除了父 module 提交代碼外，還需要對子 module 的指針進行更新，這種 contains 的操作在我們的場景里，無疑對項目增加了許多的複雜性，經過一些綜合的考慮，我們最終放棄了使用的方式，使用（https://gerrit.googlesource.com/git-repo/）進行管理。

repo 的使用

首先，非常推薦微店的梁志濤在知乎上關於【為什麼android使用repo而不是直接使用git管理工程呢】的回答，感謝他的一些技術指導，給我們對 repo 和 git submoudle 的認知提高了好多個檔次。

repo 的一些特性可以讓你在沒有插件化之前，就能用上它，用上它之後，我們現在的模型是這樣的

app 殼工程和業務模塊工程並行了，更新各個模塊的代碼再也不會對其他工程有影響。如果把業務模塊轉換成坐標依賴，我們還可以選擇性地把需要的代碼拉到本地，不需要的代碼不用去動，連 compile 的時間都省了好多，我們的願望有多麼的美好，那麼現實就會有多麼的殘酷。

首先，按照 Android 的目錄結構來看，如果我們不進行較大的配置的話，我們許多的文件，必須放到外部工程的根目錄下。

大概像這樣

為了圖中紅色字文件的正確路徑，我們一開始把這些文件打入了一個叫的 repo 里，repo 下拉代碼的時候，會在根目錄下寫入這個 repo 里的所有的文件，且在根目錄下面，繼續加入其它模塊，這樣我們發現，其它模塊又變成了的子模塊了，雖然沒有噁心，但是整體的組織結構還是很奇怪，為了保證其它模塊不被打入倉庫，我們只好在這個 repo 下面的 .gitignore 中，把其他模塊的管理都去掉了。

.gitignore 如下:

# 省略其他 # 業務模塊的 ignore wsc_login wsc_customer wsc_shop ....

我們可以看到，gitignore 居然和業務耦合在了一塊，也就是說，我再抽出一個業務，如果我忘了在裡面把這個業務文件夾 ignore 掉，就會被 push 到倉庫里，這不和 git submodule 一樣了么？我們使用 repo 不是就是要解決這樣的問題么？

於是我們參考了提供的方案，看看它是怎麼管理這種文件的。

我們可以看到，這裡面有兩個非常有用的指令就是，，給我的啟發就是，我們可以創建一個包含構建文件的 repo，用這個 repo 去管理相關的邏輯，同時，repo 的顆粒度要足夠小，讓各個 repo 各司其職，這樣 repo 之間的互相耦合就更小了，我們把這個 repo 取名為，本來想取名叫，但是可能會和生成出來的文件夾衝突，所以只好換了一個名字，名字解決後，我們整個文件夾的結構就是這樣的：