Коротко о системе контроля версий

Так сложилась ситуация, что у меня вечно все проекты достаточно разветвленные и не совсем простые. Длятся они не днями, а неделями (а то и годами ;)). Практически неизбежна ситуация, когда сегодня ненужный и / или неудачный код станет жизненно необходимым через полгода. Вроде бы и делал, но гарантированно стер.

Нередки ситуации, когда требования конечного потребителя меняются (вплоть до того, что надо восстанавливать исходное положение дел).

В общем и целом - надо хранить историю создания / изменения. Вот об истории и развитии этого дела я и хотел бы поговорить.

Сначала я пошел по пути наименьшего сопротивления: просто комментирование кусков кода, которые не используются. Но тут не все гладко: нередко изменения вносятся не в один, а в несколько функций (файлов). Какие-то создаются, какие-то удаляются за ненадобностью. Отказался достаточно быстро.

Далее - создание архивов с указанием даты и времени. Тоже решение, но обладающее парой минусов: либо безумный объем, требуемый для архивов (это если их создавать "полными"), либо муки с восстановлением (если архивы создаются "по нарастающей", фиксируя только вносимые изменения). И работает такой подход только если разработчик один. Стоит появиться второму / третьему / четвертому, согласование архивов летит в тартарары.

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

Оказывается, есть такая штука, как "система контроля версий" (control version system, CVS). Грубо говоря, это отдельная программа, которая а) хранит всю историю изменений (включая пользовательские комментарии) и б) позволяет очень быстро и просто восстановить состояние отслеживаемых каталогов на любой момент времени. Остановился я на использовании двух: SVN и GIT.

Обе системы имеют своих клиентов под Windows (я, например, остановился на TortoiseSVN для SVN и SourceTree для GIT), обе достаточно просты в использовании. Но при этом - для себя и домашней работы я выбрал GIT как более отвечающий моим вкусовым предпочтениями. Для работы используется SVN.

Общие принципы у систем одинаковы: есть некая "рабочая копия", в которой разработчик творит чего хочет. Есть "репозиторий", в котором хранится вся история изменений. После внесения изменений в рабочую копию разработчик фиксирует изменения в репозитории. Для восстановления - выполняется обновление. Каждое изменение (т.н. "коммит") имеет комментарий разработчика. В некоторых случаях комментарий может быть пустым.

Я бы не хотел рассказывать, как работать с этими системами - в принципе, там ничего сложного нет; информации на YouTube или в Google / Yandex / Rambler etc полно. Я хотел бы рассказать об общей организации работы с этими системами.

Итак, для дома выбран GIT. Есть рабочая копия, есть репозиторий. Фактически они совмещены в одну папку. Выполняется разработка, тестирование и отладка программы. После того, как все доведено до ума, выполняется коммит в репозиторий. Учитывая, что все это дополнительно синхронизируется с облачными файлохранилищами, потерять информацию становится практически невозможно (ну или для этого надо сильно постараться). Поскольку разработчик один - я,- то все отслеживается очень быстро и просто.

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

Люди работают разные, а решение должно быть достаточно универсальным для всех и несложным для применения. Поэтому я остановился на SVN с его чуть ли не единственным клиентом для Windows - TortoiseSVN.

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

Разработчики терроризируют свои локальные копии, добиваясь приемлемой работы кода. Как только кусок работы выполнен, разработчик выполняет фиксацию своих изменений в репозиторий и сообщает об этом всем причастным. Те, в свою очередь, выполняют обновление своих локальных "рабочих" копий. И продолжают работать как ни в чем не бывало. Если тестировщики сказали, что "все хорошо", и ни один из разработчиков не задерживает выпуск новой версии, выполняется окончательная сборка модулей и фиксация уже этой сборки в репозитории. Точно так же все разработчики и тестеры выполняют обновление своих копий из репозитория.

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

Да, я знаю, как это звучит. Достаточно долгий и нудный путь. Но! В результате проектировщики получают более-менее отлаженный вариант. При необходимости можно восстановить код по состоянию хоть "год назад" - или весь, или какие-то куски. Снова все пересобрать и запустить в эксплуатацию.

Так что, если у Вас вдруг код оказывается длиннее 50-100 строк, и проект длится больше недели, советую присмотреться к системам контроля версий. Очень удобная штука, даже если использовать ее возможности на 10-15%.

P.S. Я намеренно не стал усложнять текст, вводя понятие "веток", "блокировок" и вопросов интеграции CVS со "взрослыми" IDE (типа VisualStudio) и т.п. Отчасти потому, что не ставил перед собою цели рассказывать вообще обо всех возможностях; отчасти потому, что не хотел выполнять полноценное и всестороннее сравнение CSV; отчасти потому, что сам не всем этим богатством пользуюсь. Если захотите комментировать или разгромить меня в пух и прах - добро пожаловать Только учтите, что комментарии сначала попадают на премодерацию, так что моментального появления ждать не приходится. По крайней мере, пока