Теория (и терминология), стоящая за Source Control

Question

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

Answer 1

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

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

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

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

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

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

Answer 2

Рекомендую проверить у Эрика Синка следующее:

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

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

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

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

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

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

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

Answer 5

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

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

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

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