问题
在最近的开发过程中碰到一个问题，每次拉取master分支开发完成后，会有其他人已经合并到master分支，这个时候我往往是通过merge来做，但是merge导致每次提交都会多出一条提交记录，在问题追溯的时候总是不太好。所以我想着如何解决这个问题
解决办法
git fetch origin master
git rebase origin/master
git rebase介绍
工作方式：rebase 会重新应用一个分支上的更改到另一个分支。它首先找到两个分支的共同祖先，然后将改动的每个提交应用于目标分支。
提交历史：使用 rebase 会创建一个更线性的历史。它实际上是移动了一系列的提交到新的基线（base）。这会改变这些提交的哈希值，因为Git中的提交包括父提交的哈希值。
冲突解决：在 rebase 过程中遇到的冲突需要在每个重新应用的提交过程中逐个解决。这与 merge 不同，merge 是在最后创建合并提交之前一次性解决所有冲突。
适用场景：rebase 更适用于当你想要一个干净、线性的提交历史时。它常用于整理特性分支的提交历史，使其更加整洁和有序，然后再将这个特性分支合并到主分支。
Merge和Rebase比较
提交历史的清晰度：merge 保留了所有分支的历史和合并点，而 rebase 则提供了一个更线性、更干净的历史。
历史的改变：merge 保留了原始的提交哈希值和历史，而 rebase 会改变提交的哈希值（因为提交的上下文发生了改变）。
冲突解决的方式：rebase 可能需要在多个提交上反复解决相同的冲突，而 merge 则是一次性解决所有冲突。
最佳使用时机：如果你需要频繁地从一个长期存在的分支（如 main 或 develop）中获取最新的更改，rebase 是一个很好的选择，因为它避免了多余的合并提交。而 merge 更适合在最终整合长期分支时使用，因为它保留了分支之间的合并点和关系。
结论
merge 和 rebase 都是处理分支间差异的强大工具，选择使用哪一个取决于你的具体需求、团队规范以及你希望维护的历史类型。rebase 对于维持一个清洁、线性的历史非常有效，而 merge 则提供了一个直观、真实的开发历史视图。在协作的环境中，理解并正确使用这两种方法对于维护一个健康、可管理的代码库至关重要。
Rebase冲突
当您使用 rebase 将您的分支（例如，特性分支）放到 master 分支的最新提交之上时，如果 master 分支的最新提交修改了与您在特性分支中修改的相同的代码部分，就会出现冲突。
处理rebase冲突
- 当出现冲突时，Git会暂停rebase操作。
- 此时，你需要手动解决这些冲突。
- 解决冲突后，使用git add将更改标记为已解决。
- 然后，使用git rebase --continue继续rebase过程。
- 如果你决定不继续rebase，可以使用git rebase --abort回到原始状态。
- 记住，rebase是一个强大但复杂的工具。在处理共享分支时要特别小心，因为rebase会改变历史，可能会导致其他协作者的困惑或更多的合并冲突。
问题
不要在公共分支rebase