目錄3. git flow 各分支操作原理示意
4. git flow 命令示例
在使用 git 的過程中如果沒有清晰流程和規劃，否則,每個人都提交一堆雜亂無章的 commit,項
目很快就會變得難以協調和維護。
git 版本管理同樣需要乙個清晰的流程和規範，vincent driessen 為了解決這個問題提出了 a
successful git branching model
以下是基於 vincent driessen 提出的 git flow 流程圖：
也就是我們經常使用的 master 分支，這個分支最近發布到生產環境的**，最近發布的
release， 這個分支只能從其他分支合併，不能在這個分支直接修改。
這個分支是我們是我們的主開發分支，包含所有要發布到下乙個 release 的**，這個主要合
並與其他分支，比如 feature 分支。
這個分支主要是用來開發乙個新的功能，一旦開發完成，我們合併回 develop 分支進入下乙個
release。
當你需要乙個發布乙個新 release 的時候，我們基於 develop 分支建立乙個 release 分支，完
成 release 後，我們合併到 master 和 develop 分支。
當我們在 production 發現新的 bug 時候，我們需要建立乙個 hotfix, 完成 hotfix 後，我們合
並回 master 和 develop 分支，所以 hotfix 的改動會進入下乙個 release。
所有在 master 分支上的 commit 應該打上 tag，一般情況下 master 不存在 commit，develop 分
支基於 master 分支建立。
feature 分支做完後，必須合併回 develop 分支, 合併完分支後一般會刪點這個 feature 分支，
畢竟保留下來意義也不大。
release 分支基於 develop 分支建立，打完 release 分支之後，我們可以在這個 release 分支
上測試，修改 bug 等。同時，其它開發人員可以基於 develop 分支新建 feature (記住：一旦打了
release 分支之後不要從 develop 分支上合併新的改動到 release 分支)發布 release 分支時，合併
release 到 master 和 develop， 同時在 master 分支上打個 tag 記住 release 版本號，然後可以刪
除 release 分支了。
hotfix 分支基於 master 分支建立，開發完後需要合併回 master 和 develop 分支，同時在
master 上打乙個 tag。
git分支管理規範
以下特點是有部分是假設性，部分是實際的 這裡的約束是指無論哪一種場景，以及開發規模大小都必須要遵守的一些git分支管理規則 只需要乙個master分支，然後各自建立自己的分支名為 dev 拼音簡寫 feature fixbug 名稱 如 dev zhang3 userreg,雙發約定好評審方式和me...
git分支管理規範
主分支 master 開發分支 develop 功能分支 feature 修復分支 hotfix 預發布分支 release master 主分支，建立 repository 時缺省會生成乙個 master 分支。通常情況下 master 分支是受保護的 protected master 分支儲存的...
Git分支管理規範
關於git的一些分支管理規範。一 分支與角色說明 git 分支型別 master 分支 主分支 穩定版本 develop 分支 開發分支 最新版本 release 分支 發布分支 發布新版本 hotfix 分支 熱修復分支 修復線上bug feature 分支 特性分支 實現新特性 gitlab 角...