Gitlab 開發規範

git 是目前最流行的源**管理工具。 為規範開發，保持**提交記錄以及 git 分支結構清晰，方便後續維護，現規範 git 的相關操作。

master 分支  （主分支、穩定分支，不能直接修改**）

develop 分支  （開發分支）

feature 分支     （開發分支，多個功能模組並行開發時）

release分支      （提測時建立，修復測試階段bug）

hotfix 分支        （線上緊急修復bug）

從時間軸維度看各個分支使用：

在乙個團隊協作的專案中，開發人員需要經常提交一些**去修復bug或者實現新的feature。而專案中的檔案和實現什麼功能、解決什麼問題都會漸漸淡忘，最後需要浪費時間去閱讀**。

但是好的日誌規範commit messages編寫有幫助到我們，它也反映了乙個開發人員是否是良好的協作者。

目前，社群有多種 commit message 的寫法規範。來自angular 規範是目前使用最廣的寫法，比較合理和系統化。如下圖：

當前業界應用的比較廣泛的是 angular git commit guidelines

具體格式為:

(): 《空行》

《空行》

type 

scope

這個取值可以是空，通常用於指明修改內容的範圍。

subject

用於概括一次提交行為囊括的內容

body部分

日誌的內容主體 body 用來描述詳細的提交內容，可寫可不寫。

footer 部分

日誌的內容頁尾 footer 用來描述一些補充資訊，可寫可不寫。

樣例如下：

版本號一般由字母v和數字 1-9 和 . 組成，不應包含多餘的資訊，正確的命名：v1.0.2；

版本號預設分為三個段位，如 v1.2.3 。如果是 fork 的專案，版本號應在上游版本的基礎上在後面增加乙個子段位；

版本號的長度應前後保持一致，必要時做補零處理，如應使用 v1.0.0 而不是 v1.0；

如有必要，可以在版本號後面加破折號 - 新增更多描述資訊，如 v2.3.0-rc。

版本號預設分為三個段位，為方便說明，從左至右分別稱之為大版本號，中版本號和小版本號，其變更規則如下：

大版本號一般不做變化，除非整個專案系統架構或實現方式做重大調整，或者應專案經理的要求對版號提公升；

中版本號的提公升意味著將要發布乙個新的穩定版本，一般會對功能介面或介面做大量調整。對於受專案經理監管的專案，版本號的提公升要經過專案經理的許可；

小版本號的變更相對靈活，由開發者自主控制。但如果有重要 bug 被修復，版本號一定要跟進；

版本過渡時，若**變更較大，包括增加新特性和對介面進行調整，一般會預先發布 alpha ，beta ，rc等測試版，此時應先在低段位新增乙個大的版本號進行過渡，如 0.2.0 -> 0.90.0 -> 1.0.0，1.0.0 ->1.90.0 -> 2.0.0。

stable版：穩定版。在開源軟體中，都有stable版，這個就是開源軟體的最終發行版，使用者可以放心大膽的用了。

穩定版本的發布採用類似v1.0.0格式；

過渡版本的發布採用類似v1.0.1-rc1格式；

示例：

gitlab開發流程

gitlab加入mr 1 刪除本地所有 git remote rm origin 2 fork remote到本地倉庫 git clone 本地倉庫鏈結 3 重新命名自己的倉庫為local git remote rename origin local 4 加入遠端倉庫的origin git remo...

github開發流程（gitlab）

開發步驟 1 新建資料夾，在資料夾裡面，開啟git，執行轉殖操作 git clone xx 這裡輸入分支鏈結位址，一般在gitlab上面可以直接複製 2 根據需求建立分支 git checkout b x 這樣會自動切到該新分支下面，然後就可以開發了 3 切換分支 git checkout x 4 ...

gitlab多人協作開發

gitlab多人協同工作 本文為亨利向 git權威指南 的作者蔣鑫老師的答疑郵件寫成。這裡特別感謝蔣鑫老師對我詢問gitlab的協同工作流程問題的詳細解答。蔣鑫老師的細緻專業的解答讓我非常感動。gitlab 新穎的git伺服器託管 開源免費。你可以在自己的公司或者開發團隊搭建好乙個。gitlab的工...