1.GIT工作流程
1.1.簡單流程
就是如同我們目前所用，所有人共用一個分支，即不分測試版和正式版，由始至終使用一份代碼，是以，這份代碼的記錄都是在同一分支的。這種操作因為隻有一個分支，那麼分支管理就不需要了。
優點：
- 可以快速上手git
缺點：
- 在進行代碼協作的時候可能會産生一些複雜的沖突，比如多人同時修改同一個檔案，那麼在不斷送出代碼的同時，可能就需要不停的去解決沖突
- 軟體 hotfix 傳遞到正式版的時候風險可能會更高，比如，我目前功能開發到一半或者測試正在測試中的代碼，但是測試未進行測試，今天又需要發版，那正式版的代碼肯定會有問題
- 代碼的可維護性很差，所有人都在同一個分支進行送出，導緻送出記錄會非常混亂，如果commit資訊沒有規範限制的話，那麼這個分支的log會無比龐大，追溯代碼會十分費勁
1.2.Git 功能分支工作流程
在需要進行多人項目協作的時候，Git 功能分支工作流程就很有必要登場了。 設想一個開發者在開發一個新功能的同時，另一個開發者在開發另一個功能，此時，若兩個開發者用同一個分支進行協作，這會産生大量的沖突。
為了解決上述問題，讓兩個開發者都從master分支拉取最新的代碼，切出一個獨立分支，當其中一個人手頭的功能寫完之後，可以自行合并到 master 分支進行釋出，而無需等待另一個功能完成再一起釋出。
這種工作流程的優點是可以愉快的進行代碼寫作而無需擔心會産生一堆的代碼沖突
1.3.帶有開發者分支的功能分支工作流程
這種工作流程是主流的工作流程之一，它有點像是在功能分支外，多增加了一個與 master 分支平級的開發者分支。 在這種工作流程下，master 分支總是代表着正式版的預釋出狀态，開發團隊如果想釋出版本，就會從該分支進行釋出。
develop 分支往往表示下一版産品最新一次傳遞變更的狀态，開發者從 develop 分支切出相應的功能分支，若該功能完成，則合并到 develop 分支進行測試，若無沖突，合并到 master 分支。
這種工作流程的優點是，允許團隊可以持續傳遞新的功能到 develop 分支進行測試，合并到 master 分支進行發版。此外，這也會為我們的團隊降低煩人的代碼維護成本。
1.4.Gitflow 工作流程
gitflow工作流程與前一個工作流程非常相似，不同的是多了兩個分支：release 分支和 hot-fix 分支
4.4.1.hot-fix 分支
hot-fix 分支是唯一一個從 master 分支切出并且合并回 master 的分支，該分支用于修複線上版本的一些 bug。使用這個分支的好處是，可以快速的處理線上的一些問題并釋出出去，而無需經過其他流程或者是等到下次疊代再釋出。
一旦 hot-fix 合并到了 master 分支并且更新出去了，應該合并到 develop 分支和目前 release 分支。這麼做是為了確定從 develop 分支切出新功能分支，能拿到最新的代碼。
4.4.2.release 分支
當所有功能都完成開發，并且合并到 develop 分支沒有産生沖突時，從 develop 分支 fork release 分支。 該分支僅包含與釋出相關的代碼，比如與該版本相關的文檔，bug 修複代碼以及其他的一些跟此次釋出相關的内容。
一旦該分支合并到 master 并且釋出出去了，應該合并回 develop 分支，以確定從 develop 分支切出的新功能分支拿到的是最新代碼。
1.5.我們公司準備用的流程
我們采用1.4和1.5相結合的方式，在master的基礎上多了一些每個人的分支以及三個固定分支develop分支、uat分支和Test分支；
develop分支用于開發夥伴釋出dev環境進行自測以及提測。
Test分支用于測試在test環境進行測試
uat分支用于修複曆史bug，在客戶uat環境進行測試
除此之外每個開發夥伴都有一個自己的開發分支，該分支應該是基于最新版的master分支進行拉取，然後在此分支上進行本次疊代的需求開發
1.5.1.正常疊代需求
開發在每個疊代的開始從最新的master分支建立自己的分支，開發完成之後合并devlop分支然後釋出dev環境進行自測和提測，提測成功後合并test分支交給測試驗證；devlop分支和test分支每個疊代結束要删除重新去master分支建立這兩個分支
1.5.2.修複曆史版本的bug
開發基于tag号進行建立分支，例如目前疊代到版本号3.3.4。此時在3.3.5版本的疊代周期内，但是并沒有釋出，也就是說3.3.5版本不存在。那我們可以去解決3.3.4版本的bug 開發者首先基于3.3.4版本建立分支，然後修改完bug後合并uat分支去客戶uat環境驗證。需要保證的是，uat分支與上述dev、test分支每個疊代結束，下個疊代開始，要同步master代碼