供交流分享，寫的比較倉(cāng)促，假定讀者有一定基礎(chǔ)
背景
目前在一家外包業(yè)務(wù)為主的公司任職，近期因公司效益和政策原因影響，出現(xiàn)同事大批量離職的情況。
起因
因?yàn)榻唤庸ぷ鞅容^集中，而且一個(gè)有產(chǎn)品理想的外包公司特點(diǎn)就是多項(xiàng)目、多版本，所以待交接內(nèi)容很多，那身在一家公司的邊緣（窮）開發(fā)部門，主要交接內(nèi)容就是源碼和文檔。撇開規(guī)范性和完整性不談，在整理離職同事的倉(cāng)庫和資料時(shí)，發(fā)現(xiàn)多個(gè)項(xiàng)目共用一套代碼的情況非常難以理解和整理，所以萌生出了一些新的管理思路，簡(jiǎn)單推敲了一下發(fā)現(xiàn)基本可行，這里記錄一下免得后續(xù)忘記了。
現(xiàn)狀
目前的模式是一套源碼（產(chǎn)品或者第一個(gè)此類業(yè)務(wù)的項(xiàng)目），只要新的外包項(xiàng)目業(yè)務(wù)一致，那么就在這個(gè)倉(cāng)庫中新建一個(gè)分支，在這個(gè)分支上進(jìn)行新項(xiàng)目的定制化改動(dòng)和調(diào)整。
這個(gè)模式本身是沒什么問題的，最大的好處就是可以共用代碼，共享bug修復(fù)和新的功能特性（即在一個(gè)項(xiàng)目中發(fā)生了變動(dòng)，其他項(xiàng)目同步調(diào)整），也符合標(biāo)準(zhǔn)意義上的產(chǎn)品開發(fā)流程。但畢竟我們還是一家外包公司，主要業(yè)務(wù)還是在接項(xiàng)目->快速出活->接項(xiàng)目這個(gè)死循環(huán)中。
說了這么多，問題點(diǎn)在哪里呢，以下：
- 過多的分支會(huì)導(dǎo)致項(xiàng)目不清晰，如果非常倉(cāng)促的接過來，很難快速搞清楚某個(gè)外包項(xiàng)目是用的哪套源碼，畢竟每個(gè)外包項(xiàng)目的叫法也不一樣；況且你每個(gè)外包分支又會(huì)有多個(gè)開發(fā)分支，你怎么區(qū)分？
- 不符合項(xiàng)目管理需要，在項(xiàng)目的Git倉(cāng)庫組管理模式中，一個(gè)項(xiàng)目會(huì)存在多個(gè)平臺(tái)的源碼倉(cāng)庫，比如一個(gè)防疫管控系統(tǒng)，你要有服務(wù)器，要有接口，要有移動(dòng)平臺(tái)，這就最少三個(gè)源碼倉(cāng)庫。但現(xiàn)在的源碼管理模式中，假設(shè)你的項(xiàng)目是脫胎于基于GIS的疫情防控平臺(tái)，那么只有這個(gè)里面會(huì)存在三個(gè)倉(cāng)庫，其他的后續(xù)孵化項(xiàng)目倉(cāng)庫組中壓根不存在這三套源碼，因?yàn)槎荚诘谝粋€(gè)倉(cāng)庫進(jìn)行分支管理了；你要覺得OK也沒啥問題的話，是因?yàn)槲遗e的這個(gè)例子是簡(jiǎn)化模型，假設(shè)企業(yè)健康上報(bào)平臺(tái)后續(xù)新增了一個(gè)數(shù)據(jù)自動(dòng)采集工具，那么企業(yè)健康上報(bào)平臺(tái)倉(cāng)庫組現(xiàn)在是有一個(gè)源碼倉(cāng)庫的是吧，你一個(gè)不了解的人接過來一看，你這個(gè)企業(yè)健康上報(bào)項(xiàng)目會(huì)不會(huì)就被認(rèn)為是只是一個(gè)數(shù)據(jù)自動(dòng)采集業(yè)務(wù)？
思路
后續(xù)發(fā)現(xiàn)其實(shí)走偏了，我們并不是做出一款產(chǎn)品服務(wù)于大眾。畢竟是一家外包公司，就算做出產(chǎn)品推廣也是各外包項(xiàng)目定制差異化推廣，并且是按照功能點(diǎn)進(jìn)行收費(fèi)，按照工作量進(jìn)行運(yùn)維。那么我新功能和bug修復(fù)都是收費(fèi)的，就算不特性不共享，我手動(dòng)粘過來，也沒有會(huì)太大工作量。我認(rèn)為在外包廠的項(xiàng)目體量和項(xiàng)目嚴(yán)格管理標(biāo)準(zhǔn)下，這部分工作量的犧牲反而會(huì)給工作帶來便利，最起碼符合人的管理習(xí)慣。項(xiàng)目經(jīng)理也會(huì)對(duì)項(xiàng)目資源有個(gè)整體的把控，而不是在亂七八糟的扒拉各種倉(cāng)庫，找分支，找代碼。
后續(xù)你給錢給合同，我們繼續(xù)合作，我給你運(yùn)維給你加功能。你后來不給錢了，那么我也沒必要讓你享受運(yùn)維服務(wù)，在外包思路上邏輯也是正確的。
所以具體應(yīng)該怎么做呢？很簡(jiǎn)單，就是如果一個(gè)新的外包項(xiàng)目產(chǎn)生了，那么從歷史倉(cāng)庫 copy 一份倉(cāng)庫就可以了，兩份倉(cāng)庫代碼獨(dú)立，互相管理。就這么簡(jiǎn)單，源碼在分支上遵循技術(shù)上的分支管理規(guī)范，只是做一個(gè)項(xiàng)目定制分支上的調(diào)整。退一步講，你如果長(zhǎng)時(shí)間不維護(hù)后續(xù)一把來了，我就算把新的版本粘過來，借助 git 強(qiáng)大的代碼對(duì)比工具，理論上也可以較快的完成特性平移的。
后續(xù)
以上僅僅是理論可行，接下來還要實(shí)踐后再出具體的使用結(jié)論。如果在看的你有更好思路方法，又或者知道某大廠的管理模式更科學(xué)，歡迎留言討論
