Ⅰ. 前言

? 我們知道，一個軟件從零開始到最終交付，大概包括以下幾個階段：規劃、編碼、構建、測試、發布、部署和維護。

? 最初，程序比較簡單，工作量不大，程序員一個人可以完成所有階段的工作。但隨著軟件產業的日益發展壯大，軟件的規模也在逐漸變得龐大。軟件的復雜度不斷攀升，一個人已經 hold 不住了，就開始出現了精細化分工。如下圖所示：

但在傳統的 IT 組織下，開發團隊（Dev）和運維團隊（Ops）之間訴求不同：

• 開發團隊(尤其是敏捷團隊)追求變化
• 運維團隊追求穩定

? 所以雙方往往存在利益的沖突。比如，精益和敏捷的團隊把持續交付作為目標，而運維團隊則為了線上的穩定而強調變更控制。部門墻由此建立起來，這當然不利于 IT 價值的最大化。

? 為了彌合開發和運維之間的鴻溝，需要在文化、工具和實踐方面的系列變革 ? DevOps 正式登上舞臺。

? DevOps（Development 和 Operations 的組合詞）是一種重視 “軟件開發人員（Dev）” 和 “IT運維技術人員（Ops）” 之間溝通合作的文化、運動或慣例。透過自動化 “軟件交付” 和 “架構變更” 的流程，來使得構建、測試、發布軟件能夠更加地快捷、頻繁和可靠。在 DevOps 的軟件開發過程包含計劃、編碼、構建、測試、預發布、發布、運維、監控，由此可見 DevOps 的強大。

? 講了這么多，這個故事到底和我們課程的主題 Git 有什么關系呢？

? 舉一個很簡單的例子就能說明這個問題。一個軟件的迭代，在我們開發人員看來，說白了就是對代碼進行迭代，那么就需要對代碼進行管理。如何管理我們的代碼呢，那不就是 Git（分布式版本控制系統） 嗎，所以 Git 對于我們開發人員來說其重要性就不言而喻了！

Ⅱ. 系統開發環境

言歸正傳，對于開發人員來說，在系統開發過程中最常用的幾個環境必須要了解一下：

1. 開發環境：開發環境是程序猿們專門用于 日常開發的服務器。為了開發調試方便，一般打開全部錯誤報告和測試工具，是最基礎的環境。
2. 測試環境：一個程序在測試環境工作不正常，那么肯定不能把它發布到生產機上。該環境是 開發環境到生產環境的過渡環境。
3. 預發布環境：該環境是為避免因測試環境和線上環境的差異等帶來的缺陷漏測而設立的一套環境。其 配置等基本和生產環境一致，目的是能讓我們發正式環境時更有把握！所以預發布環境是你的產品質量最后一道防線，因為下一步你的項目就要上線了。要注意預發布環境服務器不在線上集成服務器范圍之內，為單獨的一些機器。
4. 生產環境：是指正式提供對外服務的線上環境，例如我們目前在移動端或 PC 端能訪問到的 APP 都是生產環境。

? 這幾個環境也可以說是系統開發的三個重要階段：開發 -> 測試 -> 上線。一張圖總結：

? 對于規模稍微大點的公司來說，可不止這么幾個環境，比如項目正式上線前還存在仿真/灰度環境，再比如還存在多套測試環境，以滿足不同版本上線前測試的需要。

? 一個項目的開始從設計開始，而 一個項目的成功則從測試開始。?套良好的測試體系可以將系統中絕大部分的致命 Bug 解決在系統上線之前。測試系統的完善和成熟也是衡量以個軟件企業整體水平的重要指標之以，測試往往被忽視，因為它對可以的隱性、對軟件開發企業不產生直接的效益，但是它卻是軟件質量的最終保障，乃至項目能否成功的重要因素！

Ⅲ. Git 分支設計規范

? 環境有了概念后，那么對于開發人員來說，一般會針對不同的環境來設計分支，例如：

分支	名稱	適用環境
master	主分支	生產環境
release	預發布分支	預發布/測試環境
develop	開發環境	開發環境
feature	需求開發分支	本地
hotfix	緊急修復分支	本地

? 注：以上表格中的分支和環境的搭配僅是常用的一種，可視情況而定不同的策略。

master分支

• master 為主分支，該分支為 只讀且唯一分支。用于部署到正式發布環境，一般由合并 release 分支得到
• 主分支作為穩定的唯一代碼庫，任何情況下不允許直接在 master 分支上修改代碼
• 產品的功能全部實現后，最終在 master 分支對外發布，另外所有在 master 分支的推送應該打標簽（tag）做記錄，方便追溯
• master 分支不可刪除

release分支

• release 為預發布分支，基于本次上線所有的 feature 分支合并到 develop 分支之后，基于 develop 分支創建。可以部署到測試或預發布集群。
• 命名以 release/ 開頭，建議的命名規則：release/version_publishtime 。
• release 分支主要用于提交給測試人員進行功能測試。發布提測階段，會以 release 分支代碼為基準進行提測。
• 如果在 release 分支測試出問題，需要回歸驗證 develop 分支看否存在此問題。
• release 分支**屬于臨時分?**，產品上線后可選刪除

develop分支

• develop 為開發分支，基于 master 分支創建的只讀且唯一分支，始終保持最新完成以及 bug 修復后的代碼。可部署到開發環境對應集群。
• 可根據需求大小程度確定是由 feature 分支合并，還是直接在上面開發（非常不建議）

feature分支

• feature 分支 通常為新功能或新特性開發分支，以 develop 分支為基礎創建 feature 分支
• 命名以 feature/ 開頭，建議的命名規則： feature/user_createtime_feature
• 新特性或新功能開發完成后，開發人員需合到 develop 分支
• 一旦該需求發布上線，便將其刪除

hotfix分支

• hotfix 分支為 線上 bug 修復分支或叫補丁分支，主要用于對線上的版本進行 bug 修復。當線上出現緊急問題需要馬上修復時，需要基于 master 分支創建 hotfix 分支
• 命名以 hotfix/ 開頭，建議的命名規則：hotfix/user_createtime_hotfix
• 當問題修復完成后，需要合并到 master 分支和 develop 分支并推送遠程。一旦修復上線，便將其刪除
  

? 其實，以上講的是企業級常用的?種 Git 分支設計規范：Git Flow 模型。但要說的是，該模型并不是適用于所有的團隊、所有的環境和所有的文化。如果你采用了持續交付，你會想要一些能夠盡可能簡化交付過程的東西。有些人喜歡基于主干的開發模式，喜歡使用特性標志。然而，從測試的角度來看，這些反而會把他嚇一跳。

? 關鍵在于站在你的團隊或項目的角度思考：這種分支模型可以幫助你們解決哪些問題？它會帶來哪些問題？這種模式為哪種開發提供更好的支持？你們想要鼓勵這種行為嗎？你選擇的分支模型最終都是為了讓人們更容易地進行軟件協作開發。因此，分支模型需要考慮到使用者的需求，而不是盲目聽信某些所謂的“成功的分支模型”。

? 所以 對于不同公司，規范是會有些許差異，但萬變不離其宗，是為了效率與穩定。