在Git版本控制系统中，rebase 和 merge 是两种不同的操作，用于合并分支。rebase 'A' onto 'master' 和 merge 'master' into 'A' 虽然最终目的都是将两个分支的更改合并在一起，但它们在处理方式和结果上有所不同。
rebase ‘A’ onto ‘master’
-
含义：将分支
A上的所有提交“重新应用”到master分支的最新提交上。这意味着A分支上的所有更改都会在master分支的最新状态上重新应用。 -
操作步骤：
- 切换到分支
A。 - 执行
git rebase master，这会将A分支上的所有提交暂时移动到一个临时区域。 - 然后将
master分支的最新更改应用到当前分支（A）。 - 最后，将
A分支上的所有更改重新应用到这些新的基础提交上。
- 切换到分支
-
结果：
A分支的提交历史会线性化，不会出现分支合并时的“合并提交”。这使得历史更加清晰，但可能会丢失一些上下文信息，因为提交的顺序和基础可能会改变。
merge ‘master’ into ‘A’
-
含义：将
master分支的最新更改合并到分支A中。这是一个标准的合并操作，会将两个分支的更改合并在一起。 -
操作步骤：
- 切换到分支
A。 - 执行
git merge master，这会创建一个新的“合并提交”，它将master分支的最新更改合并到A分支中。
- 切换到分支
-
结果：在分支
A上会有一个额外的提交，这个提交是master分支更改的合并结果。这会保留两个分支的完整历史，但可能会在历史中引入额外的“合并提交”，使得历史看起来不那么线性。
区别
- 历史线性化：
rebase操作使得历史更加线性，没有额外的合并提交，而merge操作会引入合并提交，历史可能不那么线性。 - 提交顺序和基础：
rebase会改变提交的顺序和基础，而merge则保留了原始的提交顺序和基础。 - 冲突解决：在
rebase过程中解决冲突可能会更复杂，因为需要逐个解决每个提交的冲突，而在merge中，所有冲突都是一次性解决的。 - 分支合并策略：
rebase通常用于将特性分支的更改合并到主分支，而merge则用于将主分支的更改合并到特性分支。
选择使用rebase还是merge取决于具体的工作流程和个人偏好。有些团队可能更喜欢线性的历史，而有些团队则更重视保留完整的历史上下文。
IDEA free版
https://pan.quark.cn/s/dd7db30d835f
🍉很好吃
https://pan.xunlei.com/s/VODlE779VGm7EO4ErUKIgB_PA1?pwd=cunm
