使用git的朋友應該都熟悉一些常見的工作流，比如主幹開發分支上線和分支開發主幹上線。前者是指在master分支永遠是開發版的最新代碼，而分支上則是當前線上部署的代碼，後者反之。這裏給大家介紹一個我個人非常習慣的流程：主幹開發，Tag上線。
只用master分支，上線打tag
所謂Tag上線是指我們全程都只有一個master分支，所有代碼都向master提交，當上線的時候我們會在當前版本上打一個tag, tag名就是版本號，比如v1.0.xxxx。版本號可以根據一個簡單的規則來定，v.主版本號.副版本號.HHmm。其中後面的HHmm表示上線時的小時和分鐘，例如今天下午17點的第一次上線可以叫v1.0.1700, 如果發現有問題18點又進行了一次上線，可以打一個名爲v1.0.1800, 如果明天晚上又上線了一次，可以將版本號改爲v1.1.2015。使用這種打tag的方式上線有一個好處，那就是可以保留你所有的上線代碼版本，你可以隨時退回到任意一次上線的代碼庫，這樣就比分支上線方便一些。
修復線上bug
下面來看一個常見的場景，如果線上遇到bug需要修復而master分支已經提交了新開發的代碼了該怎麼辦呢？非常簡單，使用checkout命令，直接退回到最近一次上線的tag位置，然後以此爲基準創建一個新的fix分支:
git checkout fix-bug v1.1.2015
執行完以後就已經在新創建的fix-bug分支了，而且代碼已經回到了最近一次上線的狀態。完成修復以後直接commit並打上新的tag, 比如v1.2.xxxx, 最後切回master分支，將fix-bug合併到master即可：
git commit '修復xxx問題'
git tag v1.2.xxxx
git checkout master
git merge v1.2.xxxx
非常簡單，而且免除了一個代碼庫有衆多分支難以管理的困擾。