Прежде чем вообще начинать использовать ветки, и даже если вы не думаете об их использовании, вам необходимо прочитать Этот Священный Талмуд .
Прочитав статью о ветках в svnbook, вы уже понимаете, для чего нужны ветки, как с ними работать и в каких случаях их следует использовать.
В принципе, после этого вам, скорее всего, уже не понадобится то, что написано под катом.
Но если вам лень читать, то, возможно, текст ниже вас заинтересует, и вы все-таки прочитаете статью документации.
Или, может быть, это просто поможет вам лучше понять то, что вы только что прочитали в svnbook. Для чего все это? Допустим, у вас есть задача, выполнение которой займет более одного дня.
Политика частых коммитов предполагает, что мы совершаем коммиты более одного раза в день.
Это позволяет нам чаще получать изменения и избегать конфликтов.
Если изменений в ревизии не так много, то вероятность конфликтов снижается.
Также мы страхуемся от форс-мажорных обстоятельств, если что-то пойдет не так – мы не потеряем неделю работы.
Но иногда задача длинная, и мы не можем закоммитить где-то посередине, потому что незавершенная задача, зафиксированная в основном коде, может мешать другим разработчикам в их работе.
Но и не брать на себя обязательств в течение нескольких дней тоже неправильно.
Во-вторых, вам может потребоваться загрузить код в производство.
Если мы коммитируем незавершенную задачу в основную ветку, она попадет в продакшн, что не кошерно.
Для этого есть филиалы.
Они позволяют нам совершить коммит в любое удобное для нас время, не мешая всем остальным.
Ветки также позволяют работать над несколькими задачами параллельно, не смешивая их.
Что такое филиал? Это просто копия каталога svn. Точнее, так называемая «облегченная копия», содержащая только изменения.
Идентичные файлы не копируются.
Филиал имеет общую историю до момента его создания с основным филиалом.
В общем, ветвей может быть сколько угодно, и каждая из них может разветвляться.
Но в стандартном проекте принято иметь три постоянных ветки: * ствол — основная линия развития.
Здесь будет текущий код, здесь будут выполняться мелкие задачи и исправления ошибок.
* ветви — ветка для разработчиков.
Гсуто разветвляется на другие ветви.
Здесь вы будете создавать свои ветки.
* теги - отметить ветку.
Здесь создаются всевозможные маркеры, отмечающие значимые вехи развития проекта, проще говоря, его стабильные и не очень стабильные версии.
Он нужен для того, чтобы всегда можно было вернуться к какой-нибудь версии, например, чтобы посмотреть «почему эта хрень раньше работала, а потом перестала, дурак» Программисты несут ответственность за * Создайте ветку, когда это необходимо.
для стабильного существования проекта.
В общем, если вы чувствуете, что задача продлится больше пары дней (а иногда и суток), и за это время вы не сможете безболезненно коммитить хотя бы пару раз в день, вам нужна ветка .
* Держите свою тему в актуальном состоянии — то есть вам нужно как можно раньше избавиться от панического страха перед командой слияния, и мерить не реже, чем вы коммитите.
В противном случае конфликтов при слиянии ветки со стволом не избежать.
* Удалить ветку после завершения задачи .
Ветки разработки — это временные ветки, поэтому их следует удалить после завершения задачи.
В крайнем случае, можно пожить еще несколько дней, чтобы убедиться, что в задаче нет серьезных ошибок.
Филиал больше никому не понадобится; его можно удалить.
Все равно через какое-то время оно настолько отойдет от основной линии развития, что никакое слияние не сможет вернуть ему актуальность.
Как работать с ветками Создать новую ветку очень просто.
Как следует из Талмуда, это делается с помощью команды копирования.
Допустим, мы разрабатываем некий проект — BUMP (Big Awesome Mega Project).
В нашем случае вам необходимо выполнить следующую команду: svn copy svn://svnserver/var/bump/trunk svn://svnserver/var/bump/branches/my-branch -m="Creating a private branch of /bump/trunk"
Чтобы переключиться на новую ветку:
с vn switch svn://svnserver/var/bump/branches/my-branch
Чтобы проверить, в каком филиале вы сейчас находитесь svn info
Перейдя в новую ветку, вы сможете вносить правки, коммитить, и никто больше этого не заметит. Но помните, что команда переключения очень похожа на команду обновления, поэтому при переключении с одной ветки на другую могут возникнуть конфликты, если в одном файле были правки.
Именно поэтому необходимо чаще мержить изменения из основной ветки.
Копирование изменений между ветками Чтобы поддерживать вашу ветку в актуальном состоянии, вам необходимо периодически копировать изменения из основной ветки.
Это необходимо для того, чтобы избежать конфликтов при слиянии веток или при переключении на основную ветку.
Поэтому замерзать нужно чаще, хотя бы один-два раза в день.
Вы можете взять за правило: выполнять слияние перед каждым коммитом.
Команда слияния, вероятно, самая сложная из команд svn. А все дело в том, что svn не запоминает ваши предыдущие мержи (до версии 1.5).
А если он не помнит, то вы рискуете скопировать те изменения, которые у вас уже есть после предыдущего слияния.
Но этот недостаток легко обойти.
После каждого копирования изменений в вашу рабочую копию вам необходимо закоммитить их в свою ветку.
В комментарии укажите диапазон редакций, включенных в ваше текущее слияние.
То есть, например, так: «слито из транка r1234:1256».
Этот комментарий послужит вам напоминанием, и вы сможете в любой момент увидеть, когда вы в последний раз объединялись и какая редакция является последней.
Такие комментарии обязательно включать, иначе будут большие проблемы и недопонимания.
И далее.
Чтобы быть уверенным, что все успешно сольется, перед самим копированием можно сначала провести тест. Для этого используйте опцию --dry-run, которая показывает только выходные данные без внесения изменений в рабочую копию.
Итак, увидеть изменения из транка можно следующей командой: svn merge - r4106:HEAD svn://svnserver/var/bump/trunk .
/ --dry-run
Например, мы получаем следующий вывод: --- Merging r4107 into '.
':
U db/queries.txt
U ejb/src/main/java/ru/bump/action/folder/MoveFolderActionLocal.java
U ejb/src/main/java/ru/bump/action/user/UserRegistrationAction.java
Это значит, что в ревизии r4107 изменено 3 файла.
Отлично, все правильно, скопируйте изменения svn merge - r4106:HEAD svn://svnserver/var/bump/trunk .
/
И мы обязуемся: svn ci -m "merged from trunk r4106:4108"
Число 4108 — это номер текущей версии.
Это легко получить.
Просто запустите команду svn up. Обратите внимание, что число 4106 в данном случае — это ревизия создания нашей ветки.
При первом слиянии вам нужно будет узнать номер этой ревизии.
Это легко, просто запустите команду svn log --stop-on-copy
Этот номер вам больше не понадобится.
Номер нужной вам ревизии вы можете узнать из вашего комментария.
Таким образом, при следующем слиянии вам необходимо узнать номер ревизии последнего слияния.
Например, в Linux я делаю это: #:~/www/bump$ svn log | grep merged
merged from trunk r4106:4108
Таким образом, чтобы снова слить из транка нужно выполнить команду svn merge - r4109:HEAD svn://svnserver/var/bump/trunk .
/
Завершение задачи
Если задание выполнено, нужно
* Объедините ваши изменения в багажник
*Удалите свою тему, чтобы она не мешала
Сливаем его в транк той же командой merge. Для этого узнаем ревизию создания ветки, и переключимся на транк.
svn switch svn://svnserver/var/bump/trunk
После этого скопируйте изменения из вашей ветки #svn up
At revision 4155
#svn merge svn://svnserver/var/bump/trunk@4155 svn://svnserver/var/bump/branches/my-branch@4155
Если все прошло успешно, конфликтов нет и ничего доделывать не нужно, фиксируем изменения в основную ветку, и теперь вы можете удалить свою ветку.
Он ничем не отличается от ствола, и при необходимости мы всегда можем создать еще одну ветку.
И стоит помнить, что наша ветка, конечно, не удаляется физически, она просто удаляется из HEAD, но в ранних ревизиях мы всегда можем ее найти и восстановить при необходимости.
Так что будьте смелее: svn delete svn://svnserver/var/bump/branches/my-btanch -m "Removing my-branch branch."
Кстати, удалять ветку после слияния задачи в транк не обязательно.
Удаление ветки обязательно при выполнении задачи, а слияние в ствол не означает, что задача полностью выполнена.
Теоретически вы можете объединять свои изменения (как полностью, так и частично) несколько раз в процессе работы над задачей, например, если задача разбита на этапы, каждый из которых является завершенным и работоспособным.
Или, например, внесенные вами изменения нужны (или могут быть полезны) другим разработчикам, но не мешают работе всего приложения (новые библиотеки или дополнения к интерфейсу существующих библиотек и классов).
В общем, решение о слиянии своих изменений в транк должен принимать программист (или группа) — владелец ветки.
Что, конечно, не исключает возможности посоветоваться с кем-нибудь, если есть сомнения.
В принципе, желательно стараться избегать каких-либо существенных расхождений между стволом и другими ветвями, если, конечно, это не мешает проекту.
Заключение В данной статье содержится лишь малая часть информации о работе с филиалами.
Он может служить напоминанием, но не учебным пособием.
Поэтому настоятельно рекомендуется прочитать соответствующий раздел svnbook. Он содержит много информации, которая не вошла в этот опус, но необходима для понимания того, как работать с ветками.
Теги: #svn #subversion #ветви #Системы контроля версий
-
Уход За Детской Ванной
19 Oct, 24 -
Уолд, Джордж
19 Oct, 24 -
Книги Для Работы В It-Компаниях
19 Oct, 24 -
Маршруты Твоего Города!
19 Oct, 24 -
Sipnet Договорилась С Почтовым Мессенджером
19 Oct, 24 -
Google Требует Отдать Тв-Частоты Под Трафик
19 Oct, 24 -
Как Мы Живем Год Без Звездочек И С Реакцией
19 Oct, 24
