Чем отличается merge от commit?

Question

Чем отличается merge от commit? Когда комитим - заливаем, скажем, в главную ветку свои изменения. Когда мержим - объединяем свою копию с изменениями в главной ветке.

Когда нужно выложить проект в продакшн, переключаемся на trunk, мержим, а потом еще и комитим, зачем второе действие?

Answer 1

Если бы merge был бы эквивалентен merge + commit, то пользователь потерял бы возможность выполнять следующие действия:

• Целиком review'ить изменения в feature branch, которые появляются после merge --reintegrate.

• Решать conflict'ы и tree conflict'ы, которые возникли в результате операции merge.

Answer 2

• Commit - означает выложить свою версию в репозиторий
• Update - означает выкачать версию из репозитория (обновить свою)
• Merge - означает внесение изменений в своей версии по сравнению с версией из репозитория. Обычно юзеру предоставляется возможность просмотра изменений (построчно) чтобы определить какие изменения из репо можно применить к своей версии (решение конфликтов).
• Diff - сравнение 2-х версий. Часто имеет смысл делать перед Merge или для просмотра изменений сделанных другим членом команды
• Checkout - выкачивание целиком исходников из репо. Как правило делается в самом начале работы

Типовой паттерн работы такой: checkout → работаем → commit → перерыв → update (возможно с merge) → работаем → commit и т.д.

Answer 3

Дело в том, что commit - это не просто заливка изменений. Сущность этой операции заключается в том, что изменения, сделанные локально, преобразуются в изменения, которые могут быть успешно добавлены в репозиторий и зафиксированы в нём в виде очередной ревизии. При этом локальные изменения всегда выражены в виде различий относительно последней ревизии, о которой известно локально (т.е. ревизии, которая была во время последнего update), а в репозиторий могут быть добавлены лишь такие изменения, которые выражены в виде различий относительно последней ревизии самого репозитория.

В простейшем случае, когда в репозиторий не было добавлено ничего со стороны, преобразование изменений сводится к тому, чтобы не делать ничего, поскольку изменения и так уже выражены в виде различий относительно последней ревизии в репозитории. Поэтому операция commit становится тривиальной и выглядит, как простая заливка изменений. В случае же, когда с момента последнего update в репозитории уже появилось что-то новое, попытка сделать тривиальный commit проваливается и приходится проходить всю процедуру полностью, т.е. сначала приспосабливать свои локальные изменения к тем другим изменениям, которые уже были зафиксированы в репозитории кем-то другим, и только потом заливать их и фиксировать.

Когда мы заливаем в репозиторий изменения, сделанные в рабочей копии, необходимость делать commit в самом конце очевидна. Ведь в репозитории ещё нет наших локальных изменений, поскольку предыдущая попытка сделать тривиальный commit провалилась. Не так очевидна эта необходимость в ситуации, когда мы объединяем одну ветку с другой прямо в репозитории с помощью merge. Дело тут вот в чём. На самом деле, операция commit играет ещё и роль подтверждения. Заливка в репозиторий новых изменений как в тривиальном случае, так и после адаптации всегда выполняется после того, как пользователь увидел окончательный вариант, поэтому его подтверждение, необходимое для фиксации очередной ревизии, как бы подразумевается и даётся тем же самым commit'ом. А вот про объединение веток в репозитории такого сказать нельзя. Результат объединения веток обычно отличается от того, что было в последних ревизиях как одной ветки, так и другой. Он представляет собой совершенно новую ревизию. И даже в том случае, когда участие пользователя в самом объединении веток не требуется, от него всё равно требуется получить подтверждение после того, как будет получен окончательный вариант новой ревизии. Именно для этого и нужен commit после merge. Если объединение прошло на автомате, то commit играет лишь роль подтверждения, которое необходимо для фиксации любой ревизии в репозитории.