作為一個開發者，多人協作，共同開發維護一個項目是很平常的事情。而git作為現下，比較主流的代碼管理倉庫，想必絕大多數人都應該會使用。
但是在實際應用過程中，會面臨很多的，各種各樣的麻煩事情。特别是，多人協作，長期性項目。很多人或者很多團隊，對項目代碼倉庫的管理非常的混亂，沒有一個固定章法，團隊中的成員，各自有各自的玩法。導緻了常常出現，代碼沖突，代碼被覆寫等突發情況。
我所在的項目組，從零到有。從開始的混亂，到慢慢的規範，我完整的經曆了整個過程。加上，需求混亂，版本疊代周期短，頻率高，對于整個工作流程要求頗高。我也完整的體會了一下，流程混亂的痛苦，和流程規範的重要性。在此大緻的做個總結，希望對大家，有所幫助。如果有什麼說的不對的地方，也請大家指正，謝謝。
首先，介紹一下我們的工作流程，大緻分為以下幾個分支：
大緻說明一下，各個分支的作用：
- 測試環境分支：對應測試環境，用于開發人員，内部調試，以及測試人員初次測試，更新頻繁，代碼最新，功能最全，最不穩定。這個分支應該是隻接受，從别的分支合并到該分支上，而不應該将這個分支，合并到别的任何分支。它應該是一個黑盒子，隻進不出！
- 預釋出環境分支：對應預釋出環境，測試人員完成初次測試後，将會把即将要上線（釋出正式環境），的功能代碼推到該分支，産品将會對，需要上線的需求進行驗收。該分支，相對穩定，最貼近生産。這個分支應該是隻接受，從别的分支合并到該分支上，而不應該将這個分支，合并到别的任何分支。它應該是一個黑盒子，隻進不出！
- 生産環境分支：生産的代碼（也就是正線上上跑的），分布正式環境時應當使用該分支，當正式代碼，運作一段時間後，确定沒有問題後，再把這個分支，推倒master。
- master：主分支，基本上和生産環境分支保持一緻，該分支不應該做任何認為的操作，隻當生産分支，穩定後将其合并過來。
- bug分支：修複bug時，一個bug對應新開的一個分支。這裡非常建議這種做法，一個bug一個分支，優點在于，改好一個就可以上線一個，不會影響到别的功能，非常靈活。
- 版本1分支…版本n分支：正在開發的版本，可能是多個版本并行，這是非常常見的事情。個人建議，多人協作時，每個版本，每個人單獨一個分支，或者多個分支。把版本細化，一個分支隻做一個或者多個互相關聯的功能。
- 版本外的單獨需求分支：實際開發中，經常會有一些零碎的緊急需求，該分支就是對應這種情況。
上面說了各個分支的作用，接下來，介紹一下工作的流程：
正常的版本開發上線流程，如下圖：
如上圖，我們應該使用，自己的版本分支（或者bug分支），往對應的環境分支合并。
1.新版本開始時，建立一個對應版本的分支。
2.開發完成後，本地自測沒有問題後，把版本分支合并到測試環境分支。
3.測試人員，在測試環境，進行測試，測試通過後，把版本分支合并到預釋出分支，注意是版本分支，而不是測試分支直接合并。
4.當産品或者需求方，在預釋出環境驗收通過後，把版本分支合并到生産環境分支，然後等待釋出。
5.當釋出生産成功，并運作一定時間，確定沒有問題後，再把版本分支合并到master分支上，然後版本分支，就沒有什麼作用了，此時完全可以删除了。
注意：
每次我們在把版本分支往别的分支合并的時候，盡量都應該先把master合并到版本分支一下，或者定期把master分支合并回版本分支。因為，你的版本周期長的時候，可能會有别的版本或者bug，優先上線了！
比如：
我版本1測試通過了，現在要釋出到預釋出環境去驗收。我應該是使用版本1分支，直接合并到預釋出分支，而不應該測試分支合并到預釋出分支。
測試環境的分支和預釋出環境的分支還有生産環境的分支，作為三個封閉的分支，我們隻往裡面合并代碼，而不将他們合并到其他任何的分支。這樣做的好處就是，可以任意的把自己想要的功能釋出到對應的環境，而不用擔心其他的不應該在這個階段釋出的代碼被合并過去。
事實上git本身是有類似的功能的，但是為什麼不用，反而采取這樣的呢。那是因為，在實際操作中，這種方式雖然笨，但是使用起來，最簡單、最直覺、最不容易出錯。
接下來有幾點我自己的建議：
1.不管是新版本，還是bug還是做别的，建議我們通過issues的方式。因為，issues可以讓我們保留一些有用的資訊，即使分支被删除了，這些資訊依然會保留，友善我們以後查找。
2.如果你是使用指令行，那麼一定要養成一個良好的習慣，不管是做合并還是推送，請一定要在這之前先pull一下！
3.如果代碼又沖突，竟可能的不要使用，工具的一鍵解決的功能，盡量的對比一下沖突的代碼。因為，并不是所有的沖突，都是隻保留一方的代碼就可以的，有的時候可能兩個版本的代碼都需要。