Подходы к версионности

Многие люди, незнакомые с современными системами контроля версий, имея в виду обозначенную проблему, стараются «изобрести велосипед» для решения повседневных задач, связанных с работой над изменяющейся информацией. Чтобы понять, как системы контроля версий позволяют облегчить этот процесс, рассмотрим вкратце эволюцию подходов к обеспечению версионности.

Версионность «вручную»

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

Эти подходы чрезвычайно просты, именно поэтому они так популярны среди обычных пользователей, но у них есть ряд серьезных недостатков:

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

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

Традиционные модели

Локальные системы контроля версий

Разработчики программного обеспечения были первыми, кто погрузился в решение проблем версионности. В основе первых систем управления версиями лежали алгоритмы сравнения файлов и простые локальные базы данных объектов. Изменения записывались в базу данных «снимками», которые фиксировали все совершенные изменения.

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

Централизованные системы контроля версий

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

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

Однако этот подход также не лишен недостатков. Наиболее очевидный — централизованый сервер является уязвимым местом всей системы. Если сервер выключается на час, то в течение часа разработчики не могут взаимодействовать, и никто не может сохранить новые версии. Если же повреждается диск с центральной базой данных и нет резервной копии, Вы теряете абсолютно всю историю проекта, за исключением нескольких рабочих копий, оставшихся у клиентов. Локальные системы управления версиями подвержены той же проблеме: если вся история проекта хранится в одном месте, Вы рискуете потерять всё.

Кроме того, централизованные системы управления версиями вынуждают Вас для всех операций использовать сетевые ресурсы, которые во всех отношениях «дороже» локальных.

Распределенная модель

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

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

По своей организации центральный репозиторий ничем не отличается от тех репозиториев, с которыми работают все клиенты. Соответственно, каждый новый клиент, начиная работу с репозиторием, получает не просто рабочую копию, а настоящий «клон» репозитория — актуальную рабочую копию и полную историю. При этом всё, что можно делать с основным репозиторием, можно делать и с локальным.

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