以下特點是有部分是假設性，部分是實際的：
這裡的約束是指無論哪一種場景，以及開發規模大小都必須要遵守的一些git分支管理規則：
只需要乙個master分支，然後各自建立自己的分支名為：dev-拼音簡寫-feature（fixbug）名稱 ,如: dev-zhang3-userreg,雙發約定好評審方式和merge規則就好，然後在開發完成後merge and push 到主分支即可。理論上建議開發好的**不要直接合併到master分支，而是應該先合併到dev分支，自測通過後，再合併到master,確保master分支每次改動都伴隨一次發布操作，這樣線上**就可以和master分支永遠保持一致了。這一點只是建議。
這種適合採用複雜分支管理策略，具體需要建立如下分支：
分支劃分如下：
master：與線上版本保持絕對一致；
develop：開發分支，由下文提到的release、feature、hotfix分支合併過後的**；
feature：實際功能點開發分支，建議每個功能新建乙個feature， 具有關聯關係的功能公用乙個feature分支；（如果不存在多個需求功能同時開發，即，每次開發只由乙個單一的需求，那麼該分支可以不需要出現，而是直接再develop分支上checkout出來開發就好。如果覺得該分支管理複雜，建議不要引入這個概念。）
release：每一次開發完成之後，從develop建立出來的分支，以此分支為基準，進行測試；（該分支可以不需要，直接將develop分支部署到測試伺服器上測試）
hotfix：該分支主要用於修復線上bug；（該分支可以從master,develop,feature等任意分支checkout出來，並快速修復bug後合併回去源分支）
commit的注釋不能不填，建議簡單扼要的描述別人能看得懂的注釋即可。
原則上應該勤勞的刪除不必要的分支，以免保留奇奇怪怪的分支給同事造成困擾。
避免在合併**評審時造成困擾，建議開發前調整好**編輯器的換行符，建議統一為linux標準的換行符即lf（而不是crlf,也不是cr）。
總體上來說，master分支和develop分支是相對來說比較有必要存在的，可以應付80%的開發場景。也是我比較推崇的，其他概念按需要靈活和開發小組自行約定就好。
不要執行你不懂的git命令
git分支管理規範
主分支 master 開發分支 develop 功能分支 feature 修復分支 hotfix 預發布分支 release master 主分支，建立 repository 時缺省會生成乙個 master 分支。通常情況下 master 分支是受保護的 protected master 分支儲存的...
Git分支管理規範
關於git的一些分支管理規範。一 分支與角色說明 git 分支型別 master 分支 主分支 穩定版本 develop 分支 開發分支 最新版本 release 分支 發布分支 發布新版本 hotfix 分支 熱修復分支 修復線上bug feature 分支 特性分支 實現新特性 gitlab 角...
專案Git分支管理規範
git 是乙個開源的分布式版本控制系統，用於敏捷高效地處理任何或小或大的專案。專案中，一般會建立三個常用分支 日常開發中，一般會建立兩類分支 從develop分支切出乙個新分支，根據是功能還是bug，命名為feature 或 fixbug 開發者完成開發，提交分支到遠端倉庫。開發者發起merge請求...