原創不易，歡迎閱後點贊關注支持，本期內部分享PPT可自取，見文末！前端
最近筆者所在公司發生了一塊兒小風波，事情大概是這樣的：市場部老大在給客戶現場演示系統時，正討論着一個主題，恰巧系統在切換到相關功能時出現了異常，致使功能不可用，現場有點尷尬。git
顯然，問題歸咎於研發部。嚴肅的氣氛下，我下意識在想本身是否是涼了，因而我迅速定位緣由，發現是後端接口發生變動而未通知前端，責任人正好是剛來沒多久的後端新人。雖然此次事故不是前端的責任，但讓我發現了後端Team存在的問題，在版本控制上有較大的隱患，代碼未經Review就入庫發版了，這本質上是分支管理不合理致使的。web
研發部門是一個總體，當着客戶的面出了生產事故，這讓你們面子上都很差看，因此我挺身而出提出在研發部內部作一次Git分支管理的分享，看看能不能幫你們解決這個問題。我入職以來一直比較注意版本控制這塊，但也是今年才比較系統地梳理研發流程和版本控制（去年是快速出產品的一年，管理上稍微糙一點），幾個月前還特地總結了一篇《前端小微團隊的Gitlab實踐》，通過數月的不斷實踐和改進，我感受這套Git體系基本覆蓋了我司的研發流程，至今沒出過事故，發版節奏一直良好。後端
其實幾個月前我就想在部門內分享下我這套版本控制流程，可是一方面是考慮到本身剛摸索出來，不太熟練，另外一方面是本身資歷尚淺，若是跨Team直接給後端老哥們「上課」也不太好吧（其實這個顧慮是多餘的~_~）。微信
嗯，大概是這麼一個心路歷程，而如今正是必須站出來的時候，我但願此次個人分享能爲團隊盡綿薄之力！具體分享的內容是這樣的，且聽我慢慢道來！app
我的感覺
Git對咱們來講既熟悉又陌生。感受熟悉是由於咱們彷佛已經掌握了大量經常使用的Git命令，感到陌生是由於咱們在實際項目中老是用很差它。是的，我也有過這樣的感覺，直到如今，我以爲Git仍有不少待探索的空間，好比難以理解的git rebase，又或者是Git提供的Hooks，讓自動化部署有了更多可能。甚至一些平臺將代碼託管，敏捷開發，CI/CD，DevOps融合到了一塊兒，提供了一站式解決方案。編輯器
始於Git，卻不止於Git，Git還有太多值得咱們折騰的小驚喜。那麼，今天我以如何在實際項目中運用Git分支管理這個主題做爲切入點作一次內部分享。分佈式
分佈式版本控制
咱們知道，Git是一個開源的分佈式版本控制系統，這讓團隊協做成爲了可能。咱們能夠經過fetch/pull將遠程倉庫的代碼拉取到本地，也能夠將本地代碼push到遠程倉庫。ide
而咱們向版本庫提交代碼的一個基本方向是：學習
工做區 --> 暫存區 --> 版本庫
-
當對工做區修改（或新增）的文件執行 git add命令時，暫存區的目錄樹被更新。 -
當執行 git commit命令進行提交操做時，暫存區的目錄樹寫到版本庫中。
分支管理
Git最核心的內容固然是分支管理，設置合理的分支可讓研發流程有條不紊。使用分支意味着你能夠從開發主線上抽離出來，不影響主線的前提下進行工做，最後完成工做再經過git merge將代碼合入到主幹分支上。
簡單的分支管理
在生產實踐中，通常來講，咱們會保持至少三個分支，分別是開發分支develop，測試分支release，生產主幹分支master。不一樣的團隊或我的在分支命名上可能會有所差別，可是基本邏輯都是大致一致的。
-
開發分支 develop： 最不穩定的分支，全部和特性，缺陷相關的代碼都會陸續地被提交到這個分支。 -
測試分支 release：一個敏捷迭代結束時，正常狀況下，全部develop分支的代碼都會被merge到release分支，準備發測試版本。 -
生產分支 master： 最穩定的分支，待交付的版本上線前，測試經過的release分支會被merge到master分支。
然而不少團隊在管理develop分支時存在一個很大的問題：全部開發者都直接向develop分支push代碼。
這樣會形成不少隱患，包括但不限於：
-
團隊成員間代碼衝突。固然，直接向 develop分支push代碼也不是形成衝突的根本緣由。可是，這會讓衝突更容易發生！ -
代碼質量不可控。這個問題你們都比較清楚了，這是由於全部代碼都沒有通過 Review就入庫了！ -
版本不可控。相信你們都遇到過，臨到上線時間點，忽然發現某某開發者的轉測功能存在重大缺陷，不能上線。這個時候，選出能上線的代碼讓人頭疼！根本緣由是開發者的代碼都直接進了 develop分支，這讓挑選代碼變成了一件很是複雜的事情！
可控的分支管理
那麼如何才能解決上述痛點呢？咱們能夠從分支的設計上入手。
-
保護分支（Protected Branchs）。禁止開發者直接向保護分支提交代碼， develop，release，master都應該被設置爲保護分支！ -
增長特性/缺陷分支，避免直接向 develop分支push代碼。 -
增長代碼Review環節，基本上全部代碼託管平臺都支持這個環節！
具體操做流程是這樣的：
-
如上圖所示，咱們約定一個特性或一個缺陷就是一個開發任務， 全部的開發任務都應該在本地創建獨立的分支。 -
開發者在特性/缺陷分支上進行開發。因爲咱們禁止了向保護分支直接 push代碼，因此開發者完成代碼編寫後，須要將本地分支 同步到遠程同名分支。 -
在代碼託管平臺如Gitlab上發起 Merge Request，請求將特性/缺陷分支合入到 develop分支。 -
Maintainer（通常是團隊資深成員，擁有贊成MR的權限）負責 Code Review，確認基本無誤後贊成MR，代碼就順利進入 develop分支了。 -
後面全量發版本的流程就簡單了，無腦 merge便可！ -
若是不能全量發版，必須進行代碼挑選，此時就須要 cherry-pick出場了！
特別注意，必定要保證分支的原子性，一個分支只幹一件事。千萬不要寫着寫着代碼，忽然萌生了在當前分支順手改另外一個問題的想法，這可能會讓你陷入更大的麻煩！
分支命名
取名字永遠是個難題，組件如何命名，方法如何命名，這些問題在平時開發過程當中老是讓人抓耳撓腮。固然，Git分支命名也不例外。
我以前也試過度支語義化命名，可是也發現了要用有限的單詞描繪出複雜的含義永遠是個僞命題。如上圖所示，咱們可能會在作一個新功能時，把相關分支命名爲feature/xxx，然後面有優化類需求時，又會新建一個feature/xxx-optimization之類的分支。然而，每每一個功能會有一次又一次的優化、變動或bug，採起這樣的命名策略永遠會讓本身直面靈魂拷問！
而且在追溯問題時，這種分支命名方式每每讓人心力交瘁！
那麼如何命名能解決這樣的問題呢？我採用了下面這種策略！
我在觀察不少開源軟件時發現，他們的維護者都會用issue來記錄各類開發相關的活動。好比需求，缺陷都會被記錄在issue中，這讓我以爲用issue來管理分支也是一個很是棒的idea！
咱們能夠在建立issue時填寫標題和描述，而且能夠經過連接等形式與敏捷管理平臺的需求和缺陷關聯上，還能夠給issue打上不一樣的標籤，看起來會很是直觀。
issue還能夠與milestone（里程碑）關聯，用於檢驗和衡量階段性的成果！想要知道更多細節，不妨打開《前端小微團隊的Gitlab實踐》細緻閱讀！
而issue自己有一個編號，或者叫ID，這種惟一標識讓咱們命名分支變得簡單。假定一個issue的編號是1，那麼咱們在本地建立分支時，只須要將分支命名爲issue/1便可，根據這個編號，我就能查到這個分支處理的是哪一個issue，而打開Gitlab的issue，我就能知道這個issue與什麼需求或缺陷有關。這不只給開發者帶來了方便，也讓管理者變得更輕鬆！
實際項目中如何操做？
對上文中的知識有了必定了解後，接下來就是看看如何在項目中把這些知識運用起來，造成一個合理，高效的流程！我以新需求爲例，簡單畫了一下流程，請看下圖：
打通了這麼一個主流程後，相信不管是修復bug，仍是其餘的場景，你都能觸類旁通！
分支節點可拓展
實際上，不一樣公司在分支節點上的數量是不同的。有的公司可能從開發到上線，會涉及多套環境驗證，這樣下來，就可能對應多個Git分支節點。加節點也不用怕，結合git merge和git cherry-pick，理論上再多節點也能應付得過來！
因此，我也在內部分享結尾時，提出了增長預發佈環境的建議。測試環境儘量發揮想象，能夠測試各類極端狀況。而預發佈環境儘可能模擬生產環境，保證數據和流程的合理性。這樣一來，結合測試環境和預發佈環境，咱們能覆蓋更多的測試用例，上線故障率會更低！
VSCODE必備擴展：GitLens
最後推薦你們安裝一個很是好用的VSCODE擴展：GitLens
有了它，咱們就能夠隨時看到每一行代碼最近一次的改動都是誰提交的。
這也避免了你們查問題時，忽然翻到一行可疑代碼，而後感嘆：這是哪一個傻X寫的！
最後一查記錄發現是本身寫的......
科科，GitLens它不香嗎？
感謝閱讀
因爲時間有限，本次分享的PPT和做圖都有些簡單，請勿介意！本次分享主要講解了筆者是如何運用Git分支去解決項目中實際遇到的痛點，總的來講仍是乾貨滿滿的，但願對你們有所幫助，喜歡的朋友請留下您的關注和點贊支持一下我吧！
PPT也分享出來了，有須要的請自取。搜索公衆號【前端司南】，回覆PPT，獲取本期內部分享PPT！
❤️ 感謝支持
-
若是您以爲這篇文章質量還不錯，請滑動至下方，點擊在看、分享 、點贊 ，讓更多人看到優質的文章。 -
關注公衆號「前端司南」加我好友，我拉你進「前端技術交流羣」， 一塊兒交流學習成長。
本文分享自微信公衆號 - 大前端技術沙龍（is_coder）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。