再論分支管理問題。

單模塊的分支管理

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
    • ...
• dev
  • base
    • base_module1@dev:commit_nn
    • base_module2@dev:commit_mm
  • app
    • module1@dev:commit_1
    • module2@dev:commit_x
    • ...
  • ...
• 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
    • ...
  • ...

分層系統的分支管理困難根源

在分層的系統級分支管理上，如果嚴格遵守下面的分支管理策略，會簡化非常多工程上的工作。

• 定義 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--