Git 的 变基主要是使git 的提交记录变得更加简洁。下面通过三个场景来理解rebase的应用。
在开发一个功能时,可能需要几天,每天都提交了更改,最后完成整个功能,但是我们的提交记录中有多个版本,如V1,V2,V3 和 V4 版本,为了提交记录简洁,可以通过变基,将多个提交记录整合成一个记录,如下图:
新建个RebaseDemo文件夹,用于模拟:
模拟连续提交四个版本:
执行“git rebase -i 指定版本号” 命令可以将HEAD对应的当前最新版本号与指定的版本号之间的所有版本(包括v2,v3,v4)变基合并为一个新的版本号。
除了上面的方式还可以采用简单的方式:执行“git rebase -i HEAD~3” 命令代替上面的命令, “HEAD~3” 表示从当前最新的版本号开始,往前的三个版本,进行变基。 如下:
执行 “git rebase -i HEAD~3”命令,出现如下:
根据提示信息,我们编辑一下版本v2和v3的信息,将pick 改成“s”, 然后按下“esc”键,退出编辑,然后输入“:wq” 保存修改,如下:
说明:把“pick”改成“s”,表示把加“s”的版本合并到上一个版本,比如这里是把“v4” 合并到“v3”, 把“v3”合并到“v2”,最终是把v3和v4都合并到了v2.
然后“enter” 执行保存,然后进入提示信息页面,这里展示了v2,v3和v4的原来提交信息,这个界面可以用于编辑合并后的提交信息,如下:
编辑合并的提交信息如下:
提示:按键盘“dd”可以快速删除一行文本。
接下来就变基成功了,如下:
然后看log:
发现变基合并完成。
发现:合并后的提交其实是相当于一个新的提交,因为我们可以从版本序列号中看到其采用了新的序列号,如下:
合并前:
合并后:
注意:合并记录时建议不要合并已经提交到远程仓库的版本。
当分支dev开发并提交了新功能V3,主分支master上也提交了新的功能,我们要把dev分支合并到master分支,正常情况下,我们的最终分支结构如下图:
这种merge结构是没问题的,也是常用的,但假如,我们想要提交记录更加简洁,即像下图这种结果,我们可以采用rebase变基方式合并。
首先我们来看一般情况下的合并方式(merge方式):
接着场景一中的提交结果,我们继续实践场景二。
当前在master分支上,接下来创建dev分支,并切换到dev分支:
在dev分支上开发dev.txt文件并提交版本V3,如下:
接着切换回master分支,并在master分支上新增了master.txt并提交版本V4,如下:
接下来,我们假设用以前的merge方式,将dev分支合并到master分支,如下:
编辑合并信息,这里是v5版本:
合并完成后,我们可以看到master上有所有的提交记录:
接下来,执行“git log --graph”命令,看一下提交结构图(左边的流线图),如下:
可以执行“ git log --graph --pretty=format:"%h %s" ” 命令(%h 表示版本号的哈希值,%s表示提交信息,即是只显示哈希值和提交信息)。简化一下提交记录:
上面模拟完成了一般情况下的合并方式(merge方式),接下来使用rebase合并方式(变基方式):
首先因为刚刚dev提交到了master,在继续dev分支开发前,先把mster的代码也合并到dev分支:
接下来在dev上新建文件dev2.txt,并提交版本V6:
再切回master分支上新建master2.txt,并提交版本V7:
接下来要合并版本,这里采用rebase变基方式。 首先切回到dev分支(这里跟merge方式不同),接下来在dev分支执行“git rebase master” 命令:
接下来再切换回master分支,把dev分支合并(merge 命令)到master分支:
然后执行“ git log --graph --pretty=format:"%h %s" ” 命令,看一下最终的提交结构:
发现提交的结构是合在一条线上了。
至此,场景二实践完成。
假如在公司开发了功能A的部分内容,但是没有提交到远程仓库,回到家继续开发功能A的其他内容,然后把家里开发的内容提交到了远程仓库。第二天再回到公司,继续开发功能A之前,要把在家开发的功能A的内容从远程仓库拉下来,一般我们会用“git pull” 命令,执行该命令是一般的做法,但是在提交结构中会看到有分叉。假如不想显示分叉,可以把“git pull origin 分支名称” 命令,拆分成用“git fetch origin 分支名称” 命令和“git rebase origin/分支名称” 命令。
此场景不做实践演示,基本操作命令如前两个场景。
有时,在执行rebase时会产生冲突,接下来就要先解决冲突,解决完冲突后执行“git add”命令,在接着执行“git rebase --continue” 命令,如下案例:
接着上面的示例,在master和dev分支上编辑同一个文件,模拟产生冲突的场景:
在dev分支上编辑1.txt文件内容:
vim命令编辑1.txt文件:
提交dev分支的修改:
切换到master分支,编辑同一个文件1.txt:
提交master上的更改:
切换到dev分支,执行rebase变基命令合并dev分支到master分支,然后产生了冲突:
解决冲突:
修改:
修改完后,查看状态:
执行“git add” 后再执行“git rebase --continue”:
执行后进入信息编辑界面:
编辑变基合并的信息:
接下来变基冲突完成,查看结果:
本变基实例完成。
Beyond Compare 工具可以用于快速解决冲突。
第一步安装Beyond Compare如下:
官网地址:https://www.scootersoftware.com/https://www.scootersoftware.com/
或者直接其他方式下载:
修改好安装目录,其它采用默认值,一路安装下去,最终完成。
手动打开界面如下:
第二步,在git中配置beyond compare, 需要执行如下命令:
git config --local merge.tool bc4
git config --local mergetool.path 'bc的安装目录'
git config --local mergetool.keepBackup false
制造冲突:
冲突出现,启动beyond compare工具:
发现beyond compare配置出问题了,没有正常打开工具。
解决问题:
既然“--local”本项目方式配置失败,那先换个思路,尝试配置全局变量“--global”, 配置命令如下:
git config --global merge.tool bc4
git config --global mergetool.bc4.cmd "\"D:\\xxx\\BComp.exe\""
git config --global mergetool.bc4.trustExitCode true
git config --global mergetool.keepBackup false
配置全局变量前,先删除刚刚错误的配置,然后配置全局变量,如下:
然后执行“git mergetool”命令,成功打开beyond compare 工具:
成功打开了工具,但是问题又来了,没有自动识别冲突。
接下来尝试在user/admin 下的全局配置文件 “.gitconfig” 中完善配置,配置内容如下:
保存后执行“git mergetool”如下命令, 成功打开了冲突文件对比界面,如下:
总结全局配置如下:
[diff]
tool = bc4
[difftool]
prompt = false
[difftool "bc4"]
cmd = \"D:\\BeyondCompare\\BeyondCompare4\\BComp.exe\" \"$LOCAL\" \"$REMOTE\"
[merge]
tool = bc4
[mergetool]
prompt = false
[mergetool "bc4"]
trustExitCode = true
cmd = \"D:\\BeyondCompare\\BeyondCompare4\\BComp.exe\" \"$LOCAL\" \"$REMOTE\" \"BASE\" \"$MERGED\"
[mergetool]
keepBackup = false
全局配置的方式成功打开了Beyond compare工具, 接下来回过头来尝试解决本项目配置未成功的文件(即最初的配置“--local” 时不能打开beyond compare的问题),尝试如下:
首先删除全局中的配置:
删除后,开始配置“--local”参数,进入项目中的“.git”目录,编辑config文件如下:
保存后,回到项目目录,执行“git mergetool”命令,调用beyond compare,如下:
成功调用Beyond Compare 工具, 问题解决。
注:鉴于Beyond Compare需要收费,上面安装Beyond Compare是没有破解,所以会发现打开的界面中几个重要的菜单是失效的。如果要正常使用,需要破解先,这里主要是理解怎么跟git结合使用,故不做破解说明。
至此,本文的变基实例已经全部完成。
本文重要命令总结:
1. 变基(简洁提交记录):
git rebase 分支名称
2. 记录的图形展示:
git log --graph --pretty=format:"%h %s"