SVN冲突出现场景

如今是一个团结协作的时代，开发一个系统，往往会多人协作共同完成。版本管理是必不可少的，常用的软件有Git，SVN等。今天说一下，SVN管理版本时，如果出现冲突后，如何快速解决冲突。

首先说明一个问题，有一种情况无论如何都不会出现冲突。假如有一个叫qaz的程序员，他checkout了版本库，这样他拥有了一个工作副本。然后，他修改了某个文件IMRoot.cs，commit到SVN，并且这个文件保证不会有其他人在他们的工作副本修改并提交到SVN。这种情况下，无论qaz 如何修改IMRoot.cs ，在commit时都不会发生冲突。

以上说了一种不会出现冲突的情况，那么什么应用场合可能会出现冲突呢？假如程序员wsx 他会修改文件 IMRoot.cs 并commit 到SVN，此时可能会引发冲突。

实例分析

下面，我们根据实际应用场合，模拟出现冲突，到如何通过SVN提供的Edit Conflicts 界面，通过颜色标识和操作按钮，快速准确地合并解决冲突。

开始，IMRoot.cs 文件主题内容是这样的，命名空间为了理解方便省略掉。 

qaz 在文件的第14 行做了修改，其他的未作任何改动，并且将修改commit到了SVN。 

wsx 在在第19行做了修改，修改如下， 

并且在提交前update了（注意因为这个文件已经被qaz 做了修改，所以wsx 如果commit前不update，SVN是不允许提交的），然后commit，此时，SVN不会引发冲突，因为修改不是在同一行。SVN将qaz 的修改合并到了wsx 拥有的工作副本中，合并后文件如下所示， 

为了故意引发冲突，假设qaz 和 wsx 同时都修改了第29行。前者修改第29行为如下，并且commite 到了SVN中 

后者修改也同时修改了这一行，这意味他并没有update 这个文件， 

然后他commit 到SVN时，提示先update ,紧接着出现冲突，如下所示， 

此时，找到这个文件，右键选择Edit conflicts 按钮，弹出编辑冲突的界面，这才到了重点！ 

从上图可以看到，主要有3个子窗口组成，左上Theirs 为SVN版本库中（也就是qaz 刚才修改提交到SVN的版本），右上 Mine 为 wsx （正在提交到SVN发现冲突的他）的工作副本文件，下方为合并他俩的文件后的显示窗口。

以下为这3个窗口的局部视图，依次为左上，右上，下方， 

 
左上

 
右上

下方

当面对以上3个窗口时，还是容易让人发蒙，尤其是文件比较复杂，冲突一大片，各种颜色掺杂在一起，不知如何下手，害怕把其他文件意外破坏和文件合并错误。那么怎么办呢？我们不妨先从简单的文件冲突入手，彻底理解各种颜色的含义，冲突行是如何标记的，这样我们才敢大胆地使用这个界面进行代码合并操作，不用担心合并后，把别的文件无辜干扰了或者出现合并错误的问题。

仔细观察以上3个窗口，我们发现，28行和29行之间多出来一行，即橙色行，并且Theirs 和Mine 都含有这一行，这个是未冲突前，此行的内容，即刚开始的版本。第29行是爆红行、冲突行，相应字段还是黄色警示，并且在第3个窗口（下方窗口）第29行全是？？？？？这种符号，意味着无法合并他俩对此行的同时修改，需要我们判断，要么采取Theirs 的，要么采取Mine 的，要么采取上一版本，要么重新商量一个相同的。SVN也提供了几个方便的右键按钮，提示如何做出这些选择， 

use this text block ： 选取选中行的内容 
use this whole file ：选取选中行所在文件的全部内容 
use text block from mine before theirs ：先用Mine的内容，后面接着用theirs的

假如第29行我们想采用qaz 的修改，那么，我们在左上窗口，选中第29行，右键选择 use this text block ，然后下方的视图变为如下， 

第29行由一行？？？？？？变为左上窗口第29行的内容，颜色由爆红变为了浅绿色。这时候注意观察，在上一行橙色显示内容代表什么意思，注意最左侧有个 “-”提示，代表此行不会纳入合并文件中。

假如第29 行，我们都想纳入qaz 和wsx 的修改，此时我们在左上窗口选择，use text block from mine before theirs ，即先用Mine的内容，后面接着用theirs的，选择后下方窗口合并内容如下， 

可以看到，第29行，先显示Mine的，然后显示Theirs的。

这些操作后，我们点击上方的Mark as Resolved 按钮，然后保存即可。这样冲突就被解决掉了。然后wsx 再commit 自己的内容到SVN。

冲突深度详细解决方案及可能带来的隐患思考

最近在做项目时,本地comit完代码后,从远程库拉取代码后,发现出现很多冲突,有点慌不知如何快速解决,一个个改效率太低,小乌龟这个之前看过一点点,但没有在实际项目中用过,这次用小乌龟快速解决了这个问题.
小乌龟下载地址

场景:
在公司做项目时,多个同事可能会同时修改了同一文件的同一行的代码,其中一个已提交了代码,但你又在本地修改了,拉取代码时势必会造成冲突,如果少量冲突,手动改一下还好,但是出现大量冲突,势必要借助一些工具,提高工作效率.

案例:
首先,我直接在远程代码仓库直接添加测试代码,模拟同事已commit了代码.

然后在本地,同一文件的同一位置,添加代码,这时提交代码,拉取代码后,会发现:


打开当前项目所在位置:
鼠标右击---->TortoiseGit -->Reslove

然后会弹出,显示冲突文件:

双击冲突文件:打开解决冲突的窗口

左边文件为:远程仓库的文件,右边为本地文件(也就是你当前修改的文件)
下边的文件是你合并操作后的文件,所以你要对比左右文件的差异:
比较常见的情况是:
1.你对已有的代码进行了改动,也会造成冲突(应该以你修改的为准)
2.别的同事推送的代码.和你添加的代码的位置冲突了(都要保留)
下面就解决冲突:

在合并处,鼠标右击:

1.Use text block from left:使用远程库的代码
2.Use text block from right:使用本地的代码
3.Use text block from right before left:
远程库和本地文件的代码都保留,且本地库的代码放在上面,远程库的代码放在下面
Use text block from left before right:
远程库和本地文件的代码都保留,且本地库的代码放在下面,远程库的代码放在上面

合并后的代码:

最后,点击Mark as resolved 和Save按钮即可(如果冲突比较多,就点击Next difference一个个排查解决冲突即可)

还有虽然解决了,冲突,但是git命令行还是处于master/merging状态,这又该如何解决?
几个命令就解决了

最后,再将合并后的代码push到远程仓库:
还是习惯性先拉取一下代码

一、git命令在提交代码前，没有pull拉最新的代码，因此再次提交出现了冲突

解决方法如下两种：

1.保留你本地的修改

git merge --abort
git reset --merge
合并后记得一定要提交这个本地的合并（add–>commit–>push–>pull）
然后在获取线上仓库：
git pull

2.down下线上代码版本,抛弃本地的修改

不建议这样做,但是如果你本地修改不大,或者自己有一份备份留存,可以直接用线上最新版本覆盖到本地
git fetch --all
git reset --hard origin/master
git fetch

二、从git远程仓库中pull最新的代码，出现如下错误：Please commit your changes or stash them before you merge.

解决方法如下：

git stash 可用来暂存当前正在进行的工作， 比如想pull 最新代码， 又不想加新commit， 或者另外一种情况，为了fix 一个紧急的bug, 先stash, 使返回到自己上一个commit, 改完bug之后再stash pop, 继续原来的工作。

1. git stash //暂存代码
2. git pull 分支名//从远程仓库拉取最新代码
3. git stash pop //合并代码到本地仓库 此时代码是将暂存的代码和远程仓库的代码合并，如下图：
   
4. 这时候需要手动修改合并所需的代码即可。
5. git stash clear//需要清空git栈执行该命令

git stash: 备份当前的工作区的内容，从最近的一次提交中读取相关内容，让工作区保证和上次提交的内容一致。同时，将当前的工作区内容保存到Git栈中。
git stash pop: 从Git栈中读取最近一次保存的内容，恢复工作区的相关内容。由于可能存在多个Stash的内容，所以用栈来管理，pop会从最近的一个stash中读取内容并恢复。
git stash list: 显示Git栈内的所有备份，可以利用这个列表来决定从那个地方恢复。
git stash clear: 清空Git栈。此时使用gitg等图形化工具会发现，原来stash的哪些节点都消失了

三、git push 报错，如下：

解决命令：git pull --rebase origin 你的分支名称，如下图所示
再次执行push命令：如下图所示：

四、git push 还会报下面的错（如图所示）：这多是多人开发有了冲突。

hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., ‘git pull …’) before pushing again.
hint: See the ‘Note about fast-forwards’ in ‘git push --help’ for details.

解决命令如下：

git push -u 代码所在的分支 -f //强制提交，此时远程上的修改已经被覆盖。这种方法一般不建议使用，除非你把远程上修改的代码复制到本地。

五、本地回退历史版本，当提交代码发生冲突或者想回退到某一个版本，操作如下：

1. git log (获取提交的历史日志)
   

2. 执行命令：git reset --hard 版本号（就是git log 中的 commit后面的哈希值（上图中的黄色部分 commit 后面的值））

3. 想要修改远程上的代码还需要执行如下命令：
   git push -u 代码所在的分支 -f //强制提交，此时远程上的修改已经被覆盖。这种方法一般不建议使用，除非你把远程上修改的代码复制到本地。

git merge --abort的一种使用情况

该命令仅仅在合并后导致冲突时才使用。git merge --abort将会抛弃合并过程并且尝试重建合并前的状态。但是，当合并开始时如果存在未commit的文件，git merge --abort在某些情况下将无法重现合并前的状态。（特别是这些未commit的文件在合并的过程中将会被修改时）

警告：运行git-merge时含有大量的未commit文件很容易让你陷入困境，这将使你在冲突中难以回退。因此非常不鼓励在使用git-merge时存在未commit的文件，建议使用git-stash命令将这些未commit文件暂存起来，并在解决冲突以后使用git stash pop把这些未commit文件还原出来。