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

Question

Я пробовал использовать систему управления версиями для пары проектов, но все еще толком не понимаю этого.Для этих проектов мы использовали TortoiseSVN, и у нас была только одна строка изменений.(Нет магистрали, ответвления или чего-либо подобного.) Если есть рекомендуемый способ настройки систем управления версиями, то каковы они?Каковы причины и преимущества такой настройки?Каковы основные различия между работой централизованной и распределенной системы управления версиями?

Answer 1

Я рекомендую ознакомиться со следующим от Эрика Синка:

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

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