常见git解决冲突

git的常见冲突

git最常见的冲突是merge一个分支时，产生的冲突。还有一个不常见的冲突是stash pop产生的冲突。

产生冲突的原因

分支合并: 如果你在两个不同的分支中，对同一个文件的同一个部分进行了不同的修改，Git就没法干净的合并他们，在合并他们的时候就会产生合并冲突。此时Git做了合并，但是没有自动地创建一个新的合并提交。Git会暂停下来，等待你去解决合并产生的冲突。解决冲突后使用 git add 将该文件标记为以解决，解决完所有冲突文件后。使用git commit来完成合并提交。
stash pop: 在我们 git pull同步远程分支代码时，git可能会提示 本次同步代码会导致工作区的修改内容被覆写，需要我们stash或者commit。此时我们git stash然后拉取代码。当我们使用git stash pop发现产生冲突。原因也是自己工作区的修改和拉取下来的代码对同一个文件的同一个部分进行了不同的修改。同样解决冲突，git add标记为以解决，git commit -m

解决冲突的小技巧

merge产生的冲突关键字是HEAD和被合并分支的名字。这样可以快速定位到产生冲突的地方，解决冲突时应该注意到底应该保留那个分支的文件。 解决完冲突后应该使用编译器编译一下看是否通过，防止没有解决完冲突或者出现了其它的情况。如果冲突的文件很多，可以使用git add .来标记已经解决所有冲突文件，使用git commit合并提交时，此时已经有了默认的提交信息，如果你不想添加一些额外的信息。直接wq推出即可。导致merge合并分支产生的冲突已经解决，此时因为合并分支和修复冲突产生的合并commit往往本地库领先远程库对应分支好几个commit，所以往往需要push一下。
stahs pop产生的冲突关键词是stashed changes updated upstream。解决冲突时，需要注意到底保留自己的修改还是别人的修改。此时如果有远程分支应该git push一下。

git合并策略

参考博客
在git合并的时候，当仅仅在一个分支上合并另外一个分支时。在合并产生冲突时我们对于冲突的commit往往只需要做二选一。只保留本身分支的内容或者只保留其它分支的内容。这样就避免了手动去修改避免造成错误。
git的合并策略有如下几种

1. recursive 默认合并策略 递归三路合并算法
2. resolve 三路合并算法
3. octopus
4. ours
5. subtree
   当使用 recursive策略时，还可以指定一些额外的参数。
6. ours 如果合并没有产生冲突，那么与默认合并结果相同，如果发生冲突，将自动应用自己这一方的修改。
7. theirs 与ours相反，如果产生冲突，将自动应用来自其它人的修改(也就是merge参数中指定的那个分支的修改)
8. patience
   例子
   注意 使用下面的命令，使用参考博客的命令会有问题。
   当前处于 test 分支进行开发，想要同步develop的代码

git merge develop -s recursive -X theirs

因为默认合并策略就是 recursive ，所以可以简写成

git merge develop -X theirs

gitpro中的参考例子

git merge 和 rebase 的区别

快进(fast-forward),当你试图合并两个分支时，如果顺着一个分支走下去能够到达另一个分支，那么Git在合并两者的时候，只会简单的将指针向前推进(指针右移)，因为在这种情况下的合并操作没有需要解决的分歧—这就叫做 “快进(fast-forward)”
merge git在使用merge合并两个分支时，会使用到简单的三方合并，及两个分支最新的commit和两个分支共同的祖先commit进行一个合并


rebase(变基)
可以使用rebase命令将提交到某一分支上的所有修改都移动到另一个分支，就好像重新播放一样。这样做的好处是，使提交历史看起来就像是一条直线一样，并且可以减少合并分支产生的commit。因为git 在使用merge合并分支时会产生一个新的合并提交的commit。而使用rebase将一个分支的修改应用到其它分支上，就不会产生新的合并提交。而是快进(fast-forward)

其它

vim 快速跳转到文本最后 shift + G ，跳转到文本开头 gg