git merge 原理 ,wiz 等云同步原理

git pull --rebase 是把本地的新增diff,一次次commit的, 只要第一次commit冲突,,哪怕你三次commit的最终整体diff是和pull过来不冲突,也没有用.修复完冲突后,需要continue.

merge是反过来,一次次把server上 commit,待测试  MERGE_HEAD

idea中. 左边是 本地,中间是合并结果. (红色代表冲突) 右边是merge过来的.

opendiff中  <--- 剪头指向谁.代表使用谁. 红色代表冲突. 结果再最小面.

 

云同步普通更新:

如果每次更新都保存完整的文件快照. 那么会冗余存储太多数据. 如果只保存diff, 那么一旦很多次更新后,要计算N次更新后的文本,就要通过原始文件一次次diff更改过来.

计算量过大. 故需要100次diff后保存一个快照文件.

在说merge 冲突后:

 git merge后,一个commitId会有两个父亲. 导致 diff会有两份(或者实现为一份快照,丢失diff.)

 

merge时,

1.当前的HEAD 就是 merge 来源分支的源 .那么就叫fast forwd (Git详解之三 Git分支 含图片 http://www.open-open.com/lib/view/open1328069889514.html )

2. 冲突时,三方对比. 但是ui工具里都不会把共同的源展现出来.

    首先把得到共同源的所有文件快照(计算得出),local和 merge来源分支的快照. 然后各自和源进行diff ( 妙: 不需要把n次的commitId diff进行合并. 有可能负负得正,直接把最终结果拿去diff就好了. 这个diff肯定是N个diff的总和.). 看看是否有对同一行的变更.如果是那么就产生冲突了.

不

 

merge冲突乱解决后擦屁股方案:

      还是通过commitId 新建新分支. git checkout  -b "newBranchName" commitId .

      把merge的两个父亲源一起checkout出来. 然后本地进行merge .然后和已经提交的merge版本号文件进行比较.