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

Question

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

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

Золотое правило для контроля источников: Заезд рано, Заезд часто

Советы по организации хранилища:

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

Answer 4

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

Answer 5

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

Answer 6

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

Answer 7

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

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

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

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

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

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

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

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

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

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

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

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

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

---

Answer 8

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

• Не нарушайте сборку (mainline)!

• Фиксация при изменении логической единицы

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

• Небольшое разветвление / слияние насколько возможно

.

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

Answer 9

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

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

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

Answer 10

Работает ли DEV на филиалах

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

Ствол сообщества

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

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

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