模拟目前工作流程
- 在gitlab fork 需要开发的项目到自己仓库
- 分配一个工作任务（feature、improvment、bug）
- 本地从个人仓库克隆项目 git clone http://mylocal/group/project
- 本地添加对于远端项目 git remote add upstream http://dev.xxx.io/group/project
- 基于远端仓库切出本地开发分支 git checkout -b feature_xxx upstream/feature_xxx
- 本地 coding 改代码，commit N次（其中也包含 push 远端仓库N次需要给QA同学测试使用过程中发现新的问题又需要反复重复这个过程）
- QA验收通过准备合并回主分支，需要进行 rebase 将多次commit压缩成一个(rebase翻译成
变基我是懵逼的，个人认为压缩更好)
7.1 本地 git checkout -b feature_xx origin/feature_xxx （注意这里的 origin 远端分支是个人仓库，因为每次的PR提交都是从个人仓库向远端仓库提交）
7.2 本地 git rebase -i upstream/feature_xxx (此时会进入编辑模式开发分支的所有commit都会展示出来除了第一个其他全部将 pick改为 s)
7.3 本地解决冲突文件，解决完成 git add .
7.4 继续解决 git rebase --continue （重复上一个和这一个步骤直到所有冲突解决完成） - git push feature_xx origin/feature_xx
- 基于个人仓库的 feature_xx 提交一个MR到公司仓库的对应分支
rebase 的好处：因为rebase 都发生在个人仓库，并且一个新功能或BUG修复往往很难一步到位，同时你要提交你得代码后QA同学才能打包测试。所以往往都伴随N个Commit，此时如果是几十人在主分支同时参与工作，可能你的一个错误提交就影响了其他所有人从主分支拉取的最新代码。此时rebase 压缩N个commit的 PR 就非常好 revert掉来解决这个问题。让其他人不受影响
其它命令
git feature upstream 拉取远端最新变化
git rebase -i commitId 压缩从指定commitId开始到现在的commit
git rebase --abort 中止压缩
git stash 暂存本地变化
git stash apply 还原暂存的变化(默认第一个)
git stash drop 删除暂存 (默认第一个)
git commit --amend 修正commit的说明内容(commit中存在错别字时非常好用)