git merge和git rebase区别笔记

初始场景:
基于正常的开发分支修改几个小bug,然后在合并到开发分支上。

git merge

git checkout feature
git merge hotfix
或者
git merge hotfix feature

合并后的节点会按照commit时间顺序排列。
git merge操作会在当前分支上生成一个新的commit节点,并保留所有的操作历史节点,对问题的追溯很有益处,但是会产生大量无用commit节点,使提交历史记录很冗长。
如下图:
这里写图片描述

git rebase

git checkout feature
git rebase hotfix

rebase操作后的历史并不会按commit时间顺序排列。
rebase操作会找出当前分支(feature)的所有修改点,并将其生产一系列布丁(4-6-8);然后以被rebase分支(hotfix)最后一个节点(9)为开始点,将feature上生成的布丁应用到hotfix上(1-2-3-5-7-9-4-6-8)。
如上描述,rebase操作能使提交历史更干净美观,可忽略很多不必要的节点;但是这样等同于重写commit历史记录,可追溯性较差。
如下图:
这里写图片描述

另外,rebase提供了一些补充操作

git checkout feature
git rebase -i hotfix

执行以上命令会弹出编辑框,如下,(IDE可能会有GUI交互窗)。

  14 pick 9fa8fe5c4 add 1
  15 pick 94e3c2cb7 add 2
  16 pick 1bc1c9152 add 3
  17 
  18 # Rebase 6041e1b91..5b88fbfaa onto 6041e1b91 (16 commands)
  19 #
  20 # Commands:
  21 # p, pick = use commit
  22 # r, reword = use commit, but edit the commit message
  23 # e, edit = use commit, but stop for amending
  24 # s, squash = use commit, but meld into previous commit
  25 # f, fixup = like "squash", but discard this commit's log message
  26 # x, exec = run command (the rest of the line) using shell
  27 # d, drop = remove commit
  28 #
  29 # These lines can be re-ordered; they are executed from top to bottom.
  30 #
  31 # If you remove a line here THAT COMMIT WILL BE LOST.
  32 #
  33 # However, if you remove everything, the rebase will be aborted.
  34 #
  35 # Note that empty commits are commented out

解释下几个参数:

  • pick就是cherry-pick
  • reword 就是在cherry-pick的同时你可以编辑
  • commit message,它会在执行的时候跳出一个界面让你编辑信息,当你退出的时候,会继续执行命令
  • edit 麻烦点,cherry-pick同时 ,会停止,让你编辑信息,完了后,你要用git rebase –continue命令继续执行,相对上面来说有点麻烦。
  • squash,合并此条记录到前一个记录中,并把commit message也合并进去 。
  • fixup ,合并此条记录到前一个记录中,但是忽略此条commit message

我们可以使用-i参数达到重新排序commit历史、编辑提交信息、删除无用提交、合并同问题提交等操作。

rebase使用原则:一旦分支中的提交对象发布到公共仓库,就不要对该分支进行rebase操作。

参考:

### Git MergeGit ReBase区别及使用场景 #### 区别 1. **提交历史的处理方式** - `git merge` 创建一个新的合并提交,将两个分支的更改合并到一个新的提交中。这种方式会保留分支的历史记录,清晰地展示分支的合并过程[^4]。 - `git rebase` 通过移动分支指针来实现合并,它将当前分支上的提交按照顺序逐个应用到目标分支上,并将目标分支指针移动到最新的提交上。这种方式使得提交历史更加线性,但会丢失分支结构信息[^4]。 2. **冲突解决** - 在 `git merge` 中,如果发生冲突,Git 会在创建合并提交时提示用户解决冲突。解决后继续完成合并操作[^3]。 - 在 `git rebase` 中,冲突可能发生在每个提交的重放过程中。因此,`rebase` 的冲突解决过程通常更复杂,需要逐个解决每个提交中的冲突[^4]。 3. **历史记录的可读性** - `git merge` 的历史记录包含分支的合并点,适合用于需要保留分支开发过程的场景。 - `git rebase` 的历史记录更加线性,适合用于希望保持代码库整洁、避免过多分支结构的场景。 #### 使用场景 1. **Git Merge 的适用场景** - 当希望保留完整的分支历史,以及显示出分支合并的细节时,选择 `git merge`[^2]。 - 在团队协作中,如果需要清晰地看到不同功能分支的开发过程合并点,`git merge` 是更好的选择[^4]。 2. **Git Rebase 的适用场景** - 如果希望保持更线性、整洁的提交历史,并且能够容忍更复杂的冲突解决过程,选择 `git rebase`[^2]。 - 在开发过程中,为了保持提交历史的整洁线性,经常使用 `rebase` 来更新本地分支到最新状态。 - 在个人开发或小型团队中,当不需要保留分支结构时,`rebase` 可以提供更简洁的历史记录。 #### 示例代码 以下为 `git merge` `git rebase` 的基本使用示例: ```bash # 使用 git merge 合并分支 git checkout main git merge feature-branch # 使用 git rebase 重写提交历史 git checkout feature-branch git rebase main ``` --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值