当前位置:   article > 正文

git rebase 和 git merge 的区别_gitrebase和gitmerge

gitrebase和gitmerge

git rebase 和 git merge 一样都是用于从一个分支获取并且合并到当前分支,但是他们采取不同的工作方式,以下面的一个工作场景说明其区别
场景:

 如图所示:你在一个feature分支进行新特性的开发,与此同时,master 分支的也有新的提交。
  • 1

在这里插入图片描述
为了将master 上新的提交合并到你的feature分支上,你有两种选择:merging or rebasing

merge

执行以下命令:

git checkout feature
git merge master
  • 1
  • 2

或者执行更简单的:

git merge master feature
  • 1

那么此时在feature上git 自动会产生一个新的commit(merge commit)
在这里插入图片描述

  • marge 特点:

    自动创建一个新的commit
    如果合并的时候遇到冲突,仅需要修改后重新commit
    优点:记录了真实的commit情况,包括每个分支的详情
    缺点:因为每次merge会自动产生一个merge commit,所以在使用一些git 的GUI tools,特别是 commit比较频繁时,看到分支很杂乱。

rebase

本质是变基 变基 变基
变基是什么? 找公共祖先

执行以下命令:

git checkout feature
git rebase master
look like this:
  • 1
  • 2
  • 3

在这里插入图片描述

  • rebase 特点:会合并之前的commit历史
  • 优点:得到更简洁的项目历史,去掉了merge commit
  • 缺点:如果合并出现代码问题不容易定位,因为re-write了history

合并时如果出现冲突需要按照如下步骤解决
修改冲突部分

git add
git rebase --continue
  • 1
  • 2

(如果第三步无效可以执行 git rebase --skip)
不要在git add 之后习惯性的执行 git commit命令

The Golden Rule of Rebasing rebase****的黄金法则

never use it on public branches(不要在公共分支上使用)
比如说如下场景:如图所示
在这里插入图片描述
如果你rebase master 到你的feature分支:

rebase 将所有master的commit移动到你的feature 的顶端。问题是:其他人还在original master上开发,由于你使用了rebase移动了master,git 会认为你的主分支的历史与其他人的有分歧,会产生冲突。

所以在执行git rebase 之前 问问自己,

会有其他人看这个分支么?
if YES 不要采用这种带有破坏性的修改commit 历史的rebase命令
if NO ok,随你便,可以使用rebase
  • 1
  • 2
  • 3

Summary 总结

如果你想要一个干净的,没有merge commit的线性历史树,那么你应该选择git rebase
如果你想保留完整的历史记录,并且想要避免重写commit history的风险,你应该选择使用git merge

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/空白诗007/article/detail/760936
推荐阅读
相关标签
  

闽ICP备14008679号