由于工作中代码库使用的是gerrit，本文场景也是基于gerrit实操
合库原则
- 原则1：合代码前更新库代码：
git pull --rebase
- 原则2： 常用
git status，确认当前修改的是不是都要提交
场景一：在新下的代码中合库
直接clone一份代码，立即合入代码，入库。这种情况很少出现冲突，建议如下操作步骤：
git clone ....// 从gerrit库 clone代码到本地- 用merge工具合入修改的代码
git add .或git add --all// 如果是有新增的文件，要用后者才能把新增的文件add到staged状态git commit// 按规定格式填好log信息。 这一步可以和上一步合并：git commit -agit push origin HEAD:refs/for/xxx// 推送到gerrit进行走查，xxx为分支名称。建议自己到gerrit确认一下代码是否ok（别遗漏修改、别多改）
场景二：在非最新代码中合库
本地已有之前clone的代码，但是已有一段时间了。这种情况直接修改较有可能出现冲突，故需要先更新本地代码。建议如下操作步骤：
1、 git pull --rebase // 更新代码，这种更新方式适合本地还没有任何修改；如果本地已有修改且不需要了，可以 git reset --hard HEAD && git pull 强制更新到最新
2、后续同场景一的第2步 ~ 第5步
场景三：对走查意见增补提交
本地已推送的代码，走查时发现问题，需要amend修改。这种情况可以直接amend，但有可能出现冲突，所以最好先更新本地代码。建议如下操作步骤：
1、git pull --rebase // 只能用这种方式更新，这样更新后可保证本地代码与库里代码一致，且之前推送走查的那个commit位于第一个（可git log 确认）
2、同场景一的第2步 ~ 第3步
3、git commit --amend // amend参数表示以增补的方式修改，也就是这次合入的代码会增补到你之前推送走查的那个commit。如果没有第一步，本操作可能失败或生成一个新的commit
4、同场景一的第5步
场景四：入库冲突
推送到gerrit的代码，提示Cannot Merge。这种情况说明没有按前面场景二、场景三先更新本地代码，如果先更新了代码再推送，几乎不可能出现这个问题。建议如下操作：
1、git pull --rebase // 只能用这种方式更新，此时不会正常更新成功，而是出现冲突提示，有冲突的文件名前面会带 Conflict ...字样
2、打开冲突文件，解决冲突，具体见下面 Conflict解决
3、git add 冲突文件 // 有几个就add几个，当然也可以 git add .
4、git rebase --continue // 完成rebase操作，此时代码已更新到与gerrit一致了，可以git log确认，你的commit应该位于第一个
5、同场景一的第5步
