Я начинаю с SVN. Я знаю основные команды и понимаю основные принципы. Мне было интересно, есть ли у кого-нибудь советы или передовые методы работы с Subversion в командной среде.
Я вижу преимущества добавления достаточно подробных сообщений при фиксации кода, но есть ли другие вещи, о которых я должен помнить?
Спасибо за отличные ответы - они очень помогли.
Ответы:
Поощряйте частые коммиты. Товарищи по команде, плохо знакомые с контролем версий, могут подумать, что им нужно держать код вне репозитория, пока «он не заработает правильно». Учите всех совершать действия как можно раньше и как можно быстрее находить проблемы. Вместо того, чтобы держать код до тех пор, пока он не заработает, предложите своим товарищам по команде создать ветки для функции, которая может сломать ствол. Это приводит к ...
Установите практику ветвления и тегирования. В дополнение к веткам для функций, поощряйте своих товарищей по команде использовать ветки для исправления крупных ошибок. Отметьте основные исправления ошибок в начале и в конце работы. Поддерживайте теги (и, возможно, ветки) для производственных / qa-выпусков.
Установите политику для транка и придерживайтесь ее. Например, «ствол всегда должен строиться без ошибок». или «магистраль всегда должна проходить все модульные тесты». Любая работа, которая еще не соответствует стандартам ствола, должна выполняться в филиале.
Не фиксируйте изменения форматирования с изменениями кода
Если вы хотите реструктурировать пробелы в гигантском файле ( Control+ K+ D), отлично. Зафиксируйте изменение форматирования отдельно от фактического логического изменения. То же самое происходит, если вы хотите перемещать функции в файлах. Зафиксируйте перемещение отдельно от фактического редактирования.
Одна из ключевых концепций, которой я всегда придерживаюсь, - это совместная фиксация связанных изменений кода . Следствие - не фиксируйте несвязанные изменения кода в одном коммите . Это означает, что не исправляйте 2 ошибки за одну фиксацию (если это не одно и то же исправление) и не фиксируйте половину исправления ошибки в каждой из 2 фиксаций. Кроме того, если мне нужно добавить какое-то новое улучшение или что-то еще в несвязанную часть системы, которая мне понадобится для какой-то другой работы, я фиксирую это улучшение отдельно (и сначала). Идея состоит в том, что любое изменение, которое кто-то может захотеть внести самостоятельно (или откатиться самостоятельно), должно быть отдельным коммитом. Это избавит вас от множества головных болей, когда придет время делать слияние или откатывать сломанные функции.
Уже много было сказано, и вот еще несколько:
Если у вас есть файлы, которые вам не нужны в системе контроля версий (например, конфигурация, скомпилированные файлы и т. Д.), Добавьте их в список игнорирования . Таким образом, вы замечаете любые файлы, которые вы забыли добавить, всегда ожидая пустой список файлов, показываемых SVN как неизвестные.
Добавьте событие post-commit, которое отправит электронное письмо в список рассылки вашего разработчика (или в список, предназначенный для этой цели), касающийся зафиксированного изменения и, в идеале, патча для него.
Выполните интеграцию с вашим трекером ошибок, чтобы ссылки на коммиты отображались в запросах ошибок / функций со ссылками на различия. Такие средства отслеживания ошибок, как MantisBT, поддерживают это.
Рассмотрите возможность интеграции с непрерывной интеграцией (например, CruiseControl.NET ), NAnt для сборки и NUnit / VS для модульных тестов. Таким образом, после того, как код регистрации пользователя или через запланированный интервал времени, код компилируется, запускаются модульные тесты, и разработчик получает обратную связь о процессе. Это также предупредит остальную команду, если репозиторий сломан (т.е. не строится).
Ну а основы:
Ответы, которые дают люди, прекрасны. Большая часть этого резюмирована в пользовательской документации svn, посвященной лучшим практикам для SVN .
Повторить:
Я хотел бы обобщить лучшие практики, которых я придерживаюсь:
Там должен быть структура репозитория . Лично я использую следующую структуру репозитория:
/trunk
/tags
/builds
/PA
/A
/B
/releases
/AR
/BR
/RC
/ST
/branches
/experimental
/maintenance
/versions
/platforms
/releases
PA(пре-альфа), A(альфа), B(бета),AR (альфа-релиз), BR(бета-версия), RC(релиз-кандидат), ST(стабильный).Вы можете найти схему моих лучших практик по подрывной деятельности в виде диаграммы, иллюстрирующей основные принципы подхода к управлению конфигурацией программного обеспечения, который я использую.
Одна вещь, которую я нашел очень полезной, - это свойство svn: external, которое означает, что вы можете ссылаться на каталоги из других репозиториев в свои собственные. Это дает действительно хорошие способы организации вашего кода и данных. Вот несколько примеров:
Используйте интеграцию с вашим программным обеспечением для отслеживания ошибок. Если вы используете Bugzilla , вы можете настроить его так, чтобы, если ваш комментарий начинается с «Ошибка XXXX», ваш комментарий SVN автоматически добавляется как комментарий к данной ошибке, включая ссылку на ваш веб-интерфейс SVN для этой версии.
Узнайте об инструментах и соглашениях SVN для ветвления и слияния.
Лучший способ работать с другими членами команды - разбить работу на полные функции / исправления разработки, а затем работать над отдельными изменениями, каждое в своей ветке. Затем объедините изменения обратно в основную ветку / магистраль, когда они будут завершены / готовы / утверждены для объединения.
Таким образом, люди могут работать над достижением общей цели (в одной или в разных ветвях), не сталкиваясь с другими изменениями.
Ваш пробег может отличаться, и это может оказаться излишним только для двух человек.
Это значительно упрощает работу, если вы используете хорошие инструменты, которые хорошо интегрируются с SVN. Это позволяет легко увидеть, что было изменено, а затем зафиксировать все или часть ваших изменений и часто обновлять вашу рабочую копию до последней версии в SVN.
Я рекомендую Tortoise SVN (если вы используете Windows) и Visual SVN. (если вы используете VS).
Также посмотрите, можете ли вы настроить его так, чтобы вы получали электронное письмо или подобное уведомление каждый раз, когда изменение зафиксировано (обычно также включая сообщение фиксации и список измененных файлов). Такие сервисы, как CVSDude, предлагают это. Я считаю полезным знать, что обновление было сделано, а затем иметь некоторое представление о том, что содержится в этом обновлении, перед обновлением моей рабочей копии.
Помимо политики ветвления и др. (где один размер определенно не подходит всем), у вас должны быть хорошие коммиты:
Золотое правило управления версиями: версий зарегистрируйтесь рано, проверяйте часто
Советы по организации репозитория:
Проконсультируйтесь со своей командой об их изменениях или, по крайней мере, внимательно посмотрите на разницу, прежде чем исправлять любые конфликты слияния. Попросите их сами просмотреть объединенный код, чтобы убедиться, что их добавления не были потеряны при объединении.
Одна вещь, которую я видел, которая уменьшает количество неработающих коммитов, - это наличие хороших сценариев перед фиксацией. Например, вы можете запустить любые модульные тесты до того, как изменение будет зафиксировано. Это приведет к тому, что коммиты будут немного медленными, но вы сэкономите время, не наступая кому-то на пальцы ног и не извиняясь. Конечно, управлять этим становится намного сложнее, когда у вас большая команда разработчиков и очень частые коммиты.
Одним из примеров интеграции с системой отслеживания ошибок и принудительного применения политик фиксации могут быть сценарии ловушек svn pre / post-commit в Trac , которые могут отклонять фиксацию, если сообщение фиксации не ссылается на какой-либо тикет в трекере ошибок и добавляет комментарии к существующим. билеты на основе содержимого сообщения (то есть сообщение фиксации может содержать что-то вроде «Исправления №1, №2 и №8», где №1, №2, №8 - номера билетов).
Лучшая практика использования SVN :
Когда вы впервые пришли в офис и открыли свой проект Eclipse , первым делом необходимо обновить ваш проект.
Взяв обновление, приступайте к работе. Когда вы закончите кодирование, проверьте его должным образом, правильно ли работает ваше приложение без каких-либо исключений. Если вы уверены, что ваш код работает нормально, самое время зафиксировать код.
Примечание. При фиксации кода не выполняйте фиксацию напрямую. Сделайте синхронизацию с сервером и проверьте, что все нужно зафиксировать. Примечание: не фиксируйте всю папку сразу. Потому что вы, возможно, внесли некоторые изменения в файл в соответствии с вашими требованиями или удалили некоторые файлы в своей локальной системе. Но на сервере настройки другие. Поэтому проверьте файлы по отдельности и зафиксируйте код.
Не фиксируйте / не обновляйте файлы конфликтов напрямую.
Когда делать переопределение и обновление?
Когда вы почти уверены, что вам не нужны никакие локальные изменения, и хотите полностью обновить серверную копию. Обратите внимание, что если вы однажды выполните переопределение и обновление, вы не получите никаких локальных изменений.
Примечание. Не храните проект без обновления более суток. Также не храните код без коммитов в течение многих дней.
Сообщите, кто все работает над одним компонентом, и обсудите, какие изменения они вносили каждый день.
Не фиксируйте файл свойств и конфигурации, если для этого нет причины. Потому что настройки будут разными на сервере и в облаке.
Не фиксируйте целевые папки в SVN, в репозитории SVN должны храниться только исходный код и папки ресурсов.
Если вы потеряли свой код, не паникуйте! Вы можете вернуть более раннюю копию из истории SVN.
Не размещайте проект в нескольких местах на диске. Оформляйте заказ в одном месте и работайте с ним.
SVN сам по себе является хорошим началом, и некоторые другие плакаты предлагали несколько отличных рекомендаций по передовому опыту.
Единственное, что я хотел бы добавить, это то, что вы должны подключить SVN с CruiseControl или TeamCity, чтобы управлять процессом непрерывной интеграции. Это будет отправлять электронные письма о сборке и сообщать всем, когда кто-то сломал сборку.
С самого начала будет очень понятно, кто следит за вашим процессом, а кто нет. Это может привести к трениям, но в долгосрочной перспективе ваша команда будет лучше.
Точный комментарий для каждой фиксации
Не ломайте (основную) сборку!
Зафиксируйте, как только изменится логическая единица
Избегайте использования Subversion в качестве инструмента резервного копирования
По возможности небольшое ветвление / слияние
.
Более подробную информацию можно найти в лучших практиках SVN .
Помните, что чем более инкрементными, модульными, дискретными и лаконичными вы делаете свои коммиты, тем легче вам (или, вероятно, другим) будет:
Используйте это для шаблона комментариев:
[задача / история xxx] [второстепенная / основная] [комментарий] [последующий комментарий] [URL-адрес ошибки]