Теория (и терминология) управления версиями

Подумайте о системе управления версиями как о гигантской кнопке "Undo" для вашего исходного кода. Каждый раз, когда вы регистрируетесь, вы добавляете точку, к которой вы можете откатиться. Даже если вы не используете branching/merging,, эта функция сама по себе может быть очень ценной.

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

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

Большое преимущество распределенного управления версиями заключается в двух аспектах:

1. При использовании распределенного управления версиями на локальном компьютере создается целое дерево исходных текстов. Вы можете фиксировать, создавать ветви и работать почти так же, как если бы Вы были в полном одиночестве, а затем, когда вы будете готовы продвигать свои изменения, вы можете продвигать их с Вашего компьютера на мастер-копию. Если вы работаете "offline" много, это может быть огромным преимуществом.

2. Вам не нужно спрашивать ничьего разрешения, чтобы стать распространителем системы управления версиями. Если человек A запускает проект, но человек B и C хотят внести изменения и поделиться этими изменениями друг с другом, это становится намного проще с распределенным управлением версиями.

Я рекомендую проверить следующее от Eric Sink:

http://www.ericsink.com/scm/source_control.html

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

Вот две статьи, которые очень полезны для понимания основ. Помимо информативности, компания Sink продает отличный продукт управления версиями под названием Vault, который является бесплатным для отдельных пользователей (я никоим образом не связан с этой компанией).

http://www.ericsink.com/scm/source_control.html

http://betterexplained.com/articles/a-visual-guide-to-version-control/

Информация о хранилище на www.vault.com.

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

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

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

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

Общим стандартом для настройки Subversion является наличие трех папок в корневом каталоге репозитория: trunk, Branch и tags. В папке магистрали хранится текущая линия разработки "main". Для многих магазинов и ситуаций это все, что они когда-либо используют... просто один рабочий репозиторий кода.

Папка тегов делает еще один шаг вперед и позволяет вам "checkpoint" ваш код в определенные моменты времени. Например, когда вы выпускаете новую сборку или иногда даже когда вы просто делаете новую сборку, вы "tag" копию в эту папку. Это просто позволяет вам точно знать, как выглядел ваш код в тот момент времени.

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

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