一. 項目版本規范(或API組件開發) 項目的版本號推薦使用語義化版本規范([https://semver.org/lang/zh-CN/](https://semver.org/lang/zh-CN/)), 其基本規則如下: 版本號定義:**..;**比如 1.0.0，采用 X.Y.Z的格式規范，且X, Y 和 Z 為非負的整數。 其中 X 為主版本號, Y 為 次版本號, Z 為修訂版本號。 **升級原則:** **1) 主版本號：**功能模塊有大的變動時，比如API兼容性做了修改或整個架構發生了變化。 版本號需要遞增, 次版本號和修訂版本號必須歸零，比如 1.1.5這個版本，現在組件的API兼容性發生改變或整個項目結構發生改變，那么主版本號需要遞增，因此這個時候版本號變成為 2.0.0; **2) 次版本號:**當模塊或組件增加新功能時 或 一些公用的API功能被棄用的時候，也需要遞增。 每次次版本號遞增時，修訂號必須歸零。比如 1.1.5 版本，現在模塊或組件增加新功能時，那么次版本號需要遞增。因此現在的版本變成了 1.2.0; **3) 修訂號:**當功能模塊或組件的bug修復, 或功能擴充等。 修訂使指項目中的bug修復，那么版本號需要遞增。比如 1.1.5 版本，現在bug修復好了，那么現在的版本變為 1.1.6了。 [回到頂部](https://www.cnblogs.com/tugenhua0707/p/11921027.html#_labelTop) 二：版本控制系統規范(GitFlow) **GitFlow概念:**GitFlow是使用一個中央代碼倉庫，它是所有開發者的信息交流中心。它和其他工作流程一樣，開發者在本地開發完成，然后將分支代碼推送到中央倉庫。不同點在于項目中的分支結構。 可以參考:([https://nvie.com/posts/a-successful-git-branching-model/](https://nvie.com/posts/a-successful-git-branching-model/)) 使用GitFlow, 在項目中會存在兩個長期分支，主分支(master) 和 開發分支(develop)。 **主分支(master):**該主分支代碼用于對外發布的代碼(一般指線上已經發布的)。 **開發分支(develop):**用于日常開發。該分支是基于master分支克隆的, 編碼工作在該分支上進行。 **功能分支(feature):**該分支是基于develop分支克隆的。該分支的作用主要用于一些新功能的開發,功能開發完畢后需要合并到develop分支。 feature分支可以有多個，它是屬于臨時分支，當某個功能實現后可以刪除該分支。 **測試分支(release):?**它是基于develop分支克隆的，產品編碼工作完成后，需要把測試分支代碼發布到測試環境中，如果在測試環境中發現了一些小bug，那么就直接在該分支上進行修復操作。等測試所有完成后，我們需要把該分支代碼合并(merge)到develop分支上。 該分支也屬于臨時分支, 當功能實現后也可以刪除該分支。 **Bug修復分支(bugfix):**? 該分支是基于master分支或Tag標簽進行克隆的。作用主要用于修復對外發布的分支。修復完畢后，需要分別合并到develop分支和master分支上。本分支也屬于臨時分支，功能完成后也可以刪除該分支。 **基本步驟如下:** 1\. 從遠程倉庫克隆代碼到本地倉庫，基本命令比如如下: ~~~ git clone https://github.com/tugenhua0707/gitflow-test.git ~~~ 2\. 在master分支上，創建develop分支，基本命令如下: [](javascript:void(0); "復制代碼") ~~~ // 切換到master分支上 $ git checkout master // 基于master分支克隆develop分支，并且切換到develop分支上 $ git checkout -b develop // 推送develop分支到遠程倉庫 $ git push origin develop ~~~ [](javascript:void(0); "復制代碼") 3\. 在develop分支本地倉庫基本流程 當某個功能點開發完成后，我們需要將代碼提交到本地倉庫。 [](javascript:void(0); "復制代碼") ~~~ // 提交到緩沖區 $ git add . // 提交修改到本地倉庫 /* 如果是修復BUG的話，則注釋可以為: "Bug 修改說明" 如果是完成了某一個功能的話，則注釋可以為: "Task 修改說明" */ $ git commit -m "Bug 修改說明" ~~~ [](javascript:void(0); "復制代碼") 4\. 推送代碼到遠程倉庫 當我們完成一個功能點或階段工作時，需要將代碼推送到遠程倉庫develop分支上。 ~~~ // 先拉取最新代碼, 防止代碼沖突 $ git pull // 解決代碼沖突后/或代碼沒有沖突的話, 我們需要將develop分支代碼推送到遠程倉庫中 $ git push origin develop ~~~ 5\. 功能分支(feature) 此時此刻，我們項目中某一個模塊需要添加一個新功能，我們可以在develop分支上克隆一份代碼來, 然后進行對應某個功能開發。當然在團隊 合作中，我們可以創建多個功能分支。比如叫 feature1，feature2，依次類推來命名.... [](javascript:void(0); "復制代碼") ~~~ // 從develop分支中克隆一份代碼下來，且切換到對應的 feature1 功能分支上。 $ git checkout -b feature1 develop // .... 然后進行開發，開發完成后提交代碼到遠程倉庫 // 功能開發完成后，我們需要把該功能分支再合并到我們的develop分支上, 切換到develop分支上來，然后進行如何合并命令 $ git merge feature1 // 合并完成后該分支，我們可以把該功能分支刪除 // 刪除本地分支 $ git branch -d feature1 // 刪除遠程分支 $ git push origin --delete feature1 ~~~ [](javascript:void(0); "復制代碼") 6\. 將代碼發布到測試分支(release) 如上在develop分支上代碼開發完成后，我們需要提測到測試環境中，因此我們需要將代碼發布到測試分支release。 執行基本命令如下: [](javascript:void(0); "復制代碼") ~~~ // 切換到develop分支上來 $ git checkout develop // 創建并切換到release分支來 $ git checkout -b release // 推送到遠程倉庫中 $ git push origin release ~~~ [](javascript:void(0); "復制代碼") // ..... 在測試中有bug時，直接在該測試分支(release)中修改。 測試完成后，需要將 測試分支(release) 代碼合并到develop分支中。 ~~~ // 切換到develop分支上 $ git checkout develop // 執行合并操作, 將release分支代碼合并到develop分支上(如果有沖突，需要解決沖突，再合并) $ git merge release ~~~ 當開發和測試代碼都沒有問題的時候，需要將代碼發布到線上后，此時需要把develop分支代碼合并到master上。 ~~~ // 先切換到master分支 $ git checkout master // 合并develop分支代碼 $ git merge develop ~~~ 7\. 線上發布完代碼后，需要打開Tag(里程碑Tag包) ~~~ // 創建里程碑Tag $ git tag -m "Task v1.0.0發布" v1.0.0 // 推送里程碑Tag到遠程庫 $ git push origin v1.0.0 ~~~ 8\. 發布完成后，線上Bug修復工作流 1) 獲取到Bug產品的軟件發布的版本號 2) 基于里程碑Tag創建分支: ~~~ // git checkout -b [創建的分支名稱] [里程碑Tag的名稱] $ git checkout -b bugfix-v1.0.0 v1.0.0 // 就會創建一個 bugfix-v1.0.0 分支，然后進行修改. ~~~ 3）修復代碼完成后可以使用如下命令查詢修改過的地方 ~~~ $ git diff ~~~ 4) 修改完成后分別合并到develop分支和master分支上 [](javascript:void(0); "復制代碼") ~~~ /* 合并到develop分支 */ $ git checkout develop $ git merge bugfix-v1.0.0 // 提交到遠程倉庫develop分支下 $ git push origin develop /* 合并到master分支下 */ $ git checkout master $ git merge develop // 提交到遠程倉庫master分支下 $ git push origin master ~~~ [](javascript:void(0); "復制代碼") 5) 創建新的里程碑Tag ~~~ $ git checkout master $ git tag -m "Bug 修復某某bug" v1.0.1 // 推送到遠程倉庫中 $ git push origin v1.0.1 ~~~ [回到頂部](https://www.cnblogs.com/tugenhua0707/p/11921027.html#_labelTop) 三：github Issue 任務管理 github Issue是目前相對來說比較流行的任務管理工具，它可以幫助我們了解項目的進度、資源的分配情況。 在團隊協作中，每個issue可以代表一個任務，我們的每一項任務可以創建一個Issue，Issue的完成后由自己關閉掉。 每個Issue應該包含問題的標題和描述信息，使后來的人一看標題和描述就可以知道該issue是那個項目下的，該項目會有那些基本功能點。 **3.1 基本用法** 在我們的Github代碼倉庫中都有一個Issues面板，如下圖所示:  1）在如上所示的 Filters 中，我們可以對分類進行過濾查詢。方便管理所有的類目。 2）在如上所示的 Labels中，Issue可以貼上標簽，有利于分類管理和過濾查看，默認有9個標簽。我們可以對9個默認標簽進行修改或刪除操作，我們有可以新建自己的標簽，如下圖所示:  對于一些稍微大一點的項目，每個Issue至少應該有兩個Label, 一個表示性質, 另一個表示優先級的。 表示優先級的Label，可以參考下面的級別: **高優先級(High)：**表示對系統有重大影響，只有解決它之后，才能完成其他任務。 **普通優先級(Medium):**對系統的某個部分有影響, 用戶的某一部分操作會達不到預期的效果。 **低優先級(Low):**對系統的某個部分有影響，用戶幾乎感知不到。 **微不足道(Trivial):**對系統功能沒有影響，一般是視覺效果等，比如字體或顏色不滿意。 添加如上標簽后，如下圖所示:  3) 在如上的 Milestones 中，它叫做里程碑，用作Issue的容器，相關的Issue可以放在一個 Milestone 里面。 我們可以新建一個 Milestone, 在Issues面板的首頁，點擊Milestones按鈕。然后我們再接著點擊 New milestone 按鈕，然后填寫 Milestone的名稱和內容，可以指定到日期時間，如下圖所示:  在如上設置完成后，我們就可以創建一個Issue了，進入Issue面板，點擊新建 "New Issue" 按鈕。就會進入新建Issue頁面，如下圖所示：  如上就是新建Issue界面，左側是填入Issue的標題和內容，右側是四個配置項。我們分別來看下右側四個配置項的具體含義: **Assignees:**人員 **Labels:**標簽 **Projects:**項目 **Milestone:**里程碑 **Assignee** Assignee 選擇框用于從當前倉庫的所有成員之中，指派該Issue給某個人，目前我這邊只有我自己，如下所示:  如上我們只要選擇一個人即可。 **Labels** Issue 可以貼上標簽，這樣有利分類和過濾查看，如下是我剛剛新建的所有標簽，如下圖所示:  新建完成后，可以變成如下看到，如下圖所示:  Projects： 指具體的那個項目，我這邊目前，可以為空，不填吧。 **Milestone:**指里程碑，也就是可以理解為該項目什么時候完成的。如下圖所示:  如上就是我們剛剛新建的日期時間。 新建一個Issue如下所示:  然后效果就變成如下所示:  最后填寫完成后，我們點擊最右側下面的 "Submit new issue" 按鈕，即可提交，然后我們就可以在Issue面板中可以看到我們的issue列表信息了，如下圖所示:  當我們的這個項目有任何功能點已經完成了，或者狀態發生改變了，或者上線了(如果上線了，我們需要關閉該項目)。我們需要自己手動去改變該項目的狀態，如下圖所示，進入該項目的目錄下進行更改狀態:  如上該上面完成及上線后，我們需要關閉該issue，因此我們可以點擊該issue的詳情頁，點擊最底部的 close issue 按鈕，如下圖所示:  如上就是github中的issue在團隊協作中項目管理的基本操作了。