我有几个分支，对应于废弃或后来推迟的开发，其中一些是纯粹的垃圾。我常常
git log master..mybranch
查找 mybranch 的全部内容，但列表通常不必要地长，因为它们还包含 master 中包含的提交，只是顺序不同。这来自于 master 已被重新设置。
当我尝试在 master 之上重新设置 mybranch 的基础时，我遇到了由这种重新排序引起的冲突。此类冲突不值得解决，因为它需要时间并且会导致 master 已知的结果。
因此，我需要一种方法来摆脱 mybranch 中的此类提交，以便只保留重要的提交，并且可以更轻松地重新建立分支。
I'm having a couple of branches, corresponding with abandoned or later postponed development, some of them are pure garbage. I use
git log master..mybranch
to find out what's mybranch all about, but the lists are usually needlessly long, since they contain also commits contained in master, just in a different order. This comes from master having been rebased.
When I try to rebase mybranch on top of master, I get conflicts caused by this reordering. Such conflicts are not worth resolving, as it takes time and leads to a result already known from master.
So what I need is a way to get rid of such commits in mybranch, so that only the important commits remains and the branch can be rebased more easily.
发布评论
评论（3）
我认为您正在寻找的是
gitcherry。这会从提交主体生成 sha1 值，而不是使用 git commit id 来比较提交。这使得它独立于提交顺序。您可以使用它来查找可能值得从一个分支添加到另一个分支的提交。msysGit 开发树中的示例可能会有所帮助。我们有一个旧分支“work/symlink”，它可能已在过去某个时间合并到“devel”分支。所以：
这表示有 5 个感兴趣的提交（我们也可以从日志输出中计算出）：
这就是“work/symlink”上存在的提交，而不是“devel”上的提交。 gitcherry 输出表明 aebecb0 提交已经应用于“devel”（来自前导减号），但其他可能值得研究。我们可以检查该提交是否仅存在于工作分支上：
但我们也可以通过使用 git log --crep 搜索提交消息来找到它合并到 devel 分支中的提交 ID看到这个确实被选进了开发。
I think what you are looking for is
git cherry. This generates sha1 values from the commit body rather than using the git commit id to compare commits. This makes it independent of the commit ordering. You use it to find commits which might be worth adding from one branch to another.An example from the msysGit development tree might help. We have an old branch 'work/symlink' which may have been merged to the 'devel' branch sometime past. So:
This says there are 5 commits of interest (which we can also work out from the log output):
Thats the commits present on 'work/symlink' and not on 'devel'. The git cherry output suggests that the aebecb0 commit is already applied to 'devel' (from the leading minus) but the others might be worth looking into. We can check that this commit is only present on the work branch:
but we can also find the commit id it got merged into the devel branch with by searching for the commit message using
git log --crepto see that this one was really picked into devel.在评论中建议了这一点，但我读你的文章越多，我就越认为你没有尝试过：
在
mybranch分支上，使用git rebase -i master将执行交互式变基，这将有效地允许您从变基中排除“冗余”提交。这可能需要一些手动比较提交才能知道选择哪些提交以及丢弃哪些提交，但它可以工作。Suggested this in a comment, but the more I read your post, the more I think you didn't try that:
When on the
mybranchbranch, usegit rebase -i masterwill perform an interactive rebase, which'll effectively allow you to exclude the "redundant" commits from the rebase. This might need some manual comparing the commits to know which ones to choose and which to discard, but it could work.如果我理解得很好，
mybranch会在master分支处于活动状态时合并或挑选它。 Git 合并算法非常智能，如果mybranch的其他提交与master自己开发中发生的更改无关，则合并将不会产生冲突。如果存在冲突，则仅意味着两个分支之间存在重叠的更改，这与
mybranch包含一些master的更改这一事实无关。结论：冲突不是由于您所说的重新排序造成的；而是由于您所说的重新排序造成的。喘口气，用手解决冲突。
If I understand well,
mybranchmerged or cherry-picked themasterbranch when it was active. Git merge algorithm being quite smart, if the other commits ofmybranchwere unrelated to changes that happened inmaster's own development the merge would be conflict-less.If you have conflicts it only means that you have overlapping changes between both branches, and this is not related to the fact that
mybranchcontains some of themaster's changes.Conclusion: the conflicts are not due to the reordering you're talking about; take a breathe and solve the conflicts by hand.