如何保持 git fork 免受重复提交的影响？
我在使用 git 维护分支时经常遇到重复提交的问题。
假设我已经分叉了一个存储库并提交了修复。我将更改推送到我的分叉存储库，并且可以在 github 上看到更改。到目前为止一切都很好。
问题在于，当项目维护者将我的修复合并到他们的分支中，然后我进行更新以与主项目保持同步时。我的修复会在我的历史记录中出现两次，一次是原始修复，一次是项目维护者将其合并的时间。
有解决办法吗？如果终于能清理掉我的树就好了。
I frequently run into a problem with duplicate commits while maintaining forks with git.
Lets say I've forked a repository and committed a fix. I push the changes to my forked repository and can see the changes on github. All well and good so far.
The problem lies when the project maintainer merges my fix into their branch and I later update to stay synced with the main project. My fix would appear twice in my history, the orginial and the time it was merged in by the project maintainer.
Is there a solution for this? It'd be nice to finally clean up my tree.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这些提交是精心挑选的，而不是合并的吗？如果将相同的提交合并到两个分支中，然后将其中一个合并到另一个分支中，则提交不会显示两次。您将准确地看到您在历史记录中所期望的内容 - 以给定提交作为父级的两个合并提交，然后这两个分支最终合并：
这是合并而不是挑选樱桃的一个很好的理由 - 并且为了促进合并，它是重要的是要确保从可能想要合并它们的所有分支的共同祖先开始主题分支，以便可以干净地合并这些功能/错误修复，而无需选择其他任何内容。
来自操作者的注释：提交是从 Github 的 fork 队列应用的，该队列在幕后使用cherry-pick。已采纳，谢谢。
Were those commits cherry-picked, not merged? If you merge the same commits into two branches, then merge one of those into the other, the commits don't show up twice. You'll see exactly what you expect in the history - two merge commits with the given commit as parent, then those two branches eventually merged:
This is a really good reason to merge instead of cherry-picking - and to facilitate that merging, it's important to make sure to start your topic branches from a common ancestor of all branches that may want to merge them, so that those features/bugfixes can be merged cleanly, without picking anything else up.
Note from the op : The commits were applied from Github's fork queue which uses cherry-pick behind the scenes. Accepted, thank you.