Изменения не отменяются с помощью `git merge -squash master`

Question

Я использую git merge -squash master --strategy-option=theirs в моих ветках релиза / постановки.Это позволяет мне (насколько я понимаю) сделать снимок текущей основной ветки в ветку релиза, но без всех сотен коммитов (каждая новая функция / исправление ошибки) - вместо этого все они свернуты в один коммит(«Релиз 20180624» и «Патч 1» и т. Д.), Поэтому я могу быстро перемотать на нужную заданную точку выпуска, если мне нужно.

Моя проблема в том, что после команды git merge -squash master --strategy-option=theirs она не отображает всеперемены.Я только что выполнил команду, и в ветке stage возникла ошибка компиляции.Я сравниваю два файла, и на master и stage файл отличается:

Master:

... 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: [
    ...

Почему существует эта разница?Почти все остальное идентично - но теперь я чувствую, что не могу доверять процессу.Я заметил это несколько раз, обычно одно единственное изменение (при условии, что я ничего не пропустил) в случайном файле.На этот раз он был обнаружен рано, потому что это была хорошая ошибка компиляции - но я могу представить, что есть другие изменения, которые сложнее обнаружить.Мои ветки выпуска и стадии не точно отражают мою кодовую базу.

Я неправильно использую merge -squash?

Answer 1

Короткий ответ таков: 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

Обратите внимание, что коммит "сквош-слияние" - это обычный коммит (без слияния): это вовсе не слияние! Обычный коммит слияния является коммитом слияния. (Это немного круговая логика: коммит слияния - это просто коммит по крайней мере с двумя родителями. Тем не менее, это ключевое отличие здесь. Кроме этого, git merge --squash - это обычное слияние, хотя оно также вызывает --no-ff и --no-commit.)