❶ git分支冲突未解决但还是提交了
这个意思是说更新下来的内容和本地修改的内容有冲突，先提交你的改变或者先将本地修改暂时存储起来。
处理的方式：1、先将本地修改存储起来。2、pull内容。3、还原暂存的内容。
Git保存的不是文件的变化或者差异，而是一系列不同时刻的文件快照。在进行提交操作时，Git会保存一个提交对象（commitobject）。该提交对象会包含一个指向暂存内容快照的指针。但不仅仅是这样，该提交对象还包含了作者的姓名和邮箱、提交时输入的信息以及指向它的父对象的指针。
❷ git分支合并为什么会发生冲突
在解决git merge的冲突时，有时我总忍不住吐槽git实在太不智能了，明明仅仅是往代码里面插入几行，没想到合并就失败了，只能手工去一个个确认。真不知道git的合并冲突是怎么判定的。
在一次解决了涉及几十个文件的合并冲突后（整整花了我一个晚上和一个早上的时间！），我终于下定决心，去看一下git
merge代码里面冲突判定的具体实现。正所谓冤有头债有主，至少下次遇到同样的问题时就可以知道自己栽在谁的手里了。于是就有了这样一篇文章，讲讲
git merge内部的冲突判定机制。
recursive three-way merge和ancestor
git的源码
先用merge作关键字搜索，看看涉及的相关代码。
找了一段时间，找到了git merge的时候，比较待合并文件的函数入口：ll_merge。另外还有一份文档，它也指出ll_merge正是合并实现的入口。
从函数签名可以看到，mmfile_t应该就代表了待合并的文件。有趣的是，这里待合并的文件并不是两份，而是三份。
int ll_merge(mmbuffer_t *result_buf,
const char *path,
mmfile_t *ancestor, const char *ancestor_label,
mmfile_t *ours, const char *our_label,
mmfile_t *theirs, const char *their_label,
const struct ll_merge_options *opts)
看过git help merge的读者应该知道，ours表示当前分支，theirs表示待合并分支。看得出来，这个函数就是把某个文件在不同分支上的版本合并在一起。那么ancestor又是位于哪个分支呢？倒过来从调用方开始阅读代码，可以看出大体的流程是这样的，git merge会找出三个commit，然后对每个待合并的文件调用ll_merge，生成最终的合并结果。按注释的说法，ancestor是后面两个commit（ours和theirs）的公共祖先（ancestor）。另外前面提到的文档也说明，git合并的时候使用的是recursive three-way merge。
关于recursive three-way merge， wikipedia上有个相关的介绍#Recursive_three-
way_merge)。就是在合并的时候，将ours，theirs和ancestor三个版本的文件进行比较，获取ours和ancestor的
diff，以及theirs和ancestor的diff，这样做能够发现两个不同的分支到底做了哪些改动。毕竟后面git需要判定冲突的内容，如果没有
原初版本的信息，只是简单地比较两个文件，是做不到的。
鉴于我的目标是发掘git判定冲突的机制，所以没有去看git里面查找ancestor的实现。不过只需肉眼在图形化界面里瞅上一眼，就可以找到ancestor commit。（比如在gitlab的network界面中，回溯两个分支的commit线，一直到岔路口）
有一点需要注意的是，revert一个commit不会改变它的ancestor。所谓的revert，只是在当前commit的上面添加了新的
undo
commit，并没有改变“岔路口”的位置。不要想当然地认为，revert之后ancestor就变成上一个commit的ancestor了。尤其是
在revert merge commit的时候，总是容易忘掉这个事实。假如你revert了一个merge
commit，在重新merge的时候，git所参照的ancestor将不是merge之前的ancestor，而是revert之后的
ancestor。于是就掉到坑里去了。建议所有读者都看一下git官方对于revert merge commit潜在后果的说法：
结论是，如果一个merge commit引入的bug容易修复，请不要轻易revert一个merge commit。
剖析xdiff
从ll_merge往下追，可以看到后面出了一条旁路：ll_binary_merge。这个函数专门处理bin类型文件的合并。它的实现简单粗暴，如果你没有指定合并策略（theris或ours），直接报Cannot merge binary files错误。看来在git看来，二进制文件并没有diff的价值。
主路径从ll_xdl_merge到xdl_merge，进到一个叫xdiff的库中。终于找到git merge的具体实现了。
平心而论，xdiff的代码风格十分糟糕，不仅注释太少，而且结构体成员变量居然使用类似i1、i2这样的命名，看得我头昏脑胀、心烦意燥。
吐槽结束，先讲下xdl_merge的流程。xdl_merge做了下面四件事：
由xdl_do_diff完成two-way diff（ours和ancestor，theirs和ancestor）,生成修改记录，存储到xdfenv_t中。
xdl_change_compact压缩相邻的修改记录，再用xdl_build_script建立xdchange_t链表，记录双方修改。xdchange_t主要包括了修改的起始行号和修改范围。
这时候分三种情况，其中两种是只有一方有修改（只有ours或theirs一条链表），直接退出。最后一种是双方都有修改，需要合并修改记
录。由于修改记录是按行号有序排列的，所以直接合并两个链表。修改记录如果没有重叠部分，按先后顺序标记为我方修改/他方修改。如果发生了重叠，就表示发
生了冲突。之后会重新过一遍两个待合并链表，对于那些标记为冲突的部分，比较它们是否相等的，如果是，标记为双方修改。
由xdl_fill_merge_buffer输出合并结果。如果有冲突，调用fill_conflict_hunk输出冲突情况。如果没有冲突（标记为我方修改/他方修改/双方修改），则合并ancestor的原内容和修改记录，按标记的类型取修改后的内容，并输出。
输出冲突情况的代码位于fill_conflict_hunk中。它的实现很简单，毕竟此时我们已经有了双方修改的内容，现在只需要同时输出冲突内容，供用户取舍。（这便是那次花了一个晚上和一个早上改掉的冲突的源头，兇手就是你，哼）。
输出格式恐怕大家都很熟悉。该函数会先打印若干个。这个就是折磨人的合并冲突了：
<<<<<<< HEAD
3
=======
2
>>>>>>> branch1
总结
git merge的冲突判定机制如下：先寻找两个commit的公共祖先，比较同一个文件分别在ours和theirs下对于公共祖先的差异，然后合并这两组差异。如果双方同时修改了一处地方且修改内容不同，就判定为合并冲突，依次输出双方修改的内容。
❸ svn如何解决分支冲突
1、 如何产生冲突
当开发人员A和开发人员B从版本库同时检出文档1.txt，而A和B同时修改了1.txt的同一地方，后提交的一方会在拷贝副本中产生冲突。
两个工作拷贝，A拷贝中文件1.txt内容为
dfqerq
123dfwre
B拷贝中文件1.txt内容为
dfqerq
123erwrq
在B版本提交之前版本库上的1.txt（base版本）内容为
dfqerq
B拷贝先提交版本到版本库中，以至于最新版本内容变为
dfqerq
123erwrq
此时A版本也提交则会产生冲突，无法提交，需要先svn
update，此时会在A拷贝中产生三个临时文件1.txt.rNew\1.txt.rOld\1.txt.mine，其中1.txt.rNew是最新版
本，1.txt.rOld是base版本，1.txt.mine是A作者修改后的版本，在此例中内容为
dfqerq
123dfwre
而update之后A拷贝中的1.txt内容为
<<<<<<< .mine
dfqerq
123dfwre=======
dfqerq
123erwrq>>>>>>> .r18
其中<<<<<<< .mine与=======之间表示A修改后的内容，=======与>>>>>>> .r18之间是版本服务器上的版本
2、解决冲突
第一种，利用update的选项进行冲突解决，也就是说不管当前拷贝副本是否是最新版本，都使用—accept参数作为冲突处理方式
–accept ARG : specify automatic conflict resolution action
(‘postpone’, ‘base’, ‘mine-conflict’,
‘theirs-conflict’, ‘mine-full’, ‘theirs-full’,
‘edit’, ‘launch’)
(p) postpone – mark the conflict to be resolved later //让文件在更新完成之后保持冲突状态。
(df) diff-full – show all changes made to merged file //使用标准区别格式显示base修订版本和冲突文件本身的区别。
(e) edit – change merged file in an editor //用你喜欢的编辑器打开冲突的文件，编辑器是环境变量EDITOR设置的。
(r) resolved – accept merged version of file //完成文件编辑之后，通知svn你已经解决了文件的冲突，它必须接受当前的内容—从本质上讲就是你已经“解决了”冲突。
(mf) mine-full – accept my version of entire file (ignore their change//丢弃新从服务器接收的变更，并只使用你查看文件的本地修改。
(tf) theirs-full – accept their version of entire file (lose my changes)//丢弃你对查看文件的本地修改，只使用从服务器新接收的变更。
(l) launch – launch external tool to resolve conflict//启动一个外置程序来执行冲突解决，这需要一些预先的准备。
(h) help – show this list //显示所有在冲突解决时可能使用的命令。
第二种，在update时并不处理冲突，利用svn resolve解决冲突
1、利用svn resolve –accept base选择base版本，即1.txt.rOld作为最后提交的版本
–accept ARG : specify automatic conflict resolution source
(‘base’, ‘working’, ‘mine-conflict’,
‘theirs-conflict’, ‘mine-full’, ‘theirs-full’)
2、手工修改1.txt文件，然后将当前拷贝即1.txt作为最后提交的版本
svn resolve –accept working 1.txt
3、svn resolve –accept theirs-full 1.txt 使用1.txt.rNew作为最后提交的版本
4、svn resolve –accept mine-full 1.txt 使用1.txt.mine作为最后提交的版本
5、svn resolve –accept mine-conflict 1.txt 使用1.txt.mine的冲突部分作为最后提交的版本
5、svn resolve –accept theirs-conflict 1.txt 使用1.txt.rNew的冲突部分作为最后提交的版本
第三种，使用svn revert取消变更
（以上文章来源：http://blog.sina.com.cn/s/blog_65fd4c1e0100h2cg.html）
－－－－－
前两天在解决冲突时用到了svn resolve这个命令，找到这篇文章主要是因为他对–accept参数的说明比较全
比官方的文档更详细。
svn文件冲突,树冲突详解
解决冲突
偶尔，当你从版本库更新、合并文件时，或者切换工作副本至一个不同的 URL 时你会遇到冲突。有两种冲突:
文件冲突
当两名(或更多)开发人员修改了同一个文件中相邻或相同的行时就会发生文件冲突。
树冲突
当一名开发人员移动、重命名、删除一个文件或文件夹，而另一名开发人员也对它们进行了移动、重命名、删除或者仅仅是修改时就会发生树冲突。
文件冲突
当两名或更多开发人员修改了同一个文件中相邻或相同的行时就会发生文件冲突。由于 Subversion 不知道你的项目的具体情况，它把解决冲突的工作留给了开发人员。一旦出现冲突，你就应该打开有问题的文件，查找以字符串<<<<<<<开头的行。有冲突的区域用如下的方式标记:
<<<<<<< 文件名
你的修改
=======
合并自版本库中的代码
>>>>>>> 版本
对于每个冲突的文件 Subversion 在你的目录下放置了三个文件:
文件名.ext.mine
这是你的文件，在你更新你的工作副本之前存在于你的的工作副本中——也就是说，没有冲突标志。这个文件除了你的最新修改外没有别的东西。
文件名.ext.r旧版本
这是在你更新你的工作副本之前的基础版本(BASE revision)文件。也就是说，它是在你做最后修改之前所检出的文件。
文件名.ext.r新版本
这个文件是当你更新你的工作副本时，你的 Subversion 客户端从服务器接收到的。这个文件对应于版本库中的最新版本。
你可以通过TortoiseSVN → 编辑冲突运行外部合并工具/冲突编辑器，或者你可以使用任何别的编辑器手动解决冲突。你需要冲定哪些代码是需要的，做一些必要的修改然后保存。
然后，执行命令TortoiseSVN → 已解决并提交人的修改到版本库。需要注意的是已解决命令并不是真正的解决了冲突，它只是删除了filename.ext.mine和filename.ext.r*两个文件，允许你提交修改。
如果你的二进制文件有冲突，Subversion不会试图合并文件。本地文件保持不变(完全是你最后修改时的样子)，但你会看到filename.ext.r*文件。如果你要撤消你的修改，保留版本库中的版本，请使用还原(Revert)命令。如果你要保持你的版本覆盖版本库中的版本，使用已解决命令，然后提交你的版本。
你可以右击父文件夹，选择TortoiseSVN → 已解决...，使用“已解决”命令来解决多个文件。这个操作会出现一个对话框，列出文件夹下所有有冲突的文件，你可以选择将哪些标记成已解决。
树冲突
当一名开发人员移动、重命名、删除一个文件或文件夹，而另一名开发人员也对它们进行了移动、重命名、删除或者仅仅是修改时就会发生树冲突。有很多种不同的情形可以导致树冲突，而且不同的情形需要不同的步骤来解决冲突。
当一个文件通过 Subversion 在本机删除后，文件也从本机文件系统中删除。因此即使它是树冲突的一部分，却既不能显示冲突的叠加图标也不能通过右键单击来解决冲突。使用检查修改对话框来获得编辑冲突选项。
TortoiseSVN 能够协助找到合并更改的正确位置，但是需要作一些额外的工作来整理冲突。请牢记: 当进行一次更新操作后，工作副本的基础文件将会包括每一个项目在执行更新操作时版本库中的版本。如果你在进行更新后再撤销更改，工作副本将返回到版本库的 状态，而不是你开始进行更改前的状态。
本地删除，当更新时有更改进入
开发人员 A 修改 Foo.c 并将其提交至版本库中
开发人员 B 同时在他的工作副本中将文件 Foo.c 改名为 Bar.c，或者仅仅是删除了 Foo.c 或它的父文件夹。
更新开发人员 B 的工作副本会导致树冲突:
在工作副本中，Foo.c 被删除了，但是被标记为树冲突。
如果冲突是由于更改文件名引起的而不是删除文件引起的，那么 Bar.c 被标记为添加，但是其中却不包括开发人员 A 修改的内容。
开发人员 B 现在必须做出选择是否保留开发人员 A 的更改。在更改文件名的案例中，他可以将 Foo.c 的更改合并到改名后的文件 Bar.c 中去。对于删除文件或文件夹的案例中，他可以选择保留包含开发人员 A 更改内容的项目并放弃删除操作。或什么也不做而直接将冲突标记为已解决，那样他实际上丢弃了开发人员 A 的更改。
如果 TortoiseSVN 能够找到被改名为 Bar.c 的原始文件，冲突编辑对话框将可以合并更改。这取决于在什么地方调用更新操作，它也许不能找到原始文件。
本地更改，当更新时有删除进入
开发人员 A 将文件 Foo.c 改名为 Bar.c 并将其提交至版本库中。
开发人员 B 在他的工作副本中修改文件 Foo.c。
或者在一个文件夹改名的案例中...
开发人员 A 将父文件夹 FooFolder 改名为 BarFolder 并将其提交至版本库中。
开发人员 B 在他的工作副本中修改文件 Foo.c。
更新开发人员 B 的工作副本会导致树冲突。对于一个简单的文件冲突:
Bar.c 被当作一个正常文件添加到工作副本中。
Foo.c 被标记为添加(包括其历史记录)并且产生树冲突。
对于一个文件夹冲突:
BarFolder 被当作一个正常文件夹添加到工作副本中。
FooFolder 被标记为添加(包括其历史记录)并且产生树冲突。
Foo.c 被标记为已修改。
开发人员 B 现在需要做出决定是否接受开发人员 A 作出的结构改变并且合并她的更改到新结构下适当的文件中，或者直接放弃开发人员 A 的更改并保留本地文件。
要合并她的本机更改到新布局中，开发人员 B 必须先找出冲突的文件 Foo.c 经过改名/移动后在版本库中的新文件名是什么。可以使用日志对话框来完成这个任务。更改必须要手工合并，因为没有办法自动的或者简单的完成此操作。一旦更改移植完毕，冲突的路径就是多余的并且可以删除。在此案例中，使用冲突编辑对话框中的删除按钮进行清理并将冲突标记为已解决。
如果开发人员 B 认为 A 的更改是错误的，那么在冲突编辑对话框中她必须选择保留按钮。这样就会标记冲突的文件/文件夹为已解决，但是需要手工删除开发人员 A 的更改。又是通过日志对话框帮助追踪哪些文件移动了。
本地删除，当更新时有删除进入
开发人员 A 将文件 Foo.c 改名为 Bar.c 并将其提交至版本库中。
开发人员 B 将文件 Foo.c 改名为 Bix.c
更新开发人员 B 的工作副本会导致树冲突:
Bix.c 被标记为添加(包括其历史记录)。
Bar.c 被添加到工作副本中，其状态为‘正常’。
Foo.c 被标记为删除并且产生一个树冲突。
要解决这个冲突，开发人员 B 必须找出冲突的文件 Foo.c 经过改名/移动后在版本库中的新文件名是什么。可以使用日志对话框来完成这个任务。
然后，开发人员 B 需要决定 Foo.c 的新文件名中的哪一个需要保留 - 开发人员 A 改的那个还是他自己改的那个。
在开发人员 B 手工解决冲突后，使用冲突编辑对话框中的按钮将树冲突标记为已解决。
本地缺少，当合并时有更改进入
开发人员 A 在主干上工作，修改 Foo.c 并将其提交至版本库中
开发人员 B 在分支上工作，将 Foo.c 改名为 Bar.c 并将其提交至版本库中
合并开发人员 A 的主干更改到开发人员 B 的分支工作副本会导致树冲突:
Bar.c 已经存在于工作副本中，其状态为‘正常’。
Foo.c 被标记为缺少并产生树冲突。
要解决这个冲突，开发人员 B 要在冲突编辑对话框中标记文件为已解决，这样就会将其从冲突列表中删除。她接下来需要决定是否将缺少的文件 Foo.c 从版本库中复制到工作副本中，是否将开发人员 A 的对 Foo.c 的更改和合并到改名后的 Bar.c 或者是否通过标记冲突为已解决来忽略更改什么事也不做。
注意，如果你将缺少的文件从版本库中复制到工作副本中然后再标记为已解决，你复制下来的文件将被再次删除。你必须先解决冲突。
本地更改，当合并时有删除进入
开发人员 A 在主干上工作，将 Foo.c 改名为 Bar.c 并将其提交至版本库中
开发人员 B 在分支上工作，修改 Foo.c 并将其提交至版本库中
当文件夹改名时有类似的案例，但是在 Subversion 1.6 中还未被识别...
开发人员 A 在主干上工作，将父文件夹 FooFolder 改名为 BarFolder 并将其提交至版本库中。
开发人员 B 在分支上工作，在她的工作副本中修改 Foo.c 。
合并开发人员 A 的主干更改到开发人员 B 的分支工作副本会导致树冲突:
Bar.c 被标记为添加。
Foo.c 被标记为修改并产生树冲突。
开发人员 B 现在需要做出决定是否接受开发人员 A 作出的结构改变并且合并她的更改到新结构下适当的文件中，或者直接放弃开发人员 A 的更改并保留本地文件。
要合并她的本机更改到新布局中，开发人员 B 必须先找出冲突的文件 Foo.c 经过改名/移动后在版本库中的新文件名是什么。可以通过适用于合并源码的日志对话框来完成这个任务。冲突编辑器仅显示工作副本的日志因为它不知道将哪个路 径的更改合并进来，所以你需要自己找到它。更改必须要手工合并，因为没有办法自动的或者简单的完成此操作。一旦更改移植完毕，冲突的路径就是多余的并且可 以删除。在此案例中，使用冲突编辑对话框中的删除按钮进行清理并将冲突标记为已解决。
如果开发人员 B 认为 A 的更改是错误的，那么在冲突编辑对话框中她必须选择保留按钮。这样就会标记冲突的文件/文件夹为已解决，但是需要手工删除开发人员 A 的更改。又是通过日志对话框帮助追踪哪些文件移动了。
本地删除，当合并时有删除进入
开发人员 A 在主干上工作，将 Foo.c 改名为 Bar.c 并将其提交至版本库中
开发人员 B 工作在分之上，将 Foo.c 改名为 Bix.c 并将其提交至版本库中
合并开发人员 A 的主干更改到开发人员 B 的分支工作副本会导致树冲突:
Bix.c 被标记为正常(未修改)状态。
Bar.c 被标记为添加(包括其历史记录)。
Foo.c 被标记为缺少并且产生树冲突。
要解决这个冲突，开发人员 B 必须先找出冲突的文件 Foo.c 经过改名/移动后在版本库中的新文件名是什么。可以通过适用于合并源码的日志对话框来完成这个任务。冲突编辑器仅显示工作副本的日志因为它不知道将哪个路径的更改合并进来，所以你需要自己找到它。
然后，开发人员 B 需要决定 Foo.c 的新文件名中的哪一个需要保留 - 开发人员 A 改的那个还是他自己改的那个。
在开发人员 B 手工解决冲突后，使用冲突编辑对话框中的按钮将树冲突标记为已解决。
❹ git merge冲突产生原因
没有区别。 origin 其实 一个是alias。简单点说，git remote add origin URL后，你再输入git pull origin master 可以看错 git pull URL master。
merge冲突有好多中原因，最常见的是，你本地一个文件 A，你对它进行了修改，而远程库中的版本也对这个文件进行了修改，就会导致发生冲突。
❺ git怎么知道哪个文件冲突
方法一（推荐使用）：
git pull 出现冲突后丢弃本地冲突文件修改，采用远程文件覆盖本地文件
git checkout [文件路径]
例：git checkout test/src/main/resources/spring-shiro.xml
方法二：
git pull 出现冲突后可以暂存本地修改git stash ,然后git pull 更新代码，git stash list 可查看暂存记录列表，释放本地暂存 git stash apply stash@{0} ，出现冲突文件，找到并解决，然后可以提交git add . 加入索引库，然后本地提交git commit -m '注释' 最后git push到远程
方法三：
1.git pull
更新代码，发现
error: Your local changes to the following files would be overwritten by merge:pom.xml
Please commit your changes or stash them before you merge.
这说明你的pom.xml与远程有冲突，你需要先提交本地的修改然后更新。
2.git add pom.xml
git commit -m '冲突解决'
提交本地的pom.xml文件，不进行推送远程
3.git pull
更新代码
Auto-merging pom.xml
CONFLICT (content): Merge conflict in pom.xml
Automatic merge failed; fix conflicts and then commit the result.
更新后你的本地分支上会出现 (develop|MERGING)类似这种标志
4.找到你本地的pom.xml文件，并打开
你会在文件中发现<<<<<<< HEAD ，======= ，>>>>>>>
这种标记，<<<<<<< HEAD和=======中间的是你自己的代码， ======= 和>>>>>>>中间的是其他人修改的代码
自己确定保留那一部分代码，最后删除<<<<<<< HEAD ，======= ，>>>>>>>这种标志
5.git add pom.xml
git commit -m '冲突解决结束'
再次将本地的pom.xml文件提交
6.git push
将解决冲突后的文件推送到远程
❻ linux的正则表达式能否使用分支符号“|”，和管道符号冲突怎么办
不会冲突啊 比如说你要匹配的内容在11.txt中
find -name “11.txt” | grep -nP "\(010\)(9)\1{7}|010-(9)\2{7}" 11.txt
第一个就是管道命令， 双引号里的是正则表达式的或啊！！
❼ git分支和master上的冲突了
git支持很多种工作流程，我们采用的一般是这样，远程创建一个主分支，本地每人创建功能分支，日常工作流程如下：
去自己的工作分支
$ git checkout work
工作
....
提交工作分支的修改
$ git commit -a
回到主分支
$ git checkout master
获取远程最新的修改，此时不会产生冲突
$ git pull
回到工作分支
$ git checkout work
用rebase合并主干的修改，如果有冲突在此时解决
$ git rebase master
回到主分支
$ git checkout master
合并工作分支的修改，此时不会产生冲突。
$ git merge work
提交到远程主干
$ git push
这样做的好处是，远程主干上的历史永远是线性的。每个人在本地分支解决冲突，不会在主干上产生冲突。
t欧姆定律：I?UR电功公式： W = U I tW = U I t
❽ gitlab 合并分支时 有冲突 怎么解决
不好解决
❾ windows中使用Git如何解决文件冲突
只需到回到windows中对新分支中的文件进行修改再保存即可，之后打开cmd控制台进行git命令操作即可。