friendbuy是一家網際網路創業公司。產品的源**是託管在github上的。在ec2上有三套環境：生產環境，測試環境和持續整合環境。基本上每天都有大量的**被提交，測試和部署。一年多的磨合下來，逐漸理順了git的使用流程。但是，最開始並不是這樣的，所有的開發人員都沒有使用過git，基本上都是svn的背景。
只有乙個git分支，就是master。開發團隊直接向master提交新的改動，部署其實就是在生產環境下執行
git pull
開發人員的日常工作也很簡單
git pull --rebasegit commit -a -m "***x"
git push
基本上是把git當作svn來使用。
很快就出現了問題。在一次給客戶的演示的過程中，掉鍊子了。
老闆很不高興，對於生產環境部署的質量產生了懷疑。
於是為了使得生產環境穩定，團隊決定犧牲時效性，建立更加正規的流程，新增了測試環境和自動整合環境
每次提交的**都會被自動整合環境自動進行測試
不定期的會人工部署到測試環境中測試
當測試環境測得差不多的時候才會決定部署到生產環境
另外每次部署到測試環境和產品環境的時候都會打乙個標籤
git tag -a *** -m ***
眾所周知，網際網路創業公司玩的就是速度。加上了這麼一套流程之後，乙個feature要發布變得非常冗長。
最要命的是，**為了嘗試不同的風格，還經常全面改版。每次完整的改版都要協調各方面的資源，特別是有乙個很長的ui調整過程。
問題是在**區域性改版的情況下，客戶的其他特性仍然要響應，產品的線上bug仍然要fix。
於是就有了分支。
git branch new-retailer-site mastergit checkout new-retailer-site
#change some thing
git commit -a -m "***"
git push origin new-retailer-site
分支用完了之後，要合併到master中
git checkout mastergit merge new-retailer-site
#fix conflit
git commit -a -m "***"
git push
最後就可以把分支刪除了
git push origin :new-retailer-site
分支在很短的時間就衝到了兩位數。對於分支的管理一開始也並不在意。
直到出了這麼乙個事情：
開發團隊一致決定new-retailer-site已經差不多了，可以「準備」發布了。然後new-retailer-site被合併到了master中。
然後在master上有開發了一些其他特性。
但是new-retailer-site的ui遲遲不能夠讓人滿意。直到有一天開發團隊被要求先把master中的「有用」的feature發布，樣式改版工作延後發布。
這可難辦了，所有的改動已經混雜在同乙個分支中了。
最後的解決辦法是用
git log
把一條條的改動給找出來，由於比對實在太麻煩了，還寫了點**來幹這事
def list_commits(branch):commits = local('
git log
' + branch + '
^master --no-merges --format=format:%s,%h
', capture=true)
commits = commits.split('
\n')
for commit in commits:
print('
==> %s <==
' % commit.split('
,')[0])
print('
' % commit.split('
,')[1])
然後把找出來的commit，一條條cherry pick出來
git cherry-pick
接下來很長一段時間都是搞不清楚，到底是哪個分支是產品部署的分支。
直到某一天，團隊決定以後再也不能隨便把無關分支合併到master了。
正常的工作流程應該是，選定要候選發布的branch，比如說new-retailer-site
git checkout new-retailer-sitegit merge master
# fix conflict
git commit -a -m "merge"
git push
然後在測試環境下
git checkout new-retailer-sitegit pull
測試通過了之後，確定可以發布到產品環境了
git checkout mastergit merge new-retailer-site
git push
然後把剩餘的分支，逐個更新
git checkout feature-branch-1git merge master
# ...
git checkout feature-branch-2
git merge master
# ...
使用feature branch的方式，可以同時進行很多項特性的開發，並有產品的需要決定什麼時候發布哪些特性。比如在聖誕節期間，基本上就沒有feature branch被發布，但是開發並不會因此停滯。而且業務的優先順序經常調整，經常開發到一半的分支也會被扔掉。
在使用多分支開發的時候要保持乙個master分支始終對應「一定會被發布到產品環境的**」，以master為中心保持一致的合併方向，不然分支之間亂合併就很難管理了。
目前有乙個缺陷是持續整合環境只對master進行測試，理想的情況下應該建立乙個staging的分支，持續整合環境也要對staging分支進行測試。
Git 工作流程
git 作為乙個原始碼管理系統，不可避免涉及到多人協作。協作必須有乙個規範的工作流程，讓大家有效地合作，使得專案井井有條地發展下去。工作流程 在英語裡，叫做 workflow 或者 flow 原意是水流，比喻專案像水流那樣，順暢 自然地向前流動，不會發生衝擊 對撞 甚至漩渦。本文介紹三種廣泛使用的工...
Git 工作流程
git 作為乙個原始碼管理系統，不可避免涉及到多人協作。協作必須有乙個規範的工作流程，讓大家有效地合作，使得專案井井有條地發展下去。工作流程 在英語裡，叫做 workflow 或者 flow 原意是水流，比喻專案像水流那樣，順暢 自然地向前流動，不會發生衝擊 對撞 甚至漩渦。本文的三種工作流程，有乙...
Git工作流程
在伺服器上有2個主要分支，master和develop 本地分支基本和遠端一樣，但是開發的時候，需要你在本地建立其他分支，最後等功能開發完成後，merge到你需要的分支上，然後刪除那個臨時的分支。這樣完成開發。專案者首先在gitlab建立2個分支，預設乙個master，並將master設定為保護，只...