文章目录
git的常见冲突产生冲突的原因解决冲突的小技巧git合并策略git merge 和 rebase 的区别其它
git的常见冲突
git最常见的冲突是merge一个分支时,产生的冲突。还有一个不常见的冲突是stash pop产生的冲突。
产生冲突的原因
分支合并: 如果你在两个不同的分支中,对同一个文件的同一个部分进行了不同的修改,Git就没法干净的合并他们,在合并他们的时候就会产生合并冲突。此时Git做了合并,但是没有自动地创建一个新的合并提交。Git会暂停下来,等待你去解决合并产生的冲突。解决冲突后使用 git add
解决冲突的小技巧
merge产生的冲突关键字是HEAD和被合并分支的名字
git合并策略
参考博客 在git合并的时候,当仅仅在一个分支上合并另外一个分支时。在合并产生冲突时我们对于冲突的commit往往只需要做二选一。只保留本身分支的内容或者只保留其它分支的内容。这样就避免了手动去修改避免造成错误。 git的合并策略有如下几种
recursive 默认合并策略 递归三路合并算法resolve 三路合并算法octopusourssubtree 当使用 recursive策略时,还可以指定一些额外的参数。ours 如果合并没有产生冲突,那么与默认合并结果相同,如果发生冲突,将自动应用自己这一方的修改。theirs 与ours相反,如果产生冲突,将自动应用来自其它人的修改(也就是merge参数中指定的那个分支的修改)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
发表评论