git 合并分支

梗概:

有两种合并方式:

• child::

  merge

  基本概念

  • child::影响当前分支原则

  梗概

  将两个分支上的末端快照合并为一个分支

  冲突

  没有冲突(conflict)的合并:

  Git会自动合并不冲突的快照

  有冲突的合并:

  需要人为编写合并后的快照, 当然只需要针对冲突的地方

  在图形化Git工具GitKraken中如此表示合并:

  快照的演变顺序为从下到上

  使用教程

  会保留合并进来的分支

  实例

  这时已经删除了B分支：

  • 被删除的B分支仍然被保留，并且会被算作A分支的组成部分

  命令行操作

  child::

  命令行git merge

  1. 梗概:

  将分支B合并到分支A上, 一般在分支A上生成一个提交, 分支A指向这个提交

  2. 步骤:

  1. 先切换到分支A
  2. git merge B
     1. 表示merge B into 当前分支

  指向原始笔记的链接

  指向原始笔记的链接

• child::

  git rebase

  基础

  适用范围:

  1. 作用:

  • 合并两个分支, 并且不会留下合并提交记录

  2. 场景:

  • child::rebase无痕合并别人最新的commit

  3. 不适用场景:

  • 共享分支上不要用rebase
    • 即不要切换到共享分支上用rebase，但是别的分支rebase共享分支还是可以的（因为不会影响到目标分支）
  • 当前分支已经落后于目标分支太久了
    • 因为rebase需要一个一个commit解决冲突，只要中间有一个冲突处理不好，则会影响后面所有的commit
    • 直接用merge更好

  梗概:

  • 指定某个提交记录为当前分支的基, 旧的基就变成两个分支的公共部分
    • 简而言之, 就是改变两条分支的分叉点
  • 只影响当前分支，不影响目标分支

  rebase的机制

  • 把当前分支基前面的提交全部暂时移除，这时当前分支头指向旧基
  • 把指定的分支的提交拉进当前分支的顶部，产生新基
  • 把原来移除的commit逐个进行提交，遇到冲突时，修改原来的commit，以处理冲突

  对远程仓库的影响

  • rebase就会导致本地与远程分支分散
    • pull分散的分支实际上就相当于git merge 远程分支
    • 所以一般rebase后会使用git push的—force-with-lease模式将本地分支覆盖到远程分支

  当别的分支基于的分支被rebase之后

  child::当基础分支被rebase变更后

  处理冲突

  • 当前分支rebase别的分支的时候，在新基的基础上提交第一个commit的时候，发生了冲突
    • 这时current是新基，incoming是本来有的第一个commit
    • rebase是用来与目标分支保持同步，rebase前不要提前在当前分支上commit来手动保持同步

  示例

  • 当前feat分支做了一些功能，但别人已经帮自己做了一些功能，并提前合到master分支上了
  • 这时就不要在当前分支上revert自己做过的一些功能了
  • 这时应该通过git 合并分支，把master分支合进来
    • 如果选择rebase合并，则在相同的功能上出现冲突的时候，current是master的head，incoming是自己分支上的提交（即自己那未完成的功能）
    • 以master为准，修改自己的commit，这样一条一条的处理冲突
      • 所以其实这种情况最好还是使用merge

  操作:

  1. 在图形化git工具上:

  • child::GitKraken

  实例

  示例之一

  child::

  git rebase实验1

  两个分支rebase前的情况

  

  1. master分支rebase到test3提交的情况

  

  2. A分支rebase到test5提交的情况

  

  三个共基分支

  1. 未rebase之前

  

  2. master分支rebase到test3提交

  

  指向原始笔记的链接

  指向原始笔记的链接