Git merge squash

Делаю мерж ветки в основную со мерж-стратегией squash

Вижу такую картину, хочу убедиться правильно ли на самом деле происходит мерж веток?

https://i.stack.imgur.com/zwCl5.png


Ответы (1 шт):

Автор решения: Герман Борисов

В документации по git https://git-scm.com/docs/git-merge говорится, что опция --squash приводит рабочую копию и индекс в такое же состояние как будто было произведено слияние (merge), но реального слияния не происходит.

Результат выглядит также как если бы все доработки были выполнены за один коммит на верхушке текущей ветки.

Update

Как известно, git дает разработчикам довольно большую свободу действия, в том числе и в выборе модели рабочего процесса (workflow). Одна из самых знаменитых — git-flow.

Другая не менее популярная модель — линейная история. При ней каждая доработка в основной ветке (master) должна быть оформлена одним коммитом. Все доработки делаются последовательно, коммиты слияния в основной ветке недопустимы. Такая модель сильно упрощает поиск причин ошибок и составление примечаний к релизу.

А что делать, если над проектом работает больше одного человека? Пока один реализует свою доработку, другие уже коммитят своё в master. Чтобы не было коммитов слияния придется делать rebase. Чтобы доработка была одним коммитом, придется делать rebase интерактивным, и применять squash для всех коммитов переносимой ветки.

Того же самого результата можно добиться командой git merge --squash

Но у merge --squash есть одно серьезное преимущество перед rebase — исходная ветка остается нетронутой. Если конфликт слияния был разрешен с ошибкой, то его можно отменить и повторить. С rebase всё сложнее, т.к. исходная ветка удаляется.

→ Ссылка