gitlab進行協作以及issue的使用說明

gitlab 是乙個類似於 github 的開源原始碼託管服務，它除了提供基於 git 的基本**託管服務外。還具備很多與軟體開發協作相關的其他功能。比如 issues、merge requests 等。

利用 gitlab 提供的這些功能，我們可以實踐一些簡單的專案管理和協作流程。這套流程借鑑於很多成功的開源專案，非常適合在小型開發團隊裡面使用。

gitlab issues 類似於「工單系統」，是乙個發布專案相關資訊的地方。專案的所有成員都可以建立新的 issue，其他成員可以在 issue 下進行相關的討論。

issues 本身是乙個非常簡單的功能，但是如果配合「標籤」、「里程碑」等功能一起使用，就可以承擔起一定的專案管理工作。

在專案的開發過程中，我們會碰到很多新的需求、軟體 bug 等。這些需求與 bug ，就是 issue 最大的**，它們都可以作為 issue 錄入到專案的 issues 中。

因為 issue 的錄入門檻很低，鼓勵專案成員錄入 issue 後，專案很容易就會出現大量的 issues。所以我們應該嚴格控制每個 issue 的內容質量，確保其他人可以通過這個 issue 獲取足夠多的資訊，提高溝通效率。

不光是和需求和 bug，任何和專案有關的內容都可以錄入到 issue 中。

編寫優秀的「需求」 issue

如果你要錄入乙個需求類的 issue，最好在內容主體中包含下面這些內容：

編寫優秀的「bug」 issue

如果你要錄入乙個 bug issue，最好在內容主體中包含下面這些內容：

當 issue 被建立後，應該等待專案的 owner （owner 指專案的所有者，是對專案各方面都比較了解的人，可以為多個人）對 issue 進行 review。

review 時，如果 owner 覺得這個 issue 滿足下面的任意條件：

「標籤」是 issue 的核心特性，為了更好的使用它，我建議採用"/"這樣的二維標籤來取代傳統的""單維標籤，下面是一些常用的 issue 標籤：

優先順序：priority

優先順序（priority）是最重要的標籤之一。它直接影響 bug 需要被響應的速度、或需求的具體排期。（經由 @雲掩大椿提醒，已修改為更符合慣例的定義）

型別：kind

kind（類別）表示 issue 屬於哪種型別。

工作量：size

領域/模組：area

area用於標記當前 issue 屬於專案中的什麼領域/模組。這個分類下的具體標籤由專案本身決定。比如area/apiserver、area/controller等。給 issue 打上 area 標籤後，專案不同模組的相關負責人可以更方便的找到自己負責的相關 issues。

gitlab 的標籤是乙個非常靈活的功能，在具體使用中，不必拘泥於上面列出來的這幾種標籤，可以根據當前專案特點隨意調整。

當 issue 被建立、打上標籤以後，就可以進行後續操作了。issue 的後續操作主要包括下面幾種：

除了為 issue 打上標籤以外，你還可以為 issue 繫結上 milestone（里程碑），來將 issue 與某些特定的專案節點關聯起來。之後便可以在 milestones 頁面檢視每乙個里程碑的進展。

和 labels 一樣，里程碑也是乙個十分靈活的功能，你可以根據專案需要建立不同的里程碑，比如：

使用 issue board（類似於敏捷開發中的「看板」），可以在乙個頁面看到當前處於不同階段的所有 issues。這個功能非常適合站立晨會時使用。

隨著專案越來越大，專案累積的 issue 也會越來越多。而這些 issue 中有很多已經失去它的價值。

所以，為了避免有價值的 issue 淹沒在這些過時的資訊當中，我們應該定期 review 現有的 issues，關閉掉那些已經過時的 issues。

在 gitlab 上建立的專案，所有人都不應該直接往 master 分支推送**。而是應該在其他分支（或者 fork 專案的分支）進行開發。並最終通過建立 merge request（類似 github pull request）將**合併到 master 分支。

基於 mr 的開發流程如下：

我們一般會用類似於dev_piglei這樣的分支名稱進行開發，遵循著「開發」 -> 「push 並建立 mr」 -> 「開發」這樣的工作流程。

但是，因為乙個分支是嚴格對應到乙個 mr 的，當你在同乙個分支上開發不同功能時，如果 mr 一直處於 open 狀態，那這些不同功能都會被推送到同乙個 mr 上，對 review 過程產生困擾。

為了避免這種情況，最好為不同的功能項建立不同的分支並各自建立 mr，比如dev_feature_add_member、dev_feature_disabled_user。

在 git 工作流方面，git-flow workflow 是乙個值得學習的內容

如果開發一些比較大的需求，我們通常會將他們一次實現完，然後作為乙個大的 mr 來提交 review。

但是如果每個 mr 過於複雜，會大大影響 code review 的效率。所以，如果你要實現乙個比較複雜的特性，建議將它拆解為多個比較小的 mr 來依次提交。

但這個 mr 裡面包含了太多內容，會增加 review 的難度。所以可以試著將這個功能拆解為下面三個更小的 mr：

謹記：