最近部門有人書寫了一篇很好的Git協作方式，操作也簡單，分支能以保持一條干凈的線進行協作開發。這里做個筆記，方便之后查看。
PS：本文非原創。
原則
- 不過分相信自己，自己的修改，可能影響所有人
- 不過分信任別人，別人的修改，可能影響我自己
- branch 和 commit 是 后悔葯
- 把大修改分割成小修改，並編寫修改描述（commit message）
- 高風險的修改，在未確定影響范圍的情況下，[不] 推送到dev
- 高風險的修改，找老司機 審(dian)核(bei)
對策
- 各人保持自己的 branch，在獨立的 branch 上進行開發
- 公布修改時，指定推送到 origin/dev
- 周期性對自己的 branch，rebase 到 origin/dev 上
步驟
1. Clone項目
git clone <版本庫的網址> <本地目錄名>
2. 獲取遠端最新狀態，並從 origin/dev 上創建自己的分支
git fetch --all git checkout -b fix-file-upload-bug origin/dev # <分支名> <簽出點> git push -u fix-file-upload-bug # 推送當前分支，並映射 origin/fix-file-upload-bug 為默認推送分支
此分支應只有你自己使用
PS：git fetch --prune : 可以獲取最新的分支情況
git branch --set-upstream debug origin/debug : 設置本地分支跟遠程分支的關聯，使得git pull/push不用指定遠程分支。
3. 查看、確認修改，創建commit
（假設提交所有） git status git add -A git commit -m "[WIP] fix logic on server side, web page not fixed yet" git push # 在遠端保留自己的備份以防萬一， # 此操作會提交到 origin/fix-file-upload-bug，不影響origin/dev ... git add -A git commit -m "[WIP] web page fixed" ... git add -A git commit -m "[FIX] fix and tested"
（注：與svn不同，commit並不會影響遠端分支，也就不可以被別人獲取）
4. ［rebase］更新本地代碼，在 本地 解決沖突（以最新的 origin/dev 為基准）
Git的殺手功能，推薦詳細閱讀更多資料，歡迎補充。
git pull -r origin dev # 組合命令，拉取 & Rebase
git 當前分支 和 origin/dev 的 commit 紀錄，進行 commit by commit 的比對。 相對頻繁的 commit，能有效降低 rebase 的難度。
參考閱讀 https://git-scm.com/docs/git-rebase 注意模型圖
注意解決沖突步驟：
1. 如果有沖突地方，先去解決沖突。
2. 然后執行
git add -A
3. 繼續rebase
git rebase --continue
PS : 切記切記不要commit!!
5. ［push］把本地代碼，立刻公布到 origin/dev上
git push origin HEAD:dev # 手動指定推送到 origin/dev 上（非默認分支 origin/fix-file-upload-bug）
由於步驟4［rebase］的存在，這一步肯定可以成功，且無沖突。
如 origin/dev 被保護，則需要到gitlab上發起MR（merge request），指定目標分支是 origin/dev ，由管理員審核代碼后，觸發合並操作。
6. 好用的命令
提取Git某次提交修改過的文件
git diff-tree -r --no-commit-id --name-only d18f9d5f17e190cfbb836a4acff2d96c0d466a2c | xargs tar -rf mytarfile.tar
Git比SVN好的地方
1、Git分支的創建、刪除、合並非常簡單。
SVN如果想把hotfix的東西合並回dev分支，它的可視化界面操作是比較麻煩的。
2、Git暫存修改
如果在開發過程中，突然需要hotfix個東西，Git可以將修改的東西放到暫存區（恢復到上一次提交的狀態），hotfix完后再從暫存區恢復就行，這是SVN做不到的。
# 將修改內容提交到暫存區 git stash # 查看暫存區內容 git stash list # 恢復某個暫存區的提交 git stash apply stash@{0}