Git 如何剥下树枝？

我有几个分支，对应于废弃的或后来推迟的开发，其中一些是纯粹的垃圾。我用

git log master..mybranch

了解mybranch的所有内容，但列表通常不必要地长，因为它们也包含master中包含的提交，只是顺序不同。这是由于

master

已被重定基

当我尝试在master上重新设置

mybranch

的基址时，我会遇到由这种重新排序引起的冲突。这样的冲突不值得解决，因为它需要时间，并且会导致

master

中已知的结果

---

因此，我需要的是一种在

mybranch

中消除此类提交的方法，以便只保留重要的提交，并且可以更轻松地重新设置分支的基础。

如果我理解得很好，

mybranch

在其活动时合并或选中

主分支。Git merge算法非常智能，如果
mybranch
的其他提交与
master
自身开发中发生的更改无关，那么合并将不会发生冲突

如果存在冲突，则只意味着两个分支之间的更改重叠，这与
mybranch
包含一些
master
的更改无关

结论：这些冲突不是由于你所说的重新排序造成的；深呼吸，用手解决冲突。
如果我理解清楚，
mybranch
合并或cherry在其活动时选择了
master
分支。Git merge算法非常智能，如果
mybranch
的其他提交与
master
自身开发中发生的更改无关，那么合并将不会发生冲突

如果存在冲突，则只意味着两个分支之间的更改重叠，这与
mybranch
包含一些
master
的更改无关

结论：这些冲突不是由于你所说的重新排序造成的；深呼吸，用手解决冲突。
在一篇评论中提出了这一点，但我越是读你的帖子，就越觉得你没有尝试：

在
mybranch
分支上，使用
git-rebase-i master
将执行一个交互式rebase，这将有效地允许您从rebase中排除“冗余”提交。这可能需要一些手动比较提交，以了解选择哪些提交和放弃哪些提交，但这可能会起作用。
在评论中建议了这一点，但我越是阅读你的文章，我越觉得你没有尝试：

在
mybranch
分支上，使用
git-rebase-i master
将执行一个交互式rebase，这将有效地允许您从rebase中排除“冗余”提交。这可能需要一些手动比较提交，以了解选择哪些提交和放弃哪些提交，但它可能会起作用。
我认为您需要的是
git cherry
。这将从提交体生成sha1值，而不是使用git提交id来比较提交。这使得它独立于提交顺序。您可以使用它来查找值得从一个分支添加到另一个分支的提交

msysGit开发树中的一个示例可能会有所帮助。我们有一个旧分支“work/symlink”，它可能在过去某个时候被合并到“devel”分支。因此：

pt111992@UKNML4132 /git (devel)
$ git cherry devel origin/work/symlink
+ 7fe3fde1d9b93472faeedb75bfd930825a5abe06
- aebecb0d31e4a546cf4d21d32e82cc852b6057bb
+ 1b467d086fd6601cd2feb34d59baf1e804f70acb
+ 3e735a0bfda6b91ae7cbb20c2c89818405c5bea9
+ d4db723c482ba4d2fd7539060834d231c35cdf53

这表示有5个感兴趣的提交（我们也可以从日志输出中得出）：

但是我们也可以通过使用
git log--crep
搜索提交消息来找到它合并到devel分支中的提交id，以查看这条消息是否真的被挑选到devel中。
我想你要找的是
git cherry
。这将从提交体生成sha1值，而不是使用git提交id来比较提交。这使得它独立于提交顺序。您可以使用它来查找值得从一个分支添加到另一个分支的提交

msysGit开发树中的一个示例可能会有所帮助。我们有一个旧分支“work/symlink”，它可能在过去某个时候被合并到“devel”分支。因此：

pt111992@UKNML4132 /git (devel)
$ git cherry devel origin/work/symlink
+ 7fe3fde1d9b93472faeedb75bfd930825a5abe06
- aebecb0d31e4a546cf4d21d32e82cc852b6057bb
+ 1b467d086fd6601cd2feb34d59baf1e804f70acb
+ 3e735a0bfda6b91ae7cbb20c2c89818405c5bea9
+ d4db723c482ba4d2fd7539060834d231c35cdf53

这表示有5个感兴趣的提交（我们也可以从日志输出中得出）：

但是我们也可以通过使用
git log--crep
搜索提交消息来找到它合并到devel分支中的提交id，以查看这条消息是否真的被选入了devel中。
因此我认为您无法通过
git-rebase-I master
从
mybranch
获得您想要的内容，而只是没有选择“common”提交？我的主要问题是确定“常见”提交。理想情况下，这应该主要自动发生，以便将丢失有用内容的风险降至最低。因此，我认为您无法通过
git-rebase-I master
从
mybranch
获得所需内容，而只是没有选择“公共”提交？我的主要问题是识别“公共”提交。理想情况下，这应该主要自动发生，以便将丢失有用内容的风险降至最低。请注意，如果在maaartinus尝试的合并中存在冲突，则不会将其删除。@CharlesB视情况而定。如果他删除“已按另一顺序提交”的提交，并将
mybranch
中的所有其他提交放在
master
的头上，他可能会通过合并到不再冲突的树上来避免冲突。。。虽然不一定可行。嗯，不确定，但让我们等待OP反馈：）我的问题是如何轻松识别“已按另一顺序提交”的提交。令人惊讶的是，对于我重定基础的分支来说，这真的很容易，因为仅仅查看冲突就足以确保它已经存在于主文档中。所以我可以跳过大部分提交。但是，一种自动化的方式，如patthoyts sug
$ git branch --all --contains aebecb0
  remotes/origin/work/symlink