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