SourceTree rebase(变基)的使用

参考资料

  1. 【Sourcetree】コミットを一つにまとめる
  2. 【Sourcetree】リベースする

目录

  • 前提
    • [0.1 merge与rebase](#0.1 merge与rebase)
    • [0.2 merge合并分支](#0.2 merge合并分支)
    • [0.3 rebase合并分支](#0.3 rebase合并分支)
    • [0.4 💥超级注意事项💥](#0.4 💥超级注意事项💥)
  • [一. 代码已提交,未推送,交互式变基](#一. 代码已提交,未推送,交互式变基)
    • [1.1 通过SourceTree操作](#1.1 通过SourceTree操作)
    • [1.2 通过Git命令行操作](#1.2 通过Git命令行操作)
      • [1.2.1 进入命令行终端,指定交互变基版本](#1.2.1 进入命令行终端,指定交互变基版本)
      • [1.2.2 指定需要处理的提交](#1.2.2 指定需要处理的提交)
      • [1.2.3 指定提交信息](#1.2.3 指定提交信息)
      • [1.2.4 查看修改效果](#1.2.4 查看修改效果)
  • [二. 代码已提交,已推送,交互式变基](#二. 代码已提交,已推送,交互式变基)
    • [2.1 通过命令行进行交互式变基,合并提交](#2.1 通过命令行进行交互式变基,合并提交)
    • [2.2 将合并的提交推送到远端](#2.2 将合并的提交推送到远端)
      • [2.2.1 遇到的问题](#2.2.1 遇到的问题)
      • [2.2.2 通过命令行强制推送](#2.2.2 通过命令行强制推送)

前提

0.1 merge与rebase

⏹merge

  • 如果你希望保留分支的历史记录,并且不介意有合并提交。适用于团队合作时保留每个人的工作记录。

⏹rebase

  • 如果你希望保持提交历史的简洁和线性,适用于希望干净历史的项目。

🤔一般而言,如果你在自己的本地分支上进行开发,并且想要保持分支历史记录的干净和整洁,就可以使用git rebase。

而对于多人协作的项目来说,由于需要共享代码库,因此最好使用git merge来避免破坏其他人的历史记录。

0.2 merge合并分支

⏹下图是 merge 合并分支时前后版本变化的情况

  • merge 会创建一个新的合并提交,将两个分支的历史记录保留在一起。
  • 日志保存完整,不管你之前合并进来的那个版本有多少个提交历史,都会被完整的合并到目标分支。
  • 过多的提交合并到主分支之后,主分支的Graph会很乱。

0.3 rebase合并分支

⏹下图是 rebase 合并分支时前后版本变化的情况

  • rebase 会将分支上的更改重新应用在目标分支上,重写提交历史。
  • rebase 方式提交的版本历史是线性的,不会创建新的合并提交,历史记录非常干净。

⏹合并压缩

  • 在rebase 的时候还可以使用 squash 参数来压缩提交记录。
  • 例如下图,Feature 1 分支的 A、B、C 三个提交记录,使用 rebase squash 后会在主分支变为一个提交记录 F。

0.4 💥超级注意事项💥

❌❌❌❌❌❌❌❌❌❌❌❌❌❌❌❌❌

❌❌❌避免在公共分支上使用 rebase ❌❌❌❌

❌❌❌❌❌❌❌❌❌❌❌❌❌❌❌❌❌

⏹不要在已经推送到公共仓库的分支上使用 rebase:变基会重写提交历史,这会使其他基于这些提交的工作分支出现冲突。

如果你在公共分支上使用 rebase,其他开发者可能会遇到合并冲突,并且需要强制拉取和合并他们的工作,这会带来很多不必要的麻烦。

⏹如果将本地分支的代码已经推送到远端,并且远端的代码并没有被合并到任何分支中,并且没有任何人基于你的分支进行开发,

此时rebase操作不会对别人的开发带来影响。


一. 代码已提交,未推送,交互式变基

1.1 通过SourceTree操作

🤔变基可以将多次本地提交合并为一次提交,简化提交履历。

💥注意:多次提交只是提交到本地Git仓库,并没有推送到远端仓库。

⏹如下图所示,我们分3次提交了代码到本地Git仓库,这3次提交都只是添加了console.log语句,

因此可以合并为一次提交然后推送到远端仓库

⏹交互式变基操作如下所示,选中要合并的提交的前一次提交,点击交互式变基功能,

然后将多次提交合并为一次。

1.2 通过Git命令行操作

⏹如下图所示,我们分3次提交了代码到本地Git仓库,这3次提交都只是添加了console.log语句

这次我们使用Git命令行的方式,将这三次提交合并为一次。

1.2.1 进入命令行终端,指定交互变基版本

⏹通过SourceTree的命令行模式进入Git命令行终端

⏹指定交互变基的版本为最近的3次提交
git rebase -i HEAD~3

1.2.2 指定需要处理的提交

⏹如下图所示,在vim模式下处理指定的提交

  • pick:保留该提交。
  • reword:保留该提交,但允许你修改提交信息。
  • edit:保留该提交,但在此提交暂停,允许你进行更改。
  • squash:将此提交与前一个提交合并,并保留两个提交的信息。
  • fixup:将此提交与前一个提交合并,但丢弃此提交的信息。
  • drop:删除该提交。

⏹如下图所示,指定后两次提交与第一次提交合并,同时丢弃后两次的提交信息

  • ffixup的简写

同时指定要修改提交的消息的版本

  • rreword的简写

⏹修改完成之后,在vim模式下按下ESC之后,输入wq保存

1.2.3 指定提交信息

⏹如下图所示又进入编辑提交信息的界面,编辑完成之后,同样在vim模式下按下ESC之后,输入wq保存

⇓⇓⇓⇓

1.2.4 查看修改效果

⏹如下图所示,提交记录变成了一个,提交更加整洁了!


二. 代码已提交,已推送,交互式变基

2.1 通过命令行进行交互式变基,合并提交

⏹如下图所示,有3次打印消息,都已经推送到远端。

⏹在git终端通过下面的命令对最近3次提交进行交互式变基。

git rebase -i HEAD~3

⏹效果如下

2.2 将合并的提交推送到远端

2.2.1 遇到的问题

⏹ 直接推送的话,会发生如下图所示的错误

2.2.2 通过命令行强制推送

git push origin 分支名称 --force

⏹效果如下

相关推荐
Lojarro2 小时前
【后端】版本控制
git·subversion
MengYiKeNan7 小时前
Git配置与使用
git
shall_zhao7 小时前
修改仓库中子模块并推送到远程仓库的指定分支
git
鱼钓猫的小鱼干10 小时前
Git 安装
git
子洋10 小时前
迁移 Gitlab 到 Forgejo
前端·git·后端
爱串门的小马驹12 小时前
git,ssh免密公钥配置,gitee为例,GitHub,gitlab同理
运维·git·ssh
小小小妮子~12 小时前
掌握Git分布式版本控制工具:从基础到实践
分布式·git
前端与小赵17 小时前
什么是Git,有什么特点
git
写bug写bug17 小时前
如何使用 .gitignore 文件
前端·git·后端