閱讀目錄
一. 項目版本規范(或API組件開發)
項目的版本號推薦使用語義化版本規范(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了。
二：版本控制系統規范(GitFlow)
GitFlow概念: GitFlow是使用一個中央代碼倉庫，它是所有開發者的信息交流中心。它和其他工作流程一樣，開發者在本地開發完成，然后將分支代碼推送到中央倉庫。不同點在於項目中的分支結構。
可以參考:(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分支，基本命令如下:
// 切換到master分支上 $ git checkout master // 基於master分支克隆develop分支，並且切換到develop分支上 $ git checkout -b develop // 推送develop分支到遠程倉庫 $ git push origin develop
3. 在develop分支本地倉庫基本流程
當某個功能點開發完成后，我們需要將代碼提交到本地倉庫。
// 提交到緩沖區 $ git add . // 提交修改到本地倉庫 /* 如果是修復BUG的話，則注釋可以為: "Bug 修改說明" 如果是完成了某一個功能的話，則注釋可以為: "Task 修改說明" */ $ git commit -m "Bug 修改說明"
4. 推送代碼到遠程倉庫
當我們完成一個功能點或階段工作時，需要將代碼推送到遠程倉庫develop分支上。
// 先拉取最新代碼, 防止代碼沖突 $ git pull // 解決代碼沖突后/或代碼沒有沖突的話, 我們需要將develop分支代碼推送到遠程倉庫中 $ git push origin develop
5. 功能分支(feature)
此時此刻，我們項目中某一個模塊需要添加一個新功能，我們可以在develop分支上克隆一份代碼來, 然后進行對應某個功能開發。當然在團隊
合作中，我們可以創建多個功能分支。比如叫 feature1，feature2，依次類推來命名....
// 從develop分支中克隆一份代碼下來，且切換到對應的 feature1 功能分支上。 $ git checkout -b feature1 develop // .... 然后進行開發，開發完成后提交代碼到遠程倉庫 // 功能開發完成后，我們需要把該功能分支再合並到我們的develop分支上, 切換到develop分支上來，然后進行如何合並命令 $ git merge feature1 // 合並完成后該分支，我們可以把該功能分支刪除 // 刪除本地分支 $ git branch -d feature1 // 刪除遠程分支 $ git push origin --delete feature1
6. 將代碼發布到測試分支(release)
如上在develop分支上代碼開發完成后，我們需要提測到測試環境中，因此我們需要將代碼發布到測試分支release。
執行基本命令如下:
// 切換到develop分支上來 $ git checkout develop // 創建並切換到release分支來 $ git checkout -b release // 推送到遠程倉庫中 $ git push origin release
// ..... 在測試中有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分支上
/* 合並到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
5) 創建新的里程碑Tag
$ git checkout master $ git tag -m "Bug 修復某某bug" v1.0.1 // 推送到遠程倉庫中 $ git push origin v1.0.1
三：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在團隊協作中項目管理的基本操作了。
待續更新中........