前2天群里发了张git历史图,如下:

根据提交历史,可以看出图中所有分支合并都采用merge的方式,具体merge是怎么操作的,可以阅读下边文章。


根据项目上的需求,如果要求git提交历史是比较简单的一条时间线,可以使用rebase的合并;如果没有这个要求,可以使用merge合并,其分支树是网状结构,但每个提交也都是比较明确清晰的。他们的区别,可参考git merge与 git rebase区别及实例

  •        rebase合并:本质是先取消自己的提交,临时保存,然后把当前分支更新到最新的origin分支,最后应用自己的提交。
  •        merge合并:将两个分支进行合并提交。

 rebase合并

(1)远程fetch的代码,本地没有修改,直接rebase即可;

(2)若本地对文件修改,没有add,rebase时,会提示“Cannot rebase: You have unstaged changes.Please commit or stash them.”,add后没有commit,会提示“Cannot rebase: Your index contains uncommitted changes.Please commit or stash them.”。commit后,如果没有修改同一文件,rebase不会冲突。

(3)若本地对同一个文件修改,commit后,rebase时,有2种情况:

    ① 如果没有修改同一位置,则可以rebase,不会产生冲突;

    ② 如果修改了同一处,则rebase时会出现冲突,也不用怕,此时git已经进行了合并,只是没有应用自己的提交,解决办法:修改冲突的文件,然后执行add和rebase –continue操作即可。如果不小心,执行完add后执行了commit,此时本地仓库HEAD处于游离态,如何解决,后续再补充。

 merge合并

merge合并也可能存在冲突,解决冲突与rebase相似,处理完冲突文件后,重新提交即可。

举例说明

假设现在有3个人(git1、git2、git3)合作开发一个项目。

(1)git1创建项目,添加index.html文件,在index文件中添加“create by git1”,提交;

         git2拉取文件后,在index中添加“add by git2”,提交;

         git3拉取文件后,在index中添加“add by git3”,提交;

         git1拉取最新代码后,在index中添加“add by git1  add1 by git1”,如下:

         

        提交远程仓库,分支树如下:

  

(2)git2在index文件中添加“add 1 by git2”,以实验冲突

  此时分支树如下:

  

  

  提交后:

  

  然后执行rebase发生冲突:

  

  分支树为(此时分支为(no branch, rebasing dev)):

  

  

  打开冲突文件,冲突部分是以 <<<<<<<<<< =============  >>>>>>>>>>标识,将此部分代码进行处理,处理后的文件为:

  

  执行add和rebase –continue

  

   rebase结束,分支树为:

  

  

  提交远程后,最终分支树如下:

  

(3)git3的index文件如下:

   

       将index文件中的第一行修改为“create by git1  modifed in another place”,提交。

   

       从远程拉取最新文件,执行rebase

       

       最终结果如下:

  

  

  

(4)git1创建了一个index2.html文件,提交后push,远程拒绝push,原因是本地不是最新版本,需要更新后提交,拉取最新文件。

   

  git1执行merge操作,最终分支树如下:

  

  

总结

  • 修改同文件不同处,rebase和merge合并不会冲突
  • 修改同文件同一处,合并会冲突,解决方式:rebase,解决冲突,执行add+rebase continue;merge,解决冲突,重新提交

 转载请注明出处,谢谢

版权声明:本文为shuimuzhushui原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/shuimuzhushui/p/9022549.html