最近部门有人书写了一篇很好的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@{}