爲何須要版本管理

前言

相信不少開發者已是直接使用git了，沒有經歷過svn的年代。但這不影響咱們瞭解這個常識。

備註：本文的觀點僅僅是我的的觀點，不具備權威性，僅僅是工做感覺，以及參考一些文章後的自我思考。

解決問題

版本的存在必定是解決問題的，解決哪幾類的問題呢？

服務器環境

服務器環境是咱們使用版本後最優先解決的問題，因此在版本里咱們優先設置了針對環境的不一樣主分支，這些分支是每一個環境所肯定使用的分支，若是公司有在使用自動化部署，極可能會把環境與分支作嚴格的對應。好比下面的對應關係：

環境	分支名	備註
線上	release	發佈以後，有的公司可能會針對重要的release發佈version
預發佈	beta	擬生產環境，主要回歸功能在線上數據和環境下是否有問題
測試	qa/test	主要的測試環境，也有的稱爲集成測試，由於有的開發代碼可能原先是單獨測試，沒有考慮互相的影響
開發	develop	主要的開發環境，開發分支，開發完成後都要歸併到這個分支

有了這個分支對應關係還不算完整，還須要對應的發佈流程，以及發佈流程中會如何使用這些分支，來保證如下幾個原則：

• 不丟失更上一級的代碼
• 在合併下一級代碼時，預先讓下一級代碼合併上級代碼，解決代碼衝突問題
• 不污染其餘環境的對應分支
• 等等

所以，咱們制定了相應的每一個分支更具體的定義，以及相應的分支流向。

點擊查看：www.yuque.com/robinson/gi…

線上歷史發佈版本

線上歷史發佈版本主要針對兩個可能狀況：1 週期迭代版本 2 重大功能更新。這裏不得不提，開源項目與非開源項目的區別。

項目類型	發佈緣由、頻率	備註
開源項目（技術框架）或者公司四研發的客戶端軟件版本	大的功能更新，更新頻率更低	主要是針對功能版本發版本，避免版本發佈過於頻繁對用戶的影響，比較明顯的像基本的技術框架，app版本
非開源項目（後端項目版本，web版本）	週期性迭代（頻率很高）	週期性迭代，是指每1-2周，開發人員都會作一些開發工做，可能包括了小功能，代碼重構，交互優化等等，因此這類必然會致使小版本很是多，固然也有可能會針對一個大的功能發大版本
非開源項目（外包項目）	大型項目開發（頻率很低）	通常是非敏捷開發，長週期的產品總體功能的開發，按照大版本開發

那麼咱們針對本身的狀況發佈了不一樣的歷史版本，究竟有什麼具體用途呢？僅僅是留個歷史版本擺着看麼？固然不是。我能想到的是如下幾點：

1.針對鮮明的功能版本作代碼區分：在不少時候咱們須要清楚知道一個功能的代碼影響範圍，經過功能版本咱們能夠清楚的看到；另一個目的，就是，若是咱們想針對某個功能版本，針對這個功能，作升級或者方案替換，那麼目的會很是明顯，也能夠最大程度的參考以前的代碼設計思惟。

2.方便用戶使用以及問題排查：主要是針對用戶場景，針對不一樣版本咱們會開放出不一樣功能，優化不一樣的問題，當用戶反饋的時候，咱們能夠經過版本號，先模糊排查問題，若是是低版本的問題，用戶進行升級便可。另一個就是，有些版本的功能屬於內測版本，或者最新版本，對於有些開發者比較傾向使用穩定版本或者歷史版本，區分出版本利於開發者或者用戶決定是否升級，或者指定使用哪一個版本。

3.開發過程當中的代碼重置，這個有時候會發生，好比，咱們開發某個功能，開發完成後，代碼提到了測試分支，測試分支也改了一些代碼，可是此時項目經理說，這個版本徹底廢棄或者延期上線，你怎麼辦？首先，須要明確的是，咱們須要把測試分支重置到上一個沒有合併開發分支的版本，你能夠經過尋找test分支的歷史提交記錄，或者適用beta分支重置，若是beta分支是肯定不會污染測試分支的沒有bug的，但若是你有歷史發佈版本的話，其實問題就很簡單了，你只要重置爲上一個歷史發佈版本便可，最少這是一種可行方案，固然這種的前提是，你完整的丟棄test分支所作的開發合併。

4.線上發佈中的版本重置，當咱們發現發佈某個版本時，致使了線上版本的崩潰，並且短時間內不能解決問題，那麼做爲運維人員，只要將上個發佈版本的代碼從新發布一遍做爲預備方案就能夠了。（這裏只考慮代碼致使的問題，其餘數據庫的數據回退等這裏不作考慮）

5.不一樣模塊的溝通以及依賴機制，通常狀況下，不少時候咱們的代碼還會依賴於其餘人項目的版本，而若是對方沒有相應的準確的版本號描述，其餘同窗便不知道該使用你的哪一個版本，不少時候並非最新的版本或者線上版本，而是另外一個版本。

本地倉庫與遠程倉庫

說道本地倉庫有什麼用，固然要提到本地倉庫的一些特色，以及以前沒有本地倉庫以前的存儲機制是如何的。

在沒有本地倉庫以前，你們想存儲代碼通常是必須經過直接提交到遠程的，並且必須有網絡，但這樣有個明顯的問題就是咱們可能會把有問題的代碼也提交上去。而別人正是經過拉取遠程代碼同步的，若是你把沒有開發完成的代碼提交上去，會致使使用同項目的開發同窗遇到本身所不瞭解的代碼問題。

而本地倉庫的兩個明顯優勢：1 能夠離線存儲 2 能夠實如今本地存儲代碼而不提交到遠程。也正因爲第二個特色，咱們對提交本地倉庫代碼的clean的要求有所放低。當你認爲本身代碼沒問題時，在一次性與遠程同步便可。 在你沒有提交到遠程時，別人同步拉取的代碼都是正確的。

因此當團隊內的成員代碼之間有依賴關係的時候，須要對團隊成員的提交作必定的限制說明，提交到遠程的代碼，儘可能是clean，righ的，或者最少在推送修改時，通知到相關的使用人。

多人協做

多人寫做最明顯的是開發環境下，你們從開發分支拉出不一樣的分支。這裏面有兩種主要可能狀況：

1 基於開發分支，不一樣人拉不一樣功能的feature分支，而後具體功能只在對應功能分支上開發，完成開發以後再聚合到develop分支上，分分支的時候，以dev-featureName爲區分。

2 基於開發分支，同一功能須要不一樣開發者協做完成，完成開發以後再聚合到develop分支上，分分支的時候，以dev-featureName-name爲區分。

bugfix分支

通常狀況下，咱們只對線上分支的bug拉bugfix分支進行問題修訂，肯定修補完成，再合併到主分支。因此它的流向會是：

release/master ==> bugfix ==> release/master

而在預發佈環境，測試環境，開發環境，由於其形成的影響不是很大，因此通常是不會針對一個具體的bug拉取問題分支的，而是在對應環境分支直接修改全部問題。但若是有必要，爲了減小對他人的開發，你也能夠拉分支。

同分支歷史版本

這一點主要是咱們對同一個開發分支，對重要的提交作備註，以及能夠找到不一樣提交狀態下的hash值，獲得這個值以後，咱們能夠根據提示的commit msg，結合hash更快的回到某個歷史狀態。

因此若是你想更好的利用好這一點，對咱們提交記錄填寫的信息的規範性很重要。

版本對比分析，作cr

這個主要發生在兩種主要狀況：

1 代碼合併請求，也就是merge request,當代碼發起歸併請求時，爲了下降風險，咱們通常會對將要合入的代碼作兩個分支的代碼對比，仔細查看兩個分支的代碼區別，一一排查區別與問題。

2 排查問題，主要針對，原來的分支是麼有這種問題，新開發分支相對有問題時；或者也多是相反的關係，咱們能夠更快的經過代碼對比， 找出差別代碼就行問題的糾正。

咱們須要如何操做

其實，不一樣分支的用途以及整個分支的變化過程仍是比較嚴格的，基本能夠知足咱們各類需求，咱們有必要了解全部分支的可能，以及代碼分支流向。但還必須有幾個基本點把握：

1 咱們須要知道全部不一樣的分支分別用於解決什麼問題，分支的代碼流向設計成如何能夠解決什麼問題。
2 不是全部團隊都嚴格執行分支流向管理和版本管理，對此沒必要過於執念，能解決當前需求的狀況下，就按照怎麼簡單怎麼來；可是當分支管理出現問題的時候，咱們須要心中有必定的分支管理方案。
3 基本的分支狀態，代碼同步的命令要知道，雖然咱們能夠藉助工具來完成，但爲了更好的理解這個過程，最好是本身操做一遍命令的方式同步分支代碼的過程。。
4 對於分支，除了藉助規範，更重要的是培養團隊的版本意識，靈活的解決各類問題的分支管理方案。當認知不在一個層次時，你認爲很合理的內容可能別人認爲不必；也可能會出現，別人的認知很合理，而本身因爲認知不到位，看不到潛在問題，而盲目反對對方的分支管理規範。

面試相關

通常技術面試，多少都會問到大家的項目研發流程如何，代碼是基於git如何進行分支管理的，發佈流程中的代碼流向是如何的，若是你以前只是放任團隊裏其餘人說你要提個mr，而不知道爲何如此，可能本文正是你應該知道的常識。

友情連接

git常識小冊:www.yuque.com/robinson/gi…