同步其他分支最新改动
一、认识
二、git merge 目标分支
git merge 合并目标分支, 通过合并当前分支和公共分支, 并且新增一个 merge commit, 然后将两个分支的历史记录联系起来，实现将一个分支的变更集成到另一个分支的效果。 git merge 工作流如下:
-
自己开始在一个专用分支
Feature中处理新功能，然后其他团队成员使用新的提交更新main分支。 -
假设
main中的 新提交与您处理的功能相关。要将新的提交并入您的feature分支中, 有两个选项：合并或变基。这里我们选择git merge main -
这会在
feature分支中创建一个新的合并提交，将两个分支的历史记录联系在一起。导致了Git历史记录中出现多个分支合并点的情况，从而使历史记录更加复杂。
合并是不错的选择，因为它是一种非破坏性的操作。现有分支不会得到任何更改。这避免了变基操作的所有隐患。另一方面，这也意味着每次需要并入上游变更时，feature 分支将会产生一个无关的合并提交。如果 main 非常活跃，这可能会污染您的功能分支的历史记录。
单个 feature 分支
多个 feature 分支
因此, git merge 不会破坏原分支的提交记录。会产生额外的提交记录，并进行两条分支线的合并。所以，融合代码到公共分支的时候用 git merge，而不能使用 git rebase
三、git rebase 目标分支
git rebase 编辑目标分支, 通过将当前分支移动到公共分支的最前面，整合所有分支上的提交，实现将一个分支的变更集成到另一个分支的效果，就好像从公共分支上重新拉了一个分支一样。git rebase 工作流如下:
-
自己开始在一个专用分支
Feature中处理新功能，然后其他团队成员使用新的提交更新main分支。 -
假设
main中的新提交与您处理的功能相关。要将新的提交并入您的feature分支中, 有两个选 项：合并或变基。这里我们选择git rebase main -
这会移动整个
feature分支，以在main分支的节点开始，从而有效地将所有新提交并入main中。但是，变基并不使用合并提交，而是为原始分支中的每个提交创建全新的提交来重写项目历史记录。这意味着，提交历史看起来好像是一条直线，没有分叉，因此整个提交历史看起来更加整洁，历史记录保持相对简单。
变基的主要优势在于可以获得更干净的项目历史记录。首先，它不像 git merge 一样需要不必要的合并提交。其次，如上图所示，变基还会产生完美的线性项目历史记录—您可以在没有任何新拷贝的情况下，始终按照 feature 的提示找到项目的源头。
git rebase 的黄金法则是永远不要在公有分支上使用它。
因此, git rebase 无需新增提交记录到目标分支，reabse后可以直接将对象分支的提交历史加到目标分支上，形成线性提交历史记录，更加直观。不能在一个共享分支上进行reabse操作，会带来分支安全问题。融合代码到个人分支的时候用 git rebase， 可以不污染分支的提交记录，形成简洁的线性提交历史记录
为什么不要在公共分支上使用 git rebase: 如果你在主分支上用rebase, rebase其他分支的修改, 是不是要是别人想看主分支上有什么历史,他看到的就不是完整的历史,这个历史已经被你篡改了