Reapply commits on top of another base tip
另一个基本提示上重新应用提交
如果需要获得更清晰的修订历史记录,可以使用 git rebase
命令集成分支。
假设我们有两个分支,其中包含 non-fast-forward
方案。
# 变基 rebase 与合并 merge 不同,是基于被 rebase 的 commit 上操作的# 切换至次分支git checkout bugfix# 变基至主分支git rebase master# 切换到主分支git checkout master# 再合并已经变基的 bugfixgit merge bugfix
整个 bugfix
分支上的提交会移动到 master 分支的后面,有效地把所有 master 分支上新的提交并入过来。
执行 rebase
命令将导致分支历史记录看起来类似于下面的图示。
当您将错误修复分支重新绑定到主分支时,将修复来自错误修复分支的提交并将其附加到主分支的末尾。最终结果是 bugfix
分支历史记录一个简单 commit 流。
如果在附加提交时发生代码冲突,Git 会要求您在继续重新设置其他提交之前修复冲突。
rebase
不会移动 master
分支的位置。在任何情况下,您都可以在 rebase
后执行从 bugfix
到 master
的 fast-forward
或清除合并。
对于 merge
和 rebase
的区别,实质上:
merge
是对目前分叉的两条分支的合并rebase
是对当前分支记录基于任何 commit
节点(不限于当前分支上的节点)的变更rebase
的 base
不能理解为分叉的基点,而是整个 git
库中存在的所有 commit
节点:
git pull —-rebase
的时候,这个当前分支是本地分支,commit
节点是远程分支的 head
git rebase master
的时候,这个当前分支是 feature
分支,commit
节点是 master
分支的 head
git rebase -i
的时候,这个当前分支就是当前工作分支,commit
节点是在 -i
后注明的 commit
交互式变基允许你更改并入新分支的提交。这比自动的变基更加强大,因为它提供了对分支上提交历史完整的控制。一般来说,这被用于将 feature
分支并入 master
分支之前,清理混乱的历史。
# 语法git rebase -i [startpoint] [endpoint]# 示例git checkout featuregit rebase -i master
它会打开一个文本编辑器,显示所有将被移动的提交:
pick 33d5b7a Message for commit #1pick 9480b3d Message for commit #2pick 5c67e61 Message for commit #3
然后 wq
保存退出后是注释修改,编辑完注释再 wq
保存完成 commit 合并。
忽略不重要的提交会让你的 feature 分支的历史更清晰易读,这是 git merge
做不到的。
被合并分支只有你自己使用。
feature
分支,进行开发:git:(master) git checkout -b feature
hotfix
,且合并入 master 分支,此时 master 已经领先于你的 feature
分支git rebase master
进行分支合并rebase
原理:
feature
分支里面的每个 commit
取消掉patch
文件,存在 .git/reabase
目录下feature
分支更新到最新的 master
分支patch
文件应用到 feature
分支上在 rebase
过程中,出现冲突 conflict 后,git 会停止 rebase 并会让你解决冲突。解决完冲突后,用 git add
命令去更新这些内容,即执行 git rebase --continue
。
⚠️ 注意:你无需执行 git commit
,只要执行 git rebase --continue
。
在任何时候,我们都可以用 git rebase -abort
来终止 rebase
的行动,并且分支会回到 rebase
开始前的状态。
永远不要对已经推到主干分支服务器或者团队其他成员的提交进行变基,我们选择变基还是合并的范围应该在自己当前工作范围内。
参考资料: