Для меня самым непонятным моментом в использовании SVN было слияние веток, т.е. копирование изменений из одной ветки в другую. Чаще всего это делается для синхронизации различных веток (например, релизных) с основной (trunk).
В начале я хочу дать немного теории, а потом покажу на примере как это делать.
Для копирования изменений служит команда merge. Принцип действия этой команды очень прост – сравнивается два состояния хранилища, и выявленные изменения вносит в рабочую копию. Вот этот момент (внесение изменений именно в рабочую копию) был первым моим открытием. До чтения документации я считал, что изменения вносятся сразу в хранилище. О второй неожиданности я расскажу подробнее.
Как большинство новичков, я предполагал, что для переноса изменений из одной ветки в другую, нужно в аргументах команды merge указать исходную ветку и приемную ветку. При чтении мануала я крайне удивился — оказывается, нужно сравнивать не текущие состояния сливаемых веток, а состояния исходной ветки с момента последнего слияния (или выделения отдельной ветки) и текущим состоянием (или любым другим прошлым). Это было настоящим открытием для меня! Так что, мой вам совет – читайте документацию, там бывает можно найти много интересного и полезного. (Глава из официального руководства, посвященная копированию изменений)
Классическим способом использования SVN, при котором может понадобится слияние, является вынесение в отдельную ветку разработки, потенциально опасной для стабильности кода в основной ветке. В этом случае создается отдельная ветка (о том, как это сделать я рассказывал в отдельной заметке), в которую копируется основная ветка. После чего разработчик (или группа разработчиков) независимо от остальных начинает кодить новый функционал. Остальные разработчики продолжают работать с основной веткой (или создают свои ветки для кодинга «опасных» участков). В случае применения такого способа разработки возникает опастность внесения настолько большого количества изменений в основную ветку и ветку «опасной» разработки, что объединить их потребует огромных усилий (или вообще будет невозможно). Чтобы этого не случилось, есть простое решение — с определенной периодичностью или при определенных событиях (например, внесение существенных изменений в основню ветку) сливать изменения основной ветки в ветку разработчика. Тогда финальное слияние нового функционала и основной ветки пройдет достаточно гладко и просто — ведь большая часть изменений основной ветки уже содержится в ветке разработчика.
На этом небольшой экскурс в теорию закончу и во второй части покажу на примере как выполнять слияние изменений в ветках.
(Еще не оценили)
Loading ...Метки: SVN, tutorial, контроль версий
[...] тему слияния изменений между ветками, начатую в первой части. В этой заметке, как и обещал, я собираюсь привести [...]