git_关于git冲突的产生原因和解决对策

文章目录

• git冲突产生的原因:
• • 首先,冲突是两个分支之间因为文件内容分歧产生的一种不理想的情况(但也没有必要畏惧)
  • • 只有一个本地分支的情况下是不会又冲突的.(只有一个分支的情况下没有冲突可言)
• 不冲突(尽可能减少冲突)的习惯是,修改文件之前先merge 别的分支
• 一般情况下冲突后的文件中会出现:
• 解决冲突
• 在pull过程中可能遇到冲突:的单方解决流程(比如自己管理的两个分支)
• • 为了让其他分支接受冲突解决后的版本,您可能需要用到强制merge选项
  • • 强制merge:

git冲突产生的原因:

在什么时候会引发冲突:
有时候合并操作不会如此顺利。
如果你在两个不同的分支中，对同一个文件的同一个部分进行了不同的修改，Git 就没法干净的合并它们。

首先,冲突是两个分支之间因为文件内容分歧产生的一种不理想的情况(但也没有必要畏惧)

幸运的是,我们有理由相信在分工明确的情况下(这样产生冲突的概率会尽可能的小),我们可以将原因归为我们对开发伙伴对文件的修改的信息得知的滞后(这也为减少冲突提供了优化git使用习惯的方案)

只有一个本地分支的情况下是不会又冲突的.(只有一个分支的情况下没有冲突可言)

任何的修改和差异都不会产生歧义(指基于git的歧义/多人之间不同的意见)
冲突可以两个分支在merge时发生的不理想的一种情况.
具体是两个已经提交的分支的相同文件相同位置的不同操作进行了合并(merge).

不冲突(尽可能减少冲突)的习惯是,修改文件之前先merge 别的分支

差异不一定导致冲突,但是冲突必定基于差异(比较明显的歧义),因此,先将别的分支merge到当前分支,可以尽可能减少冲突;

最直接的效果就是你的同事前些时候在你想要修改的文件file上也做了你未知的修改(这些修改的位置location你也未知,而且是先于你的修改),此时,如果你不将对方的分支及时的merge到你的分支中,就急于对当前分支中的文件file做修改,那么极可能引发冲突;

而如果你在修改前将对方的分支merge进来,这样的情况就可能被化解了(你及时的获取了对方的进度信息)
对于一个人管理的两个(或多个)分支,也是类似的

尽管信息滞后,但只要同一时期内,只有一方修改文件file,那么对于滞后方在下一次的merge时也不会发生冲突;(关键是落后的一方能自觉地将对方的分支合并入自己的分支后再开始工作)

一般情况下冲突后的文件中会出现:

解决冲突

在pull过程中可能遇到冲突:的单方解决流程(比如自己管理的两个分支)

大致流程:

在这些过程中,不时的用git status 来获取提示是good idea

为了让其他分支接受冲突解决后的版本,您可能需要用到强制merge选项

强制merge:

1. 通过git merge实现
   branch_unfixed分支合并branch_fixed分支，即,强制使用冲突已修复的分支覆盖冲突未修复的分支)
   git checkout <branch_unfixed>
   git merge --strategy-option=theirs <branch_fixed>
   
2. 通过git reset实现
   git checkout <branch_unfixed>
   git reset --hard <branch_fixed>