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

Когда кто-то попросил веских оправданий не использовать контроль версий , они получили 75 ответов и 45 голосов «за».

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

Может быть, вы найдете там что-нибудь полезное.

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

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

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

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

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

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

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

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

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

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

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

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

Мы используйте как CVS (для проектов, отличных от .NET), так и TFS (для проектов .NET), где я работаю, а в репозитории TFS есть папка Developer Sandbox, в которой разработчики могут проверять личные экспериментальные проекты (прототипы).

Если и когда проект начинает использоваться в производственной среде, код перемещается из папки Developer Sandbox в свою собственную папку в основном дереве.

Лично я часто начинаю контроль версий после первой успешной компиляции.

Мне просто интересно, почему никто не упомянул распределенные системы контроля версий в этом контексте: если бы вам удалось переключиться на распределенную system (git, bazaar, mercury), большинство аргументов вашей второй группы станут бессмысленными, поскольку они могут просто запустить свой репозиторий локально и отправить его на сервер, когда захотят (и они также могут просто удалить его, если захотят перезапустить с царапина).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

некоторые люди могут учиться только на собственном опыте.

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

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

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

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

Вот моя точка зрения на вашу точку зрения.

1) Даже разработчикам-одиночкам нужно где-то хранить свой код, когда их ПК выходит из строя. Что произойдет, если они случайно удалят файл без контроля версий?

2/3) Прототипы принадлежат системе контроля версий, поэтому другие члены команды могут посмотреть код. Мы помещаем наш код прототипа в отдельное место в основной ветке. Мы называем это Спайком. Вот отличная статья о том, почему вы должны сохранить код Спайка - http://odetocode.com/Blogs/scott/archive/2008/11/17/12344.aspx

Вам не нужны «аргументы, чтобы убедить их». Дискурс - это не игра, и вам не следует использовать свою работу как платформу для обсуждения. Для этого нужен ваш супруг :) Если серьезно, вам нужно объяснить, почему вас волнует, как другие разработчики работают над сольными проектами, в которых другие люди не участвуют. Что вам не хватает, потому что они не используют систему контроля версий? Вам нужно увидеть их ранние идеи, чтобы понять их более поздний код? Если вам удастся это сделать, вы сможете их убедить.

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

Пока я отвечаю на вопрос вопросом, позвольте мне задать еще один: нужно ли вашему коду компилировать / работать / не нарушать сборку для проверки? Мне нравится, когда мои ветки становятся хорошими и ломаются, а затем исправляются, работают, отлаживаются и т. Д. В то же время мне нравится, когда другие разработчики используют систему управления версиями, как они хотят. Филиалы были изобретены именно по этой причине: чтобы люди, которые не могут ладить, не должны были жить вместе.

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

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

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

Посмотрим их аргументы:

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

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

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

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

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