Git 在排除没有更改的提交时，我可以使用什么命令预览合并

我希望看到合并到主线中的提交列表，但是跳过那些引入主线中已经存在的更改的提交（如果git merge要跳过的话）

假设我有

master

分支，我想合并

development

。我使用git log master..development预览我要合并的提交

两者之间的提交数量相当高，即500。为了减少工作量，我想消除那些更改已在

master

中的提交。（可能发生的情况是，如果开发中的200个提交在某个时候被挤压合并到master中）

什么是git命令，用于仅查看将引入更改的提交

什么是git命令，用于仅查看将引入更改的提交

没有。您可能可以估计一个（见下文），但这是一条危险的道路

从根本上说，这里的问题是，在压缩合并之后，您应该停止使用压缩合并的所有提交，即完全删除压缩合并的分支。如果您继续使用这个分支，那么就要由您来决定如何处理这个问题：Git不会帮您解决这个问题

请记住，

git merge

的工作原理是：

• 找到合并基
• 实际上，从合并基到每个分支尖端运行两个

  git diff

  s
• 结合由此产生的变化；及
• 提交结果，记录两个父级，以便下一次合并使用不同的合并基

使用git merge--squash修改此选项将保留上述所有内容，但最后一步，即最终提交-（1）被禁用，就像被

--禁止提交一样，并且（2）在不记录两个父级的情况下进行，以便下一次合并具有相同的合并基础

因此，未来的重新合并依赖于“合并”步骤，该步骤管理将任何先前挤压合并的更改视为重复，并消除重复。这往往只需要少量的更改就可以工作，而大量更改则会失败

考虑到这一点，让我们看一个案例。我们将从以下历史开始：

...--o--*--A------B   <-- mainline
         \
          C--D--E--F   <-- feature

其中合并基是commit
*
，两个分支提示是commit
B
和
F
。Git将自-
*
-at-
B
以来的更改与自-
*
-at-
F
以来的更改相结合，形成了
G

我们现在可以通过添加更多提交来继续开发
功能。未来的
git合并
使用提交
F
，而不是提交
*
，作为合并基础

但是如果我们改用
git merge--squash
，我们会得到以下图形：

...--o--*--A------B--G   <-- mainline
         \
          C--D--E--F   <-- feature

没有办法知道“有趣的”提交是
H-I-J
（当然还有
K
本身）

挤压合并时，您应该取消分支
功能
，这样您现在可以：

...--o--*--A------B--G------K   <-- mainline
                      \
                       H--I--J   <-- feature2

同样很清楚，至少对Git来说是这样；您可以使用
feature..mainline
在Git的帮助下找到这一点，有趣的提交是
H-I-J
（和
K
）

近似，如果你坚持的话
现在，如果您愿意，您可以通过
J
扫描整个提交集
C
，这些提交集位于
mainline..feature
之前的挤压合并之后，尝试对每个提交进行
git cherry pick
。1在一些（简单）情况下，Git会发现采摘樱桃
C
没有效果。这同样适用于
D
、
E
和
F
。樱桃采摘将产生效果

这个概念在许多真实的案例中被打破了。例如，假设commit
D
是commit
C
的还原。在这种情况下，樱桃采摘
C
到从commit
K
萌生的新分支上会产生效果。在其顶部拾取
D
将撤消该效果，因为
D
是一个还原。您可以构建一个处理这种特殊情况的工具，但是如果
C
的还原是
E
而不是
D
，该怎么办

一般情况下，需要将合并记录为合并。因此，一般的规则是，
gitmerge--squash
“杀死”一个分支。它的所有提交都应该被丢弃：它们已经被挤压合并所取代；这是所有壁球的新的和改进的形式；再也见不到他们了


1您可以在新的分支或分离的头上执行此操作，以测试樱桃镐是否真的拾取了任何东西。
不是答案，但500次提交听起来像是大量的提交。这一点，再加上期望合并多个功能上与目标分支相同的提交，表明您可能希望修复您的分支策略。同意Tim B的意见，您不应该选择/挤压合并那么多提交。另外，列出提交如何减少工作负载？无论哪种方式，您都必须执行git合并开发并解决任何冲突？任何不引入任何更改的提交也不会导致任何合并冲突。我理解您的担忧，但请理解，对于大型团队，我在这里抛出的数字实际上并没有那么大。尤其是每天都有50个补丁和功能发布的地方。无论哪种方式，我相信回答这个问题都会对某人有所帮助，即使他们只处理10次提交。
...--o--*--A------B--G-----K   <-- mainline
         \
          C--D--E--F--H--I--J   <-- feature

...--o--*--A------B--G------K   <-- mainline
                      \
                       H--I--J   <-- feature2

...--o--*--A------B--G-----K   <-- mainline
         \          /
          C--D--E--F--H--I--J   <-- feature