我们拉取了一个项目，在此分支进行，修改，同时别人也拉取了统一分支的代码进行修改而且也已经提交到远程，这时候如果我们将本地代码提交了并推送到远程，一定会出现代码冲突的问题，
如果我们在代码提交前，再git pull ,也会出现冲突问题, 那么有没有一个优雅的办法应对代码仓库冲突的问题，又避免内容丢失？

有两种解决方案

1、git stash -> git pull -> git stash pop -> 解决冲突 ->git add -> git commit

2、git commit -> git pull -> 解决冲突 -> git add -> git commit

对于第一种解决方案：

其中的git stash 会做这样的事：

1、将暂存区的代码和工作区的代码都保存下来

2、加 -u 参数，会把不被跟踪的文件（即它在工作区，但是永远不会被添加到暂存区）也保存下来

所以git stash 会存储我们本地代码的操作记录，将本地的代码库恢复成本地最近一次拉取的状态，这样拉取远程代码就不会出现冲突问题，

当我们把我们的操作记录弹出，暂存区和工作区的代码会相应的恢复，我们就相当于在最新提交的版本上进行修改，但是同样会在工作区上出现冲突，我们手动解决冲突的文件，然后添加到暂存区，再提交我们的修改，就可以完美的推送到远程（前提还是远程的最新代码还是我们最近拉取的代码）

这种解决方案的好处是，当我们修改代码修改到一半时，想要同步和远程最新代码的内容，不想提交一个半成品，这样做就非常有用，就相当于我们代码的修改基于最新分支情况进行修改，提交记录就只有一次。

对于第二种解决方案：

首先git commit会把我们当前修改的代码提交生成一个版本，这时候工作区和暂存区都很干净，

接着git pull，其实也分为两步，

先git fetch 将远程最新提交记录同步到本地，

然后git merge将本地最新一次的提交和远程最新一次的提交内容合并放到工作区，

若无冲突直接提交到暂存区并提交，

若有冲突会系统就会在工作区代码中注明哪些冲突，然后需要我们手动解决并手动添加到暂存区、再手动提交到版本库。

最后总结：

1、理解合并冲突并不容易，但也有方法，无论如何我们都要坚定的确信，冲突一定可以解决！冲突一定可以解决！冲突一定可以解决！

2、想要避免冲突，保护本地已经修改的代码，上述是最佳实践，

3、第一种推荐代码只完成了一半，但想和远程代码同步的，第二种推荐确认自己的修改无误时使用.

4、当本地提交的版本不是基于远程仓库的最新版本，一定会被拒绝push，

解决方案就是git push, 解决冲突，再提交

5、当本地正在修改代码，知道了远程已经迭代了代码需要同步时，如果直接git pull ,会覆盖掉工作区和暂存区的内容，也会被拒绝(因为在git merge 时会在工作区合并文件，并放到暂存区并提交，如果工作区不干净，即还有未add到暂存区的代码，就会覆盖其工作区中的代码，如果暂处区不干净，也会覆盖掉 ) ,（除非 在命令添加 –force，强制覆盖)

解决方案就是git stash ,git pull ,git stash pop ,然后解决冲突，再commit和push