使用git rebase -i合併提交
`rebase`為變基
`git rebase -i `命令可以壓縮合併多次提交
格式：`git rebase -i [startpoint] [endpoint]`
其中-i的意思是`–interactive`，即彈出互動式的介面讓使用者編輯完成合併操作，[startpoint] `[endpoint]`則指定了乙個編輯區間，如果不指定`[endpoint]`，則該區間的終點預設是當前分支`head`所指向的`commit`(注：該區間指定的是乙個前開後閉的區間)。
在檢視git的log後，可以使用如下命令
// 合併從當前head到15f745b(commit id)
`git rebase -i 15f745b`
或:// 合併最近的兩次提交
`git rebase -i head~2`
pick：保留該commit（縮寫:p）
reword：保留該commit，但我需要修改該commit的注釋（縮寫:r）
edit：保留該commit, 但我要停下來修改該提交(不僅僅修改注釋)（縮寫:e）
squash：將該commit和前乙個commit合併（縮寫:s）
fixup：將該commit和前乙個commit合併，但我不要保留該提交的注釋資訊（縮寫:f）
exec：執行shell命令（縮寫:x）
drop：我要丟棄該commit（縮寫:d）
第二行的 pick 改為 s,s為squash的縮寫,squash的意思是將這個提交壓縮為最後一次提交，儲存後再重新編寫注釋
使用git pull --rebase避免提交樹上出現太多的merge操作
rebase詳解：
執行git pull --rebase時，若出現了與本地衝突，此時head會指向乙個commit id來解決衝突，解決後執行git add，不要執行git commit，執行完git add後，使用命令git rebase --continue來完成rebase。
有個很成熟的叫「git flow」的分支模型，它能夠應對 99% 的場景，剩下的那 1% 留給幾乎不存在的極度**的場景。
需要注意的是，它只是乙個模型，而不是乙個工具；你可以用工具去應用這個模型，也可以用最樸實的命令列。所以，重要的是理解概念，不要執著於實行的手段。
簡單說來，git flow 就是給原本普普通通的分支賦予了不同的「職責」：
master——最為穩定功能最為完整的隨時可發布的**；
hotfix——修復線上**的 bug；
develop——永遠是功能最新最全的分支；
feature——某個功能點正在開發階段；
release——發布定期要上線的功能。
看到上面的「master」和「develop」加粗了吧？代表它們是「主要分支」，其他的分支是基於它們派生出來的。主要分支每種型別只能有乙個，派生分支每個型別可以同時存在多個。各型別分支之間的關係用一張圖來體現就是：
Git Flow，Git團隊協作最佳實踐
git是乙個很好的版本管理工具，不過相比於傳統的版本管理工具，學習成本比較高，實際開發中，如果團隊成員比較多，開發迭代頻繁，對git的應用比較混亂，會產生很多不必要的衝突或者 丟失等。就像寫 需要 規範一樣，使用git進行 管理同樣需要乙個清晰的流程和規範，git flow就是乙個被廣泛認可的git...
Git Flow Git團隊協作最佳實踐
git是乙個很好的版本管理工具，不過相比於傳統的版本管理工具，學習成本比較高。實際開發中，如果團隊成員比較多，開發迭代頻繁，對git的應用比較混亂，會產生很多不必要的衝突或者 丟失等。就像 需要 規範一樣，使用git進行 管理同樣需要乙個清晰的流程和規範，git flow就是乙個被廣泛認可的git使...
Git多人協作
1 檢視遠端庫資訊 git remote git remote v 2 推送分支 將本地的資訊push到伺服器上 git push origin master 注意 1 master分支是主要的分支，需要時時刻刻同步 2 dev分支是開發分支，所有團隊成員在上面工作，需要同步 3 bug分支只用於本...