我在一家名为 blaBla 的分支机构工作。 master 从其他人那里得到了大量的提交。为了不断更新 blaBla，我经常使用 git pull master 并将其合并到 blaBla 中。但这会使我的分支因大量提交而杂乱无章。我想将 master 中发生的所有 new 提交合并为一个，然后将其合并到我的分支中。因此，当我执行git log 时，我只看到属于该分支的提交和那些单个合并提交。没有别的了
【问题讨论】：
标签： git github version-control merge
我想将 master 中发生的所有新提交合并为一个，然后将其合并到我的分支中。
你真的不想这样做。将更改从 master 引入功能分支的唯一合理选择是：
在不压缩其提交的情况下执行普通的git merge master，以便 Git 可以判断您的功能分支与 master 有哪些共同提交（否则您可能会遭受大量合并冲突）。否则，您压缩的合并提交中的所有新更改将看起来像是您的新功能的一部分 - 不好。
执行git rebase master 以在master 的最新版本之上重播分支的更改。这是我首选的工作流程，因为它将您的更改构造为“自 master 以来的更改”，无论您从哪个 master 开始，但它带来了重写历史的所有常见风险（例如，如果您要去，请非常仔细地沟通到 git push --force 到其他人所依赖的分支）。
更新以反映已接受的答案： 或者，更改您对提交的可视化方式。 git log --first-parent 将隐藏合并到当前分支的提交。虽然通常用于可视化 master（哪些功能分支已合并），但它也可以排除已合并到功能分支中的 master 提交。
【讨论】：
git log --first-parent 查看您的分支 - 您将看到“将分支 'master' 合并到 blaBlah”（及其冲突解决方案），但不会看到合并的提交。我不理解关于 rebase 的“混乱我的本地分支”评论 - 如果您认为分支是“自 master 分支以来的变化（即git log master..），rebase 之后您将继续查看同一系列的提交。
git log --first-parent 是答案。 Tnx！
似乎有几种方法可以做到这一点，但如果您只在本地执行此操作，则可能会使您的更改更加难以掌握。 Git 真的不喜欢历史被重写
【讨论】：
git log 时，您所看到的只是我的提交、单一合并事件和合并冲突的相关修复，仅此而已。没有其他数千个提交可见