分支策略
在實際開發中，我們應該按照幾個基本原則進行分支管理：
首先，master分支應該是非常穩定的，也就是僅用來發布新版本，平時不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是說，dev分支是不穩定的，到某個時候，比如1.0版本發布時，再把dev分支合并到master上，在master分支發布1.0版本；
你和你的小伙伴們每個人都在dev分支上干活，每個人都有自己的分支，時不時地往dev分支上合并就可以了。
所以，團隊合作的分支看起來就像這樣：
分支推送策略
但是，并不是一定要把本地分支往遠程推送，那么，哪些分支需要推送，哪些不需要呢？
- master分支是主分支，因此要時刻與遠程同步；
- dev分支是開發分支，團隊所有成員都需要在上面工作，所以也需要與遠程同步；
- bug分支只用于在本地修復bug，就沒必要推到遠程了，除非老板要看看你每周到底修復了幾個bug；
- feature分支是否推到遠程，取決于你是否和你的小伙伴合作在上面開發。
總之，就是在Git中，分支完全可以在本地自己藏著玩，是否推送，視你的心情而定！
合并分支歷史信息遺留問題
通常，合并分支時，如果可能，Git會用Fast forward模式，但這種模式下，刪除分支后，會丟掉分支信息。
如果要強制禁用Fast forward模式，Git就會在merge時生成一個新的commit，這樣，從分支歷史上就可以看出分支信息。
如果要保留需要在合并時加上--no-ff參數
git merge命令用于合并指定分支到當前分支(意思在合并前需要切換到主分支)
如，
git merge dev (普通合并)
git merge --no-ff -m "merge with no-ff" dev （保留分支信息合并）
查看分支詳細情況命令
git log --graph --pretty=oneline --abbrev-commit
沖突解決:
Git用<<<<<<<，=======，>>>>>>>標記出不同分支的內容，我們修改如下后保存：
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1
需要解決沖突然后保存
多人協作的工作模式通常是這樣:
- 首先，可以試圖用git push origin branch-name推送自己的修改；
- 如果推送失敗，則因為遠程分支比你的本地更新，需要先用git pull試圖合并；
- 如果合并有沖突，則解決沖突，并在本地提交；
- 沒有沖突或者解決掉沖突后，再用git push origin branch-name推送就能成功！
如果git pull提示“no tracking information”，則說明本地分支和遠程分支的鏈接關系沒有創建，用命令git branch --set-upstream branch-name origin/branch-name。
這就是多人協作的工作模式，一旦熟悉了，就非常簡單。
按本管理
發布一個版本時，我們通常先在版本庫中打一個標簽，這樣，就唯一確定了打標簽時刻的版本。將來無論什么時候，取某個標簽的版本，就是把那個打標簽的時刻的歷史版本取出來。所以，標簽也是版本庫的一個快照。
Git的標簽雖然是版本庫的快照，但其實它就是指向某個commit的指針（跟分支很像對不對？但是分支可以移動，標簽不能移動），所以，創建和刪除標簽都是瞬間完成的。
