供交流分享踩身，寫的比較倉促萤晴，假定讀者有一定基礎(chǔ)
背景
目前在一家外包業(yè)務(wù)為主的公司任職吐句，近期因公司效益和政策原因影響，出現(xiàn)同事大批量離職的情況店读。
起因
因為交接工作比較集中蕴侧，而且一個有產(chǎn)品理想的外包公司特點(diǎn)就是多項目、多版本两入，所以待交接內(nèi)容很多，那身在一家公司的邊緣（窮）開發(fā)部門敲才，主要交接內(nèi)容就是源碼和文檔裹纳。撇開規(guī)范性和完整性不談择葡，在整理離職同事的倉庫和資料時，發(fā)現(xiàn)多個項目共用一套代碼的情況非常難以理解和整理剃氧，所以萌生出了一些新的管理思路敏储，簡單推敲了一下發(fā)現(xiàn)基本可行，這里記錄一下免得后續(xù)忘記了朋鞍。
現(xiàn)狀
目前的模式是一套源碼（產(chǎn)品或者第一個此類業(yè)務(wù)的項目）已添，只要新的外包項目業(yè)務(wù)一致，那么就在這個倉庫中新建一個分支滥酥，在這個分支上進(jìn)行新項目的定制化改動和調(diào)整更舞。
這個模式本身是沒什么問題的，最大的好處就是可以共用代碼坎吻，共享bug修復(fù)和新的功能特性（即在一個項目中發(fā)生了變動缆蝉，其他項目同步調(diào)整），也符合標(biāo)準(zhǔn)意義上的產(chǎn)品開發(fā)流程瘦真。但畢竟我們還是一家外包公司刊头，主要業(yè)務(wù)還是在接項目->快速出活->接項目這個死循環(huán)中。
說了這么多诸尽，問題點(diǎn)在哪里呢原杂，以下：
- 過多的分支會導(dǎo)致項目不清晰，如果非常倉促的接過來您机，很難快速搞清楚某個外包項目是用的哪套源碼穿肄，畢竟每個外包項目的叫法也不一樣；況且你每個外包分支又會有多個開發(fā)分支往产，你怎么區(qū)分被碗？
- 不符合項目管理需要，在項目的Git倉庫組管理模式中仿村，一個項目會存在多個平臺的源碼倉庫锐朴，比如一個防疫管控系統(tǒng)，你要有服務(wù)器蔼囊，要有接口焚志，要有移動平臺，這就最少三個源碼倉庫畏鼓。但現(xiàn)在的源碼管理模式中酱酬，假設(shè)你的項目是脫胎于基于GIS的疫情防控平臺，那么只有這個里面會存在三個倉庫云矫，其他的后續(xù)孵化項目倉庫組中壓根不存在這三套源碼膳沽，因為都在第一個倉庫進(jìn)行分支管理了；你要覺得OK也沒啥問題的話，是因為我舉的這個例子是簡化模型挑社，假設(shè)企業(yè)健康上報平臺后續(xù)新增了一個數(shù)據(jù)自動采集工具陨界，那么企業(yè)健康上報平臺倉庫組現(xiàn)在是有一個源碼倉庫的是吧，你一個不了解的人接過來一看痛阻，你這個企業(yè)健康上報項目會不會就被認(rèn)為是只是一個數(shù)據(jù)自動采集業(yè)務(wù)菌瘪？
思路
后續(xù)發(fā)現(xiàn)其實走偏了，我們并不是做出一款產(chǎn)品服務(wù)于大眾阱当。畢竟是一家外包公司俏扩，就算做出產(chǎn)品推廣也是各外包項目定制差異化推廣，并且是按照功能點(diǎn)進(jìn)行收費(fèi)弊添，按照工作量進(jìn)行運(yùn)維录淡。那么我新功能和bug修復(fù)都是收費(fèi)的，就算不特性不共享表箭，我手動粘過來赁咙，也沒有會太大工作量。我認(rèn)為在外包廠的項目體量和項目嚴(yán)格管理標(biāo)準(zhǔn)下免钻，這部分工作量的犧牲反而會給工作帶來便利彼水，最起碼符合人的管理習(xí)慣。項目經(jīng)理也會對項目資源有個整體的把控极舔，而不是在亂七八糟的扒拉各種倉庫凤覆，找分支，找代碼拆魏。
后續(xù)你給錢給合同盯桦，我們繼續(xù)合作，我給你運(yùn)維給你加功能渤刃。你后來不給錢了拥峦，那么我也沒必要讓你享受運(yùn)維服務(wù)，在外包思路上邏輯也是正確的卖子。
所以具體應(yīng)該怎么做呢略号？很簡單，就是如果一個新的外包項目產(chǎn)生了洋闽，那么從歷史倉庫 copy 一份倉庫就可以了玄柠，兩份倉庫代碼獨(dú)立，互相管理诫舅。就這么簡單羽利，源碼在分支上遵循技術(shù)上的分支管理規(guī)范，只是做一個項目定制分支上的調(diào)整刊懈。退一步講这弧，你如果長時間不維護(hù)后續(xù)一把來了娃闲，我就算把新的版本粘過來，借助 git 強(qiáng)大的代碼對比工具当宴，理論上也可以較快的完成特性平移的畜吊。
后續(xù)
以上僅僅是理論可行，接下來還要實踐后再出具體的使用結(jié)論户矢。如果在看的你有更好思路方法，又或者知道某大廠的管理模式更科學(xué)殉疼，歡迎留言討論
