我一直git merge -squash master --strategy-option=theirs在发布/登台分支上使用。它使我（据我所知）可以将当前master分支的快照拍摄到release分支中，但没有所有数百个提交（每个新功能/错误修复）-而是将它们全部汇总为一个提交（例如“ Release 20180624”和“ Patch 1”等），因此我可以根据需要快速倒带到一个不错的发布点。
我的问题是，执行git merge -squash master --strategy-option=theirs命令后，并没有带来所有更改。我只是运行命令，stage分支出现了一个错误编译。我比较了两个文件，并且在master和stage文件上是不同的：
主：
... loads of imports ...
import { CommentsModule } from '../comments/comments.module';
... loads more imports ...
import { routing } from './myjobs.router';
import { CommentsModule } from '../comments/comments.module';
@NgModule({
imports: [
...
这是一个简单的错误，CommentsModule两次被导入。
阶段：
... loads of imports ...
import { CommentsModule } from '../comments/comments.module';
... loads more imports ...
import { routing } from './myjobs.router';
@NgModule({
imports: [
...
为什么存在这种差异？几乎所有其他内容都是相同的-但现在我觉得我不能真正相信这个过程。我已经注意到了几次，通常是在随机文件中进行一次这样的更改（假设没有任何遗漏）。这次是因为它是一个不错的编译错误而导致早期发现-但我可以想象还有其他更难发现的更改。我的release和stage分支无法正确反映我的代码库。
我使用merge -squash不正确吗？
简短的回答是git merge-尤其在合并，因为在面向行的差异合并基础工程变化的组合是不够聪明，了解的东西应该只导入一次。不使用-X theirs或--strategy-option theirs，如果更改集不能很好地匹配，则会出现合并冲突。使用theirs告诉Git盲目地假设存在冲突，应该使用“他们的”版本，但这只会影响冲突。即使没有theirs此方法也可能导致点火失败。例如，假设您提前添加了导入：
[your changes near the top of the file]
some context here
+import { CommentsModule } from '../comments/comments.module';
假设他们决定在以后的许多行中包含此模块：
different context here
+import { CommentsModule } from '../comments/comments.module';
Git现在可以看到在不同位置两次添加同一行的说明，因此可以这样做。
常规合并和压缩合并均执行合并操作。当您或Git进行最后一次提交时，它们之间的区别就在最后。通过常规合并，新提交具有两个父提交：您当前的提交，以及另一个ID传递给您的提交git merge：
...--o--*--o--o--...--o <-- yourbranch (HEAD)
\
o--o---...---o <-- theirbranch
变成：
...--o--*--o--o--...--o--M <-- yourbranch (HEAD)
\ /
o--o---...---o <-- theirbranch
没有--squash，则变为：
...--o--*--o--o--...--o--S <-- yourbranch (HEAD)
\
o--o---...---o <-- theirbranch
请注意，“南瓜合并”提交是普通的（非合并）提交：根本不是合并！常规合并提交是合并提交。（这是一些循环逻辑：合并提交只是具有至少两个父级的提交。但这仍然是这里的关键区别。除此之外，agit merge --squash是普通合并，尽管它也会强制--no-ff和--no-commit。）
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句