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

Question

В моем магазине 2 типа людей:

1. Те, которые начинают проверять код с момента первой успешной компиляции.
2. Другие, которые проверяют код только тогда, когда проект почти завершен.

Я являюсь частью группы 1 и пытаюсь убедить людей из группы 2 вести себя как я. Их аргументы похожи на следующие:

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

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

Answer 1

Я бы хотел добавить две вещи. С контролем версий вы можете:

• Вернитесь к последней версии, которая работала, или хотя бы проверьте, как она выглядела. Для этого вам понадобится SCM, который поддерживает changesets / использует фиксации всего дерева.
• Используйте его для поиска ошибок, используя так называемую ' diff debugging ', найдя коммит в истории, в которой была обнаружена ошибка. Вы хотели бы, чтобы SCM поддерживал его в автоматическом или полуавтоматическом режиме.

Answer 2

Давайте посмотрим их аргументы:

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

Во-первых, третий. Я вижу причину, но она основана на неверном предположении.
На работе мы используем Perforce, централизованную VCS, и на самом деле мы проверяем только тот исходный код, который успешно компилируется и ничего не нарушает (теоретически, конечно!) После экспертной оценки.

Поэтому, когда я начинаю нетривиальное изменение, я чувствую необходимость в посреднических коммитах. Например, недавно я начал вносить некоторые изменения (как-то в одиночку для этой конкретной задачи, поэтому я обращаюсь к пункту 1) в коде Java с использованием JDom (синтаксический анализ XML). Затем я застрял и захотел использовать встроенный в Java 1.6 синтаксический анализ XML. Очевидно, пришло время следить за текущей работой, если моя попытка не удалась и я захочу вернуться. Обратите внимание, что этот случай как-то обращается к точке 2.

Решение, которое я выбрал, простое: я использую альтернативный SCM! Хотя некоторые централизованные VCS, такие как SVN, можно использовать локально (на компьютере разработчика), меня соблазнила распределенная VCS, и после краткого тестирования Mercurial (что хорошо) я обнаружил, что Bazaar лучше подходит для моих потребностей и вкуса.
DVCS хорошо подходит для этой задачи, потому что они легки, гибки, допускают альтернативные ветви, не «загрязняют» исходный каталог (все данные находятся в одном каталоге в корне проекта) и т. Д.
Делая параллельное управление источниками, вы не загрязняете источник других разработчиков, сохраняя возможность вернуться назад или быстро попробовать альтернативные решения.

В конце концов, после передачи окончательной версии официальному SCM, результат тот же, но с дополнительной безопасностью на уровне разработчика.

Answer 3

Я бы сказал им ...

Я сольный разработчик этого проекта.

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

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

svn ci <files> -m " implement ajax support for grid control

В следующий раз, когда кто-то новый захочет внести некоторые изменения в элемент управления сеткой или сделать что-то связанное, у них будет отличная отправная точка. Все проекты начинаются с одного или двух человек. Управление исходным кодом стало проще, чем когда-либо, - они договорились с ними о 30-минутной демонстрации Tortoise SVN?

Это всего лишь прототип, возможно, мне придется снова переписать с нуля.

Они обеспокоены хранением? Хранение дешево. Они обеспокоены потерей времени на управление версиями? Это занимает меньше времени, чем проверка по электронной почте. Если они перезаписывают биты, контроль источника становится еще более важным, чтобы иметь возможность ссылаться на старые биты.

Я не хочу загрязнять систему контроля версий неполными версиями.

Это на самом деле хорошая забота. Раньше я думал об одном и том же и избегал проверять код, пока он не стал красивым и чистым, что само по себе неплохо, но много раз я просто хотел бездельничать. На этом этапе изучение ветвления помогает. Хотелось бы, чтобы у SVN была полная поддержка очистки папок, таких как Perforce.

Answer 4

Я проверяю проект в системе контроля версий перед тем, как начать кодирование. Первое, что я делаю, - это создаю и организую проекты и файлы поддержки (например, файлы .sln в разработке .NET) с необходимыми библиотеками поддержки и инструментами (обычно в папке lib), которые я знаю, которые я буду использовать в своем проекте. Если у меня уже есть некоторый написанный код, я тоже добавляю его, даже если это неполное приложение. Тогда я проверяю все. Оттуда все как обычно, напиши какой-нибудь код, скомпилируй, протестируй, зарегистрируйся ...

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

Answer 5

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

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

Answer 6

Это называется ветвлением, которое люди пытаются получить с помощью программы: p Прототип? Работа в филиале. Экспериментируя? Работа в филиале. Новая функция? Работа в филиале.

Объедините свои ветви в основной ствол, когда это имеет смысл.

Answer 7

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

Поэтому, когда я начинаю создавать прототипы, я могу создать проект, а затем перед его сборкой я делаю "git init, git add., Git commit -a -m ...", чтобы когда я захотел переместить интересные части, я просто клонируйте с помощью git, и тогда я смогу добавить его в хранилище subversion или что-то еще, где я сейчас работаю.

Answer 8

Любая приличная современная платформа управления исходным кодом (из которых VSS не является одной) никоим образом не должна быть загрязнена, помещая в нее файлы исходного кода. Я придерживаюсь мнения, что все, что имеет ожидаемую продолжительность жизни больше, чем примерно 1/2 часа, должно находиться под контролем источника как можно раньше. Solo develpment больше не является оправданием для отказа от управления исходным кодом. Речь идет не о безопасности, а об ошибках и долгосрочной истории.

Answer 9

Я пьян и сначала делаю git -init, а затем vim foo.cpp.

Answer 10

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