---
# System prepended metadata

title: 版本管控方案
tags: [idea]

---

# 版本管控方案

###### tags: `idea`

我歸納出以下幾種版控架構可以嘗試運行在公司內部, 也分析了這幾種的優缺點, 以下兩種方式都考慮了 confidential 為前提。

### git submodule

- 缺點：
    - manager 會很麻煩, 每當其中一個 node 要更新測試時, manager 必須幫忙推進(因為只有 manager 看得到 main_project), 同時它也要了解每個 node 的狀態, (pull request) 可以解決這個問題, 但是可以使用 pull request 代表可以看到所有人的程式碼
- 優點：
    - repository 會很乾淨, 每次推進也不會很複雜

### main_project 使用一個文件來紀錄大家的版本狀態

- 缺點：
    - 每次推進程序會比較複雜, 大家要按照規範一起維護 main_project 的文件, 更改裡面的版本號
- 優點：
    - 由於大家是共同維護 main_project, 所以可以自己推進 main_project, 不會只有 manager 在維護, 比較不會相互影響到進度



---

PS:
假設每個 sub_repo 都符合這個原則(只有回到 develop, release, master 時才會更新 main_project), 那麼 main_project 似乎也只需要 develop, release, master 三條線, 這似乎可以簡化許多。