git flow 流程例項**
分支命名規範
git flow是構建在git之上的乙個組織軟體開發活動的模型，是在git之上構建的一項軟體開發最佳實踐。
核心分支是指master和dev分支：
主分支(master)：
開發主分支(develop)：
臨時分支是指 feature、release、hotfix分支，這三種分支都屬於臨時性需要，使用完以後，應該刪除，使得**庫的常設分支始終只有master和develop。
功能(feature)分支：
這個分支主要是用來開發乙個新的功能，一旦開發完成，我們合併回develop分支進入下乙個release。
預發布(release)分支：
當你需要乙個發布乙個新release的時候，我們基於develop分支建立乙個release分支，完成release後，我們合併到master和develop分支。
修補bug(hotfix)分支：
當我們在production發現新的bug時候，我們需要建立乙個hotfix, 完成hotfix後，我們合併回master和develop分支，所以hotfix的改動會進入下乙個release。
這三種分支都屬於臨時性需要，使用完以後，應該刪除，使得**庫的常設分支始終只有master和develop。
1. 建立develop分支
// 從master拉出develop分支
git pull origin master //可選，獲取最新版本
git checkout -b develop master
// 發布develop分支
git push -u origin develop
// 從develop拉出feature_v2.0功能分支
git pull origin develop //可選，獲取最新版本
git checkout -b feature_v2.0 develop
// 發布feature_v1.1分支
git push -u origin feature_v2.0
// develop分支獲取最新
git pull origin develop
// 切換到develop分支
git checkout develop
// 從feature分支合併到develop分支
git merge --no-ff feature_v2.0
// 刪除feature分支，也可以不刪除
git branch -d feature_v2.0
從develop拉出乙個release分支
git pull origin develop //可選，獲取最新版本
git checkout -b release_v2.0 develop
// 合併到master
git checkout master
git merge --no-ff release_v2.0
// 在master打tag標記
git tag release2.0 master
git push --tags
// 合併到develop
git checkout develop
git merge --no-ff release_v2.0
從主線master拉出乙個hotfix分支
git pull origin master //可選，獲取最新版本
git checkout -b hotfix_v2.0.1 master
// 合併hotfix_v2.0.1到master
git checkout master
git merge --no-ff hotfix_v2.0.1
// 在master打上tag
git tag hotfix2.0.1 master
git push --tags
// 合併hotfix_v2.0.1到develop
git checkout develop
git merge --no-ff hotfix_v2.0.1
Git Flow分支管理
也就是我們經常使用的master分支，這個分支最近發布到生產環境的 最近發布的release，這個分支只能從其他分支合併，不能在這個分支直接修改。當我們在production發現新的bug時候，我們需要建立乙個hotfix,完成hotfix後，我們合併回master和develop分支，所以hotf...
Gitflow分支管理策略
gitflow存在兩個記錄專案歷史的分支 develop分支將包含專案的完整歷史記錄，而master將包含簡化版本。現在，其他開發人員應該轉殖 儲存庫，並為develop建立跟蹤分支。基於master分支建立develop分支。每個新功能應駐留在其自己的 特性 分支中，可以將其推送到 儲存庫以進行備...
大廠git分支管理規範 gitflow規範指南
目錄3.git flow 各分支操作原理示意 4.git flow 命令示例 在使用 git 的過程中如果沒有清晰流程和規劃，否則,每個人都提交一堆雜亂無章的 commit,項 目很快就會變得難以協調和維護。git 版本管理同樣需要乙個清晰的流程和規範，vincent driessen 為了解決這個...