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

#svn

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

Ответы

Ответ 1

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



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


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


Ответ 2

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


Ответ 3

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


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