Требуется ли управление версиями для небольшой группы разработчиков (1-2 программиста)?

Ответ 1

Я просто собираюсь здесь и говорю "ДА". Как @17 из 26 сказал

Отсутствие какого-то контроля источника - это чистое безумие.

Это правда. Я делал небольшие проекты как с контролем, так и без него (не на мой выбор). Без, это просто отстой. Канонической версии проекта нет, вы никогда не знаете, кто имеет что и слияние изменений - это упражнение в боли.

Действительно, все, что угодно, около 5 строк кода должно быть под управлением какого-то типа.

Ответ 2

Вы всегда, всегда хотите иметь какой-то контроль над версиями, даже если вы сами работаете над проектом.

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

Отсутствие какого-то контроля источника - это чистое безумие.

Ответ 3

Определенно да.

Даже если вы один программист, вам нужен контроль версий. Простота, с которой вы можете сравнить код с любым снимком во времени, бесценна.

Мой совет - пойдите для этого!

[Как только я жил без контроля версий. Теперь я больше не могу.]

Ответ 4

Я ОДИН программист, и я считаю его бесценным, так как иногда я хочу отбросить назад или сравнить что-то с более ранней версией.

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

Это отличный способ отслеживать ваше развитие.

Ответ 5

Subversion - абсолютно нет. Он централизован, и поддержка слияния не очень хороша.

Контроль версий - абсолютно ДА! Даже разработчик соло нуждается в этом!

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

• git
• ртутный
• Darcs

Да, есть кривая обучения. Пойдите распределены, вы можете это изучить. И да, вы можете поблагодарить меня позже.

А где живут распределенные хранилища? Вот несколько идей:

• в вашей персональной карте памяти USB (и не ограничивайте себя одним USB-накопителем, распространяйте их также в нескольких местах, например, в вашем банке).
• другой в безопасном месте (вне места, в другом месте, на другой стороне сети), где пожары, землетрясения или торнадо не могут повредить ваш источник одновременно) в качестве резервной копии
• один в централизованном сервере, ваш или что-то вроде github
• несколько копий на машинах разработчика
• промежуточное хранилище где-то рядом с промежуточным сервером
• производственный репозиторий где-то рядом с производственным сайтом

Ответ 6

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

Даже если вы одинокий разработчик, он будет

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

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

Это всего лишь основы, которые помогут вам выиграть любой аргумент о том, использовать ли контроль версий.

Ответ 7

Я программист "одного человека", и я, наконец, начал использовать управление версиями, когда обнаружил, что копирую все приложения и помещая их в папку под названием "backup", а затем называя их чем-то вроде "20080122-backup". Я думаю, что многие люди начинают этот путь. Таким образом, вопрос заключается не в том, следует ли вам использовать контроль версий, а скорее, если вы сделаете это правильно или вы должны взломать часть наполовину домашнего факсимильного сообщения?

Ответ 8

Контроль версий необходим только там, где число программистов составляет > 0.

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

Помимо этого - найдите систему, которая позволяет вам совершать ранние действия и совершать часто.

Я почти странно, хотя это может звучать - направляя взгляд на то, что каждый проект, даже один из разработчиков, должен смотреть на непрерывную интеграцию, то есть иметь эту систему, построенную и протестированную с нуля, каждый раз, когда изменения совершаются или, по крайней мере, на регулярной основе. Зачем? Это а) дает вам уверенность в том, что в VCS есть встроенная система и b) убедитесь, что на самом деле у вас есть чистые сборки для тестирования и развертывания.

Ответ 9

Я не знаю о Subversion в частности, но я считаю, что каждый проект, даже один с одним разработчиком, должен использовать контроль версий. Я бы рассмотрел несколько вариантов (CVS, SubVersion, git, Bazaar, Visual SourceSafe) и посмотрел, какие из них соответствуют вашей команде, наилучшим образом.

Ответ 10

Контроль версий - это самый важный инструмент, который имеет программист, даже более важный, чем реальные языки программирования. Независимо от того, сколько у вас пользователей, всегда необходимо контролировать источник. Я не знаю, сколько раз я сделал перерыв, а затем нужно вернуться и работать над старым кодом или по крайней мере просто посмотреть, как работает исходный код. Я работаю в небольших командах, и мы используем SVN Notifier, чтобы сообщить нам, когда дела идут. Это позволяет нам пересматривать работу друг друга, и вы не получаете страшный "Вы еще проверили свой код?" вопросы все время. Использование исходного управления с самого начала позволит устранить многие головные боли (перезаписывает, утерянный код, борется за то, кто изменил что), с которыми вы можете столкнуться.

Ответ 11

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

И вы можете создать резервную копию.

Ответ 12

У меня есть проект, над которым я работаю, и Version Control делает мою жизнь намного проще. Например, скажем, я решил реализовать новую функцию. По какой-то причине, однако, я решу, чтобы мусор это, возможно, я написал это неправильно, возможно, я передумал в его реализации, что бы ни случилось. Все, что мне нужно, это вернуться к предыдущей версии из SVN вместо того, чтобы вручную восстанавливать каждый используемый файл.

Ответ 13

Subversion нет. Но контроль источника.

Ответ 14

Независимо от того, являетесь ли вы одним разработчиком или группой разработчиков, вы должны сделать следующее, прежде чем начинать кодирование НИЧЕГО:

• Настройте систему управления версиями . Используйте любую систему, которая вам нравится, git, SVN, Mercurial. Это не имеет значения, поскольку если вы знаете, как его использовать.
• Настройте совместную система документации. Использование Wiki или trac, или любой другой такой системы вы знаете, как использовать.
• Настройте систему сборки. использование Make, ANT, Maven или любая другая сборка которую вы знаете, как построить.
• Напишите первые тестовые примеры.

Не кодируйте одну строку основного приложения, пока не выполните эти четыре

Ответ 15

Любой, кто не выполняет контроль версий, просто делает это неправильно.

Ответ 16

Управление версиями может иметь следующие преимущества:

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

Но опять же у него также есть свои падения, если вы не выбираете хороший

Ответ 17

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

Ответ 18

ДА!

Извините за крик: -)

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

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

Ответ 19

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

Возможность сохранять контексты, а не только изменения в коде - это отличная вещь, с которой работает элемент управления версиями, вы переходите от "file this and that changed in line blah" к "Я добавил новый вариант..." что действительно ценно.

Не слушайте меня, хотя есть замечательная статья, которую rands написал об этом

Захват контекста

Ответ 20

ДА, но только для групп разработчиков, размер которых составляет > 0

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

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

Ответ 21

Я бы сказал, для git, по двум основным причинам

• тривиально настроить репо. cd в каталог, git init, и все готово
• регистрация! использование VS любого рода позволяет легко/очевидно/просто регистрировать, почему вы вносите изменения. наличие dvcs, в частности, делает его очень быстрым и легким для восприятия, когда, что и почему сделали изменения. Поскольку dvcs имеет длинную информацию локально, она быстро и легко просматривается, в отличие от svn на удаленных машинах.

[это, по-видимому, верно и для Mercurial. Они уверены, что это не так легко для подрывной деятельности.]

Ответ 22

Каждый, кто говорит, что контроль источника для 1-2 разработчиков является обязательным, полностью, совершенно прав. Доверяйте нам: -)

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

Ответ 23

Простой ответ YES.

Не повторять, но этого нельзя сказать достаточно. Вы ДОЛЖНЫ ИМЕТЬ контроль источника. Subversion смехотворно прост и почти нулевое накладное время после его установки. Это не должно занять более 5-20 минут. У вас есть и другие варианты, например GIT. Так что просто выберите один и поставьте свой источник туда - конец ответа.:)

Ответ 24

Управление версией ДА, вам всегда нужно выполнить контроль версий.

SVN? нет.. меня, я использую Git.

Ответ 25

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

Аналогично с выбором не использовать контроль версий....

Ответ 26

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

Но преимущества возможности отката назад к предыдущей (рабочей) версии и возможности сделать простой diff проверенных файлов будут более чем достойными.

Самая большая проблема заключается в том, что вознаграждение - как и большинство вещей - происходит после "тяжелой работы".:)

Обратите внимание, что другое, но более легкое решение может включать в себя "Теневое копирование" в Windows, если ваш сервер os (хотя, я думаю, этого не будет). Плюсом этого является то, что вы не будете беспокоить своих со-разработчиков с помощью обучения subversion, но при необходимости сможете вернуться к старой версии...

Ответ 27

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

Ответ 28

VSS отлично, но много динеро.

Ответ 29

попробуйте mercurial (hg) вместо svn

Ответ 30

Да, если вы профессиональный разработчик, вам абсолютно необходимо использовать контроль версий!