單模塊的分支管理
git解決了單項目的分支管理問題。但是這只是一個模塊的分支管理。
一個模塊內的版本可以是:
- main
- dev
- somebody/dev
- somebody/feature/xxx
多模塊的分支管理
當出現 N 個模塊組成的系統的時候,版本管理開始“向量化”。
一個系統的版本可以是:
- main
- module1@main:commit_1
- module2@main:commit_x
- ...
- dev
- module1@dev:commit_1
- module2@dev:commit_x
- ...
- project_1
- module1@projoect_1:commit_1
- module2@projoect_1:commit_x
- ...
分層系統的分支管理
如果系統內又做了分層,分爲 base / app 兩層,版本管理開始“樹化”
一個分層的系統的版本可以是:
- main
- base
- base_module1@main:commit_nn
- base_module2@main:commit_mm
- app
- module1@main:commit_1
- module2@main:commit_x
- ...
- base
- dev
- base
- base_module1@dev:commit_nn
- base_module2@dev:commit_mm
- app
- module1@dev:commit_1
- module2@dev:commit_x
- ...
- ...
- base
- project_1
- base
- base_module1@project_1:commit_nn
- base_module2@project_1:commit_mm
- app
- module1@project_1:commit_1
- module2@project_1:commit_x
- ...
- ...
- base
分層系統的分支管理困難根源
在分層的系統級分支管理上,如果嚴格遵守下面的分支管理策略,會簡化非常多工程上的工作。
- 定義 system_main 代表上面的分層系統的 main 分支
- 定義 system_dev 代表上面的分層系統的 dev 分支
- 定義 system_project 代表上面的分層系統的 feature 分支。
那麼如果系統層上總是能從 dev->main->project 單線Pull-request 的話,系統的維護會向一個模塊的分支管理一樣簡單。
但是,實際上不會發生這種事,實際上,在模塊內,模塊的開發是這樣的:
- 有一個 dev 分支
- dev 分支的開發會往 main 合併
- 如果有某個項目需求,會從 main 拉出一個 project_1 分支,然後,後續 project_1 上的修改要經過耗時更久的週期開發,滿足 project_1 上的需求,並且它增長的commit會一直應用到 system_project_1 的commit裏。與此同時, dev->main的主版本也在增長。
經過幾個版本後,就會面臨模塊的 project_1 分支和 dev/main 分支的巨大差異,難以做分支的管理。
這是一個問題,如何在模塊級別解決呢?
根本問題在於,模塊級別要保持單線條,模塊級別無論如何都堅持不分裂版本,堅持保持:
feature->dev->main 分支。
在system 級別,應該總是:
- system_dev: 採用模塊的 dev 分支。
- system_main: 採用模塊的 main 分支。
- system_project: 採用模塊的 main 分支!!!
那麼,如何解決 system_project 上的「項目級」特殊需求呢?
答案是:沒有特殊需求,所有需求都應該在 dev->main 上直接提供,system_project 只是在模塊的 main 分支上,apply 了一組配置,這組配置是功能的開關。
事實上有些模塊就是這麼做的。而有些模塊則版本之間差異很大,這實際上造成了分支的不一致,從而導致工程上的各種重複工作,例如在 main 上獲得了好的工程指標,在project上滯後工程指標差,同時有巨大的同步壓力。
核心就是:模塊級別永遠不分裂版本,保持單線條分支迭代: feature->dev->main
這是一個問題,如何在系統級別解決?
在系統級,不要讓模塊自由配置分支的名字,堅持以固化的分支名字來組織系統:
system_dev: 只裝配每個模塊的名字爲 dev 的分支,部分同一個倉庫分離出的可以加前綴:例如 xxx/dev,但是必須是這樣命名的分支。門禁上直接禁止其他名字分支名字在系統級配置裏出現。
同理,system_main: 只裝配每個模塊名字爲 main 的分支。
現在,system_project_1: 只裝配每個模塊名字爲 main 的分支。但是應用了一組預定義的「項目配置」。
system_main 和 system_project 都用的是模塊的 main 分支,但是每個模塊的commit 可能不同,但是system_project裏的模塊 commit 一定舊於 system_main 裏的模塊 commit。也就是說 system_project 裏的模塊 commit 一定是曾經出現在某一個版本 system_main 裏的 commit。 這就倒逼了 模塊功能發佈到 project,一定經歷了system_dev 系統,經歷了 system_main 系統,最後發佈到了 system_project。
這是一個問題,如何解決迭代速度問題?
這樣的系統級分支管理,挑戰是如何保證迭代速度,模塊不能再直接從模塊 commit 提交到 system_project。那就是要求 system_dev -> system_main -> system_project 的迭代非常快速。解決好這個迭代速度就會是工程上的核心水平構建。
但是一旦成功,收益將會是巨大的:所有的工程指標,只需要在 dev->main 上做一次。這是一個工程算法複雜度問題。
--end--