Лучшие практики SVN - работа в команде

Я начинаю с SVN. Я знаю основные команды и понимаю основные принципы. Мне было интересно, есть ли у кого-нибудь советы или передовые методы работы с Subversion в командной среде.

Я вижу преимущества добавления достаточно подробных сообщений при фиксации кода, но есть ли другие вещи, о которых я должен помнить?

Спасибо за отличные ответы - они очень помогли.

Поощряйте частые коммиты. Товарищи по команде, плохо знакомые с контролем версий, могут подумать, что им нужно держать код вне репозитория, пока «он не заработает правильно». Учите всех совершать действия как можно раньше и как можно быстрее находить проблемы. Вместо того, чтобы держать код до тех пор, пока он не заработает, предложите своим товарищам по команде создать ветки для функции, которая может сломать ствол. Это приводит к ...

Установите практику ветвления и тегирования. В дополнение к веткам для функций, поощряйте своих товарищей по команде использовать ветки для исправления крупных ошибок. Отметьте основные исправления ошибок в начале и в конце работы. Поддерживайте теги (и, возможно, ветки) для производственных / qa-выпусков.

Установите политику для транка и придерживайтесь ее. Например, «ствол всегда должен строиться без ошибок». или «магистраль всегда должна проходить все модульные тесты». Любая работа, которая еще не соответствует стандартам ствола, должна выполняться в филиале.

Не фиксируйте изменения форматирования с изменениями кода

Если вы хотите реструктурировать пробелы в гигантском файле ( Control+ K+ D), отлично. Зафиксируйте изменение форматирования отдельно от фактического логического изменения. То же самое происходит, если вы хотите перемещать функции в файлах. Зафиксируйте перемещение отдельно от фактического редактирования.

Одна из ключевых концепций, которой я всегда придерживаюсь, - это совместная фиксация связанных изменений кода . Следствие - не фиксируйте несвязанные изменения кода в одном коммите . Это означает, что не исправляйте 2 ошибки за одну фиксацию (если это не одно и то же исправление) и не фиксируйте половину исправления ошибки в каждой из 2 фиксаций. Кроме того, если мне нужно добавить какое-то новое улучшение или что-то еще в несвязанную часть системы, которая мне понадобится для какой-то другой работы, я фиксирую это улучшение отдельно (и сначала). Идея состоит в том, что любое изменение, которое кто-то может захотеть внести самостоятельно (или откатиться самостоятельно), должно быть отдельным коммитом. Это избавит вас от множества головных болей, когда придет время делать слияние или откатывать сломанные функции.

Уже много было сказано, и вот еще несколько:

1. Если у вас есть файлы, которые вам не нужны в системе контроля версий (например, конфигурация, скомпилированные файлы и т. Д.), Добавьте их в список игнорирования . Таким образом, вы замечаете любые файлы, которые вы забыли добавить, всегда ожидая пустой список файлов, показываемых SVN как неизвестные.

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

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

4. Рассмотрите возможность интеграции с непрерывной интеграцией (например, CruiseControl.NET ), NAnt для сборки и NUnit / VS для модульных тестов. Таким образом, после того, как код регистрации пользователя или через запланированный интервал времени, код компилируется, запускаются модульные тесты, и разработчик получает обратную связь о процессе. Это также предупредит остальную команду, если репозиторий сломан (т.е. не строится).

Ну а основы:

• Создавайте теги перед началом контроля качества версии
• Создавайте теги перед опасными изменениями (например, крупными рефакторами)
• Создайте ветки для выпущенных версий, чтобы заморозить код.
• Убедитесь, что люди знают, что нужно обновлять, прежде чем начинать работу над фрагментом кода, и обновите его еще раз перед его фиксацией.
• SVN позволяет разным пользователям многократно извлекать один и тот же файл. Убедитесь, что каждый разрешает любой конфликт, который может возникнуть.
• Никогда не используйте одну и ту же учетную запись SVN более чем для одного пользователя. Это может привести к ужасным вещам.

Ответы, которые дают люди, прекрасны. Большая часть этого резюмирована в пользовательской документации svn, посвященной лучшим практикам для SVN .
Повторить:

1. Настройте структуру репозитория (у вас должен быть корень проекта со стволом, ветками и тегами под ним)
2. Выберите ветвление своей политики (частные ветки, ветки по этапам / выпускам / ошибкам и т. Д.) И придерживайтесь их - я бы рекомендовал больше ветвлений, чем меньше, но нет необходимости в частных ветвях
3. Выберите повторную маркировку политики - чем больше тегов, тем лучше, но, что важнее, определитесь с соглашениями об именах тегов.
4. Выберите политику повторной фиксации в транке - держите транк как можно более «чистым», он должен быть доступен для выпуска в любое время.

Я хотел бы обобщить лучшие практики, которых я придерживаюсь:

1. Не фиксируйте двоичные файлы . Должен быть отдельный репозиторий для двоичных файлов, таких как Nexus , Ivy или Artifactory .

2. Там должен быть структура репозитория . Лично я использую следующую структуру репозитория:

   /trunk
   /tags
       /builds
           /PA
           /A
           /B
       /releases
           /AR
           /BR
           /RC
           /ST
   /branches
       /experimental
       /maintenance
           /versions
           /platforms
       /releases
   

3. Используйте определенный список типов веток . Мой список следующий: экспериментальный , обслуживающий , версии , платформы , выпуски .
4. Используйте определенные типы тегов : PA(пре-альфа), A(альфа), B(бета),AR (альфа-релиз), BR(бета-версия), RC(релиз-кандидат), ST(стабильный).
5. Минимизируйте необходимость слияния . Должны быть правила, когда слияние возможно / поощряется, а когда нет.
6. Нумерация версий . Должен быть установлен подход к нумерации версий, которого следует придерживаться. Обычно он описывается в таком документе, как План управления конфигурацией программного обеспечения, является частью высокоуровневой проектной документации. Лично я использую комплексный подход к нумерации версий. Согласно этому подходу, версии имеют следующие шаблоны: Nxx (ветви обслуживания / поддержки), NMx (ветвь выпуска), NxK. (сборка), NMK (выпуск).
7. Делайте как можно чаще . Если это может быть сложно (например, когда необходимо внести слишком много изменений, чтобы реализовать функцию и даже скомпилировать код), следует использовать экспериментальные ветви.
8. Багажник должен содержать последнюю разработку . Например, когда есть выбор , где разработать новую основную версию ( Nxx ) применений, в багажнике или в отрасли, решение должно быть всегда в пользу ствола . Старая версия должна быть переведена в ветку обслуживания / поддержки . Предполагается, что существует четкое различие между основными версиями и их особенности (архитектура, совместимость) проявляются как можно раньше. .
9. Строгая политика «не нарушать сборку» в ветках выпуска . Между тем, он не обязательно должен быть строгим для ствола. если он может иметь либо экспериментальную разработку, либо кодовую базу, которая требует решения проблем слияния.
10. Использовать svn: externals . Это позволит разделить ваш проект на модули, установить прозрачную процедуру управления релизами, разделить и победить разную функциональность.
11. Использовать отслеживание проблем . Вы сможете указать ссылку на проблему внутри сообщения фиксации.
12. Отключить пустые сообщения фиксации . Это можно сделать с помощью хуков предварительной фиксации.
13. Определите, какие ветви вы хотите непрерывно интегрировать . Например, я предпочитаю использовать непрерывную интеграцию для магистрали , обслуживания и выпуска. веток.
14. Установить политику непрерывной интеграции для разных типов филиалов. Как я отмечал ранее, самые строгие правила «не нарушайте сборку» применяются к выпускным веткам, в то время как магистральные и обслуживающие ветки могут иногда нарушаться. Также есть разница между списком проверок, запущенных на магистрали / обслуживание и выпуск ветвях .

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

Одна вещь, которую я нашел очень полезной, - это свойство svn: external, которое означает, что вы можете ссылаться на каталоги из других репозиториев в свои собственные. Это дает действительно хорошие способы организации вашего кода и данных. Вот несколько примеров:

1. Если у вас есть отдельные репозитории для кода, разные модули / библиотеки и ссылки на те, которые вы используете. Это означает, что у вас может быть мета-репозиторий для каждого исполняемого файла. Если это небольшой исполняемый файл, который использует только несколько модулей, вам не нужно проверять все дерево. В результате вы получаете номера ревизий SVN для каждого модуля.
2. Добавление больших двоичных данных, таких как скомпилированные версии библиотек, в репозиторий кода обычно считается плохой привычкой, но это может быть действительно удобно. Если вы просто добавите все версии всех используемых вами библиотек в другой репозиторий, вы сможете получить лучшее из двух миров. Вы ссылаетесь на версии используемых вами библиотек в своем репозитории кода. При проверке репозитория кода вы также получите и код, и двоичные файлы. Однако двоичные файлы хранятся в большом репозитории, резервное копирование которого не требуется так тщательно, поскольку исходный код и репозиторий исходного кода остаются небольшими и содержат только текст.

Используйте интеграцию с вашим программным обеспечением для отслеживания ошибок. Если вы используете Bugzilla , вы можете настроить его так, чтобы, если ваш комментарий начинается с «Ошибка XXXX», ваш комментарий SVN автоматически добавляется как комментарий к данной ошибке, включая ссылку на ваш веб-интерфейс SVN для этой версии.

Узнайте об инструментах и ​​соглашениях SVN для ветвления и слияния.

Лучший способ работать с другими членами команды - разбить работу на полные функции / исправления разработки, а затем работать над отдельными изменениями, каждое в своей ветке. Затем объедините изменения обратно в основную ветку / магистраль, когда они будут завершены / готовы / утверждены для объединения.

Таким образом, люди могут работать над достижением общей цели (в одной или в разных ветвях), не сталкиваясь с другими изменениями.

Ваш пробег может отличаться, и это может оказаться излишним только для двух человек.

Это значительно упрощает работу, если вы используете хорошие инструменты, которые хорошо интегрируются с SVN. Это позволяет легко увидеть, что было изменено, а затем зафиксировать все или часть ваших изменений и часто обновлять вашу рабочую копию до последней версии в SVN.

Я рекомендую Tortoise SVN (если вы используете Windows) и Visual SVN. (если вы используете VS).

Также посмотрите, можете ли вы настроить его так, чтобы вы получали электронное письмо или подобное уведомление каждый раз, когда изменение зафиксировано (обычно также включая сообщение фиксации и список измененных файлов). Такие сервисы, как CVSDude, предлагают это. Я считаю полезным знать, что обновление было сделано, а затем иметь некоторое представление о том, что содержится в этом обновлении, перед обновлением моей рабочей копии.

Помимо политики ветвления и др. (где один размер определенно не подходит всем), у вас должны быть хорошие коммиты:

• Если возможно, фиксация должна относиться к одной части работы; исправление ошибки, новая функция - должна быть некоторая «логика» того, какие изменения вы совершили
• У коммита должен быть описательный комментарий, который поможет вам найти его в истории репозитория. Большинство людей предлагают написать в начале одно предложение, описывающее весь коммит, и более подробный отчет ниже.
• Если возможно, вам следует привязать фиксацию к вашей системе отслеживания ошибок. Trac, Redmine и др. позволяют создавать ссылки от ошибок к коммитам и наоборот, что очень удобно.

Золотое правило управления версиями: версий зарегистрируйтесь рано, проверяйте часто

Советы по организации репозитория:

• Как вы организуете свой репозиторий контроля версий?
• SVN Книга Глава 5. Администрирование репозитория
• Макет репозитория

Проконсультируйтесь со своей командой об их изменениях или, по крайней мере, внимательно посмотрите на разницу, прежде чем исправлять любые конфликты слияния. Попросите их сами просмотреть объединенный код, чтобы убедиться, что их добавления не были потеряны при объединении.

Одна вещь, которую я видел, которая уменьшает количество неработающих коммитов, - это наличие хороших сценариев перед фиксацией. Например, вы можете запустить любые модульные тесты до того, как изменение будет зафиксировано. Это приведет к тому, что коммиты будут немного медленными, но вы сэкономите время, не наступая кому-то на пальцы ног и не извиняясь. Конечно, управлять этим становится намного сложнее, когда у вас большая команда разработчиков и очень частые коммиты.

Одним из примеров интеграции с системой отслеживания ошибок и принудительного применения политик фиксации могут быть сценарии ловушек svn pre / post-commit в Trac , которые могут отклонять фиксацию, если сообщение фиксации не ссылается на какой-либо тикет в трекере ошибок и добавляет комментарии к существующим. билеты на основе содержимого сообщения (то есть сообщение фиксации может содержать что-то вроде «Исправления №1, №2 и №8», где №1, №2, №8 - номера билетов).

Лучшая практика использования SVN :

1. Когда вы впервые пришли в офис и открыли свой проект Eclipse , первым делом необходимо обновить ваш проект.

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

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

3. Не фиксируйте / не обновляйте файлы конфликтов напрямую.

4. Когда делать переопределение и обновление?

   Когда вы почти уверены, что вам не нужны никакие локальные изменения, и хотите полностью обновить серверную копию. Обратите внимание, что если вы однажды выполните переопределение и обновление, вы не получите никаких локальных изменений.

   Примечание. Не храните проект без обновления более суток. Также не храните код без коммитов в течение многих дней.

5. Сообщите, кто все работает над одним компонентом, и обсудите, какие изменения они вносили каждый день.

6. Не фиксируйте файл свойств и конфигурации, если для этого нет причины. Потому что настройки будут разными на сервере и в облаке.

7. Не фиксируйте целевые папки в SVN, в репозитории SVN должны храниться только исходный код и папки ресурсов.

8. Если вы потеряли свой код, не паникуйте! Вы можете вернуть более раннюю копию из истории SVN.

9. Не размещайте проект в нескольких местах на диске. Оформляйте заказ в одном месте и работайте с ним.

SVN сам по себе является хорошим началом, и некоторые другие плакаты предлагали несколько отличных рекомендаций по передовому опыту.

Единственное, что я хотел бы добавить, это то, что вы должны подключить SVN с CruiseControl или TeamCity, чтобы управлять процессом непрерывной интеграции. Это будет отправлять электронные письма о сборке и сообщать всем, когда кто-то сломал сборку.

С самого начала будет очень понятно, кто следит за вашим процессом, а кто нет. Это может привести к трениям, но в долгосрочной перспективе ваша команда будет лучше.

• Точный комментарий для каждой фиксации

• Не ломайте (основную) сборку!

• Зафиксируйте, как только изменится логическая единица

• Избегайте использования Subversion в качестве инструмента резервного копирования

• По возможности небольшое ветвление / слияние

.

Более подробную информацию можно найти в лучших практиках SVN .

Работает ли DEV над филиалами

1. Частые коммиты в вашу ветку
2. Дискретные / модульные коммиты в вашу ветку ( см. Здесь )
3. Часто обновляйте / объединяйте из транка. Не садись на свою ветку, не оперевшись

Общественный багажник

1. Всегда должен строить / работать
2. Одна проблема на фиксацию ( снова см. Здесь ) В основном для того, чтобы вы или другие могли откатиться по одному за раз
3. Не объединяйте изменения рефакторинга / пробелов с логическими изменениями. Вашим товарищам по команде будет сложно извлечь из фиксации то, что вы на самом деле сделали.

Помните, что чем более инкрементными, модульными, дискретными и лаконичными вы делаете свои коммиты, тем легче вам (или, вероятно, другим) будет:

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

Используйте это для шаблона комментариев:

[задача / история xxx] [второстепенная / основная] [комментарий] [последующий комментарий] [URL-адрес ошибки]