git工作流你可以理解為工作中團隊成員遵守的一種**管理方案，在git中有以下幾種工作流方案作為方案指導：
gitflow工作流
這個工作流其實也是我們團隊採用的工作流，這也是很多團隊會採用的工作流，它會相對複雜一點，但它非常適合用來管理大型專案的發布和維護，後面筆者也會詳細講下這一塊。貫穿整個開發周期，master和develop分支是一直存在的，master分支可以被視為穩定的分支，而develop分支是相對穩定的分支，特性開發會在feature分支上進行，發布會在release分支上進行，而bug修復則會在hotfix分支上進行。筆者也是花了不少時間才熟練掌握整個工作流，期間遇到不少坑，後面會跟大家分享下。
主分支保持穩定
不允許直接往這個分支提交**，只允許往這個分支發起merge request
只允許release分支和hotfix分支進行合流
開發分支
相對穩定的分支
用於日常開發，包括**優化、功能性開發
從develop分支拉取，用於下個迭代版本的功能特性開發
功能開發完畢合併到develop分支
release分支
從develop分支拉取
用於回歸測試，bug修復
發布完成後打tag並合入master和develop
hotfix分支
熱更新分支
從develop分支拉取
用於緊急修復上線版本的問題
修復後打tag並合入master和develop
大家可能會發現我們這個跟標準的gitflow工作流有些差別，其實也沒有什麼標準不標準的，前面說到要結合團隊的實際情況，我們團隊對於目前所採用的工作方式都是達成共識的，所以有一些差異並沒有關係。
1). 首先將遠端**拉取到本地
git clone ***
git checkout -b develop origin/develop
2).新建feature分支
git checkout -b feature
3).多人在feature上開發，如果中途需要將develop的變更合入feature，所有人需要將本地的**變更提交到遠端
git fetch origin
git rebase origin/feature
git push origin feature
然後由feature負責人rebase develop分支，刪除原來feature分支，重新新建feature分支；
git fetch origin
git rebase origin/feature
git rebase develop
git push origin :feature
git push origin feature
這樣可以保證feature保持線性變更；
4).feature開發完成後，所有人需要將本地的**變更提交到遠端
git fetch origin
git rebase origin/feature
git push origin feature
然後由feature負責人rebase develop分支，然後將feature分支合入develop，刪除feature；
git fetch origin
git rebase origin/feature
git rebase develop
git checkout develop
git merge feature
git push origin :feature
這樣可以保證develop保持線性變更，各feature的變更完整可追溯；
5).合入feature後拉出對應的release/feature分支，後續bug修復在release/feature上
git checkout develop
git checkout -b release/feature
release/feature分支的同步合併與feature分支相同
6).release/feature分支bug修復完成後，拉取對應的tag推送遠端進行發布
git tag -a v1.0 -m 'feature發布'
git push origin v1.0
之後將release/feature合入develop分支，然後刪除
git rebase develop
git checkout develop
git merge release/feature
git push origin :release/feature
7).發布完成後將release合入master分支，保證master為最新穩定版本（實際操作為發起merge request）
大型專案相對於中型專案又多了release版本。這個版本的作用只要是控制需求的更新以及當前版本bug的fix處理。
對於這種情景sourcetree自帶git-flow的功能
並且給出各種引導提示
和中型專案相比，hotfix分支在大型專案中只處理線上的bug問題。對於需求的控制，都會發生在release分支中。乙個release版本的生成並不意味著它可以直接提交master，qa的介入在中小型專案中屬於master分支，
但是在這個流程下，qa的介入屬於release分支，包括對於bug的修復操作也是直接在release版本完成。當qa對於release版本確認完成後，release版本merge到master預上線並且merge回develop保持**一致性。
git 工作流的一些經驗分享
【過程改進】總結大中小型專案的git流程
Git 工作流程
git 作為乙個原始碼管理系統，不可避免涉及到多人協作。協作必須有乙個規範的工作流程，讓大家有效地合作，使得專案井井有條地發展下去。工作流程 在英語裡，叫做 workflow 或者 flow 原意是水流，比喻專案像水流那樣，順暢 自然地向前流動，不會發生衝擊 對撞 甚至漩渦。本文介紹三種廣泛使用的工...
Git 工作流程
git 作為乙個原始碼管理系統，不可避免涉及到多人協作。協作必須有乙個規範的工作流程，讓大家有效地合作，使得專案井井有條地發展下去。工作流程 在英語裡，叫做 workflow 或者 flow 原意是水流，比喻專案像水流那樣，順暢 自然地向前流動，不會發生衝擊 對撞 甚至漩渦。本文的三種工作流程，有乙...
Git工作流程
在伺服器上有2個主要分支，master和develop 本地分支基本和遠端一樣，但是開發的時候，需要你在本地建立其他分支，最後等功能開發完成後，merge到你需要的分支上，然後刪除那個臨時的分支。這樣完成開發。專案者首先在gitlab建立2個分支，預設乙個master，並將master設定為保護，只...