每天对自己多问几个为什么,总是有着想象不到的收获。 一个菜鸟小白的成长之路(copyer)
rebase
:变基
目的: 就是让git的提交记录变得更加的简洁
。
使用场景1:简化提交记录
举例: 组长给你安排了一个大的功能模块(比如说购物车功能),让你自己独立的开发,给你五天的时间。那么你就会从dev
分支上,在单独拉去一个分支,开发购物车功能,你每天都会使用git commit
来记录你每天的工作量,五天就会产生五个commit,当你交给你组长的时候,这五个commit对你组长来说,是没有用的,他只需要你的最后一次代码提交,所以,你就可以把无用的commit进行合并。
简单举例:
// 这里就把master想象成开发分支, dev想象开发的购物车的分支
git init
touch master.js
git add .
git commit -m 'master分支上的最初版本'
// 拉取一个开发购物车分支
git checkout -b dev
// 接下来就进行开发
// 第一天
touch dev1.js
git add .
git commit -m '购物车静态页面的实现'
// 第二天
touch dev2.js
git add .
git commit -m '购物车的逻辑实现1'
// 第三天
touch dev3.js
git add .
git commit -m '购物车逻辑实现2'
// 第四天
touch dev4.js
git add .
git commit -m '接口联调'
// 第五条
touch dev5.js
git add .
git commit -m '购物车功能的优化'
//然后这时候,就可以把代码合并到master分支上了
如果合并,其中很多的commit信息是没有用的,所以需要合并。
git rebase
的基本用法
git rebase -i [startpoint] [endpoint]
其中-i
的意思是--interactive
,即弹出交互式的界面让用户编辑完成合并操作,[startpoint]
[endpoint]
则指定了一个编辑区间,如果不指定[endpoint]
,则该区间的终点默认是当前分支HEAD
所指向的commit
(注:该区间指定的是一个前开后闭的区间)。
这里的commit hash值
一般截取前面的几位字母就行了
git rebase -i 9c9d69bc
或者:
git rebase -i HEAD~5 // 向前合并几个,这里需要自己去数
这里,自己就有点失算了,哈哈哈。这里是**前开后闭
**的,所以选择9c9d69bc
,合并的时候,是不会包括购物车的静态页面的实现
。这里发现问题了,以后就要多注意了,希望以后不会在犯了。
上面的截图中,有一个指令区域:
pick:保留该commit(缩写:p)
reword:保留该commit,但我需要修改该commit的注释(缩写:r)
edit:保留该commit, 但我要停下来修改该提交(不仅仅修改注释)(缩写:e)
squash:将该commit和前一个commit合并(缩写:s)
fixup:将该commit和前一个commit合并,但我不要保留该提交的注释信息(缩写:f)
exec:执行shell命令(缩写:x)
drop:我要丢弃该commit(缩写:d)
这里主要就是使用 s
,将该commit和前一个commit合并(缩写:s)。
修改后的截图:
上面 截图选中的部门,就是默认的提交信息,这里,我们就可以改改这个提交记录,改成购物车功能的实现完成
。
git log
上面 1
就是前面四条的合并的总的记录。
注意事项:
上面的
2
这个commit 的提交已经被push到远程仓库中,就最好不要合并,不然就会引出不必要的麻烦出来
使用场景2: 简化分支的主树干
在上面的笔记中,学习了merge这个命令,这里合并,就会是主树干 变的很复杂
https://blog.csdn.net/James_xyf/article/details/120809220?spm=1001.2014.3001.5501
这里有一个分支,就有一个分叉,那么如果分支多了,就是分支变得复杂,跟蜘蛛网一样的。
那么rebase
就可以简化树干。
过程图,还是这样的。
图画的有点丑,但是大致意思应该都明白。
流程开始了。
1、先创建一个git管理的文件夹
git init
2、创建master1.txt
,然后add commit
touch master1.txt // 创建一个文件夹
git add .
git commit -m 'master c1'
3、创建master2.txt
,然后add commit
touch master1.txt // 创建一个文件夹
git add .
git commit -m 'master c2'
4、在master c2
的基础上创建一个分支dev
,然后创建文件 dev1.txt
add commit
git branch dev
git checkout dev
// 等价于
git checkout -b dev
touch dev1.txt
git add .
git commit -m 'dev c1'
5、切换回master分支,继续创建master3.txt
,然后 add commit
git checkout master
touch master3.txt
git add .
git commit -m 'master c3'
6、切换到dev,在dev分支上rebase ,合并master分支
git checkout dev
git rebase master
7、然后切换到master分支,merge 合并dev分支
git checkout master
git merge dev
git log --graph --pretty=format:"%h $s"
这样树干,就是直接一条线了。
跟merge的区别:
merge
合并的时候,会产生一条新的commit记录
rebase
则不会产生新的commit
git rebase产生冲突
在rebase
的过程中,也许会出现冲突(conflict). 在这种情况,Git会停止rebase
并会让你去解决 冲突;在解决完冲突后,用"git-add"命令去更新这些内容的索引(index), 然后,你无需执行 git-commit,只要执行:
$ git rebase --continue
这样git会继续应用(apply)余下的补丁。
在任何时候,你可以用--abort
参数来终止rebase的行动,并且"dev" 分支会回到rebase开始前的状态。
$ git rebase --abort
总结
git rebase的目的就是用来优化
// 合并commit提交记录
git rebase -i [startpoint] [endpoint]
// 合并分支
git rebase master