【版本管理 | Git】Git rebase 命令最佳实践！确定不来看看？
【版本管理 | Git】Git rebase 命令最佳实践！确定不来看看？
🤵♂️ 个人主页: @AI_magician 📡主页地址： 作者简介：CSDN内容合伙人，全栈领域优质创作者。 👨💻景愿：旨在于能和更多的热爱计算机的伙伴一起成长！！🐱🏍 🙋♂️声明：本人目前大学就读于大二，研究兴趣方向人工智能&硬件（虽然硬件还没开始玩，但一直很感兴趣！希望大佬带带）
该文章收录专栏 [✨— 《深入解析机器学习：从原理到应用的全面指南》 —✨]
git rebase
名称 | 介绍 |
|---|---|
git rebase | 将一个分支的提交应用到另一个分支上，并且可以修改提交历史。 |
git rebase <branch> | 将当前分支的提交应用到目标分支<branch>上，将当前分支的提交添加到目标分支的顶部。(回到目标分支状态，如在Github修改了readme，在push不了，需要pull回来并将当前目录rebase到顶端) |
git rebase <upstream> | 将当前分支的提交应用到上游分支<upstream>上，将当前分支的提交添加到上游分支的顶部。 |
git rebase -i <commit> | 启动交互式 rebase，可以修改提交历史。 |
git rebase --continue | 在解决合并冲突后继续 rebase 过程。 |
git rebase --abort | 中止当前的 rebase 过程，恢复到 rebase 开始之前的状态。 |
git rebase --skip | 跳过当前的提交，继续 rebase 过程。 |
git rebase --onto <newbase> <upstream> <branch> | 将 <branch> 上从 <upstream> 到当前分支的提交应用到 <newbase> 上，创建一个新的分支。 |
git pull --rebase | 在拉取远程分支时使用 rebase 而不是合并。 |
git config --global pull.rebase true | 设置全局配置，使得 git pull 默认使用 rebase 而不是合并。 |
Git 的 rebase 操作是用于将一个分支的提交移动到另一个分支上的操作。它可以改变提交历史、合并代码以及整理分支结构。下面是对 Git rebase 操作的详细解释：
基本语法：git rebase <目标分支>
<目标分支>是你想要将当前所在分支中的提交应用到其上的目标分支。
工作原理：rebase 将会找出当前所在分支与目标分支最近的共同祖先，然后逐个应用当前所在分支上从该祖先起新增加或修改过的提交。
使用场景：
- 合并代码：当你想要将一些特定功能或修复添加到主干（如
master分支）之前，你可以使用 rebase 来将这些修改放置在主干之前，并保持一个更清晰直观的提交历史。 - 整理 commit 记录：通过交互式地进行 rebase，你可以合并、删除、编辑和重排多个提交来整理和清除不必要或错误的 commit 信息。
命令选项：
-
-i或--interactive：启动交互式模式，在此模式下可以执行更高级别操作，如合并、编辑和重排提交。 -
--onto：指定 rebase 操作的起始点，可以是一个 commit ID、分支名或标签名。
注意事项：
Rebase 改写了 Git 的提交历史，请确保在操作之前备份重要数据，并且只对尚未推送到远程仓库的本地分支执行 rebase 操作。
如果你在进行 rebase 过程中遇到冲突，Git 将会暂停并提示你解决冲突。解决完冲突后，使用 git add 命令将文件标记为已解决，并使用 git rebase --continue 继续进行 rebase。
🤞到这里，如果还有什么疑问🤞
🎩欢迎私信博主问题哦，博主会尽自己能力为你解答疑惑的！🎩
🥳如果对你有帮助，你的赞是对博主最大的支持！！🥳