变基

https://blog.csdn.net/weixin_43717839/article/details/143222436

使用场景

Git变基（Rebase）是一个强大的Git特性，用于重新定位一个分支上的一系列提交到另一个分支上，从而使提交历史更加整洁和线性。以下是Git变基的几种常见使用场景：

交互式变基（合并同一条线上的提交记录）

• 命令：git rebase -i HEAD~n（n为要合并的提交数）
• 对象：版本库中的本地分支
• 作用：将当前分支最近的n次提交合并成一个提交。这个命令让用户以交互方式控制变基过程中要如何处理每个提交。使用-i参数时，Git会打开一个文本编辑器，列出指定的提交历史，并允许用户对这些提交进行各种操作。
• 注意事项：要合并的提交里面不能包含已经上传到远端仓库的提交。

变基（合并分支）

• 命令：git rebase [其他分支名称]
• 对象：版本库中的本地分支
• 步骤：
  1. 切换到当前分支。
  2. 执行git rebase [其他分支名称]命令。
  3. 将当前分支的提交应用到其他分支的最新提交上。
• 作用：通过变基，可以将待合并分支的修改应用到目标分支上，从而在目标分支上形成一个干净的提交历史。
• 注意事项：
  1. 最终被修改的还是当前分支。
  2. 应用到其他分支的提交为当前分支跟其他分支共同祖先的后续提交。

本地分支与远端分支的变基

• 命令：通常结合git pull命令使用，即git pull --rebase [远程仓库名] [分支名]
• 对象：本地分支和远端分支
• 作用：从远程仓库获取最新的更新，并将本地分支的提交“移植”到远程分支的最新提交之上，以保持提交历史的线性。
• 优点：
  1. 历史记录更清晰：变基后的提交历史是线性的，便于阅读和理解。
  2. 避免合并提交：通过变基，可以避免生成不必要的合并提交，从而保持提交历史的简洁。
  3. 冲突处理更明确：在变基过程中，每个提交的冲突会逐个处理，更容易定位和解决冲突。
• 注意事项：
  1. 变基会重写提交历史，因此在已经推送到共享仓库的分支上运行变基可能会导致问题，其他开发者的工作可能会受到影响。
  2. 建议只在还没有推送到远程仓库的个人分支上使用变基，以避免对其他协作者的工作造成影响。

移植分支

• 场景：有时候，已经创建了一个分支，并完成其首次提交，此时可能需要将该分支移植到提交图中的另一个位置上。
• 命令：git rebase [原分支] --onto [目标分支]
• 作用：通过--onto选项将指定分支的提交拷贝到另一个指定位置上。

综上所述，Git变基在多个场景下都非常有用，但使用时需要注意其重写历史的特点，并谨慎处理可能引发的冲突和协作问题。

删除提交日志

使用 gitee 或者 github 创建名为 demo-git 的仓库

将多个提交合并为一个提交

https://blog.csdn.net/Aqu415/article/details/140565162

下面模拟开发者A和开发者B同时基于 demo-git 协作开发。

使用 gitee 或者 github 创建名为 demo-git 的仓库

开发者A：在本地初始化一个空白的 git 仓库

git init demo-git
cd demo-git

开发者A：使本地 git 仓库指向远程 https://gitee.com/dexterleslie/demo-git 仓库

git remote add origin https://gitee.com/dexterleslie/demo-git

开发者A：新建 test.txt 内容如下：

1

开发者A：第一次提交

git add test.txt
git commit -m "第一个提交"
git push --set-upstream origin master

开发者A：修改 test.txt 内容如下：

12

开发者A：第二次提交

git add test.txt
git commit -m "第二个提交"
git push

开发者B：克隆 demo-git 仓库到另外一个目录以模拟另外一个开发者准备开发新的特性

git clone https://gitee.com/dexterleslie/demo-git demo-git-feature
cd demo-git-feature

开发者B：创建 feature 分支准备开发新特性

git checkout -b feature

# 推送分支到远程
git push --set-upstream origin feature

开发者B：新建 feature.txt 内容如下：

1

开发者B：feature 第一次提交

git add feature.txt
git commit -m "feature的第一个提交"
git push --set-upstream origin feature

开发者B：修改 feature.txt 内容如下：

12

开发者B：feature 第二次提交

git add feature.txt
git commit -m "feature的第二个提交"
git push

开发者A：修改 test.txt 内容如下：

123

开发者A：第三次提交

git add test.txt
git commit -m "第三个提交"
git push --set-upstream origin master

开发者A：修改 test.txt 内容如下：

1234

开发者A：第四次提交

git add test.txt
git commit -m "第四个提交"
git push --set-upstream origin master

开发者B：在 feature 分支合并最新两个提交

git rebase -i HEAD~2

开发者B：把 git rebase 过程弹出的内容修改如下：

pick c64e612 feature的第一个提交
s f49d741 feature的第二个提交

# Rebase ab4e21d..f49d741 onto ab4e21d (2 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

开发者B：保存并退出，注释其他注释只保留或者修改其中一个注释作为 rebase 后的注释，保存并退出。

开发者B：把 rebase 后的新提交强制推送到远程

git push -f

开发者B：查看 log 会看到分支的提交被合并为一个提交

git log

开发者A：合并 feature 到 master 分支中

git merge origin/feature
git push