Использование SVN отдельно или в небольших рабочих группах - подход рабочего процесса?

Question

Я провел несколько месяцев, работая над веб-приложением, и мы подошли к стадии производства. Скоро пришло время расширить группу разработчиков с помощью 1-3 человек.

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

Рабочий процесс кажется немного более сложным с SVN, и хотя я прочитал Контроль версий с Subversion от O'Reilly Media , и я пока не уверен, является ли излишним использование SVN для каких-либо причины помимо резервного копирования при разработке в одиночку или в небольшой (1-3 человека) рабочей группе?

Как ты это делаешь? Каков ваш рабочий процесс с контролем версий при работе в одиночку или в небольших рабочих группах?

Спасибо!

Answer 1

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

Answer 2

Как и любой SCM, это определенно на больше , чем резервное копирование.

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

Я не развиваюсь самостоятельно без SCM, не говоря уже о других разработчиках. Это основной инструмент в вашем наборе инструментов, и его стоит получить au fait раньше, чем позже.

Какой у меня рабочий процесс? Это зависит от команды и используемого СКМ.

1. Если SCM хорошо это поддерживает (например, Git), я создам ветку для каждой ошибки / функции. SVN не очень горячий при ветвлении, так что это может не применяться.
2. Я регулярно проверяю / объединяю . Если вы делаете это не часто, кодовая база будет отклоняться от вашей рабочей кодовой базы, и последующее объединение станет более трудным. Кроме того, вы хотите, чтобы члены вашей команды имели представление о том, что вы делаете.
3. Мой процесс непрерывной интеграции (например, я использую движок непрерывной сборки, такой как TeamCity / Cruisecontrol / Hudosn) будет собирать / тестировать и, при желании, отмечать выпуск после успешного цикла сборки / тестирования.
4. Я создам ветку для окончательного выпуска и отработаю это для обслуживания после выпуска.

Answer 3

К ответу Брайана нечего добавить. В качестве альтернативы вы можете взглянуть на распределенные системы контроля версий (DSCM), такие как Mercurial, Git или Bazaar. ИМХО, они идеально подходят для небольших групп разработчиков, очень просты в настройке, но, тем не менее, их можно масштабировать до больших проектов.

Хорошее вводное руководство по Mercurial, написанное Джоэлем Спольски, можно найти на http://hginit.com/.

макет хранилища http://hginit.com/i/05-complex.png