Настройка работы системы контроля версий доклад
Обновлено: 02.07.2024
Сегодня в мире, где существует огромное количество сложных систем, существует необходимость видоизменения электронных документов на различных стадиях их разработки. За время своего существования электронный документ может быть подвержен большому количеству изменений. Однако часто так бывает, что для дальнейшей работы необходима не только последняя версия документа, но и различные предыдущие варианты.
Безусловно, можно хранить несколько различных вариантов необходимого документа, но данный способ неэффективен. Нам приходится тратить кучу времени и сил, необходимо особое внимание и велика вероятность ошибки. Кроме того нам приходится хранить огромное количество практически идентичных документов.
Вследствие этого были разработаны программные средства, которые упрощают данный механизм. Данные средства именуются системами контроля версий. Существует несколько такого рода систем, каждая из которых актуальна при определенных условиях их использования.
Целью данного реферата является рассмотрение различного рода систем контроля версий.
В соответствии с поставленной целью необходимо решить следующие задачи:
определить понятие системы контроля версий;
проанализировать существующие системы контроля версий;
рассмотреть основные виды данного рода систем из зарубежной и российской практики.
Задачи работы предопределили ее структуру. Реферат состоит из трех глав, введения, заключения, списка литературы и приложения.
Теоретической базой работы являются научная, российская и зарубежная периодика и ресурсы сети Интернет.
1. Понятие системы контроля версий
Система управления версиями (Version Control System или Revision Control System) представляют собой программное обеспечение для облегчения деятельности с быстро меняющейся информацией. Система контроля версий предоставляет возможность хранить несколько вариантов одного и того же документа. При необходимости можно вернуться к старым версиям, можно узнать, кем были сделаны те или иные изменения и т.д.
Такого рода системы в большинстве своем используются при разработке программного обеспечения, чтобы можно было хранить исходные коды разрабатываемых программ. Система контроля версий позволяет разработчикам хранить прошлые версии файлов из разработки и доставать их оттуда. Она хранит информацию о версии каждого файла (и полную структуру проекта) в коллекции, обычно называемой репозиторием. Но тем не менее данные системы могут использоваться и в других областях знаний, которые включают в себя огромное количество часто изменяющихся электронных документов. Например, они всё чаще применяются в САПР, обычно, в составе систем управления данными об изделии (PDM). Управление версиями используется в инструментах конфигурационного управления.
Внутри репозитория могут быть несколько параллельных линий разработки, обычно называемых ветвями. Это может быть полезно для хранения стабильной или выпущенной версии ветви, одновременно продолжая работу над рабочей версией. Другой вариант – это открыть выделенную ветвь для работы над экпериментальной возможностью.
Система контроля версий также позволяет пользователям дать ярлык снимку ветви (часто называемых как тэги) для легкого доставания. Это полезно для обозначения индивидуальных релизов или самых свежих рабочих версий, предназначенных для использования.
Использование системы контроля версий безусловно обязательно для разработчика, если проект больше нескольких сот строк или если для проекта совместно работают несколько разработчиков. Использование хорошей системы контроля версий определенно лучше, нежели использование узко-направленных специальных методов, которые используют некоторые разработчики для управления различными ревизиями своего кода.
Зачастую осуществить объединение не возможно ни с помощью системы, ни вручную. Ярким примером является ситуация когда формат файла очень сложный или неизвестен. Отдельные системы контроля версий предоставляют возможность пользователю заблокировать файл в хранилище. Данная операция не позволяет другим пользователям получить рабочую копию или препятствует изменению рабочей копии файла и обеспечивает, таким образом, исключительный доступ только тому пользователю, который работает с документом. [1]
Многие системы управления версиями предоставляют ряд других возможностей:
Позволяют создавать разные варианты одного документа, т. н. ветки, с общей историей изменений до точки ветвления и с разными — после неё.
Дают возможность узнать, кто и когда добавил или изменил конкретный набор строк в файле.
Ведут журнал изменений, в который пользователи могут записывать пояснения о том, что и почему они изменили в данной версии.
Контролируют права доступа пользователей, разрешая или запрещая чтение или изменение данных, в зависимости от того, кто запрашивает это действие.[1]
1.1. Распределённые системы управления версиями
Существуют системы управления версиями, которые, вместо традиционной клиент-серверной, используют распределённую модель. Такие системы, в общем случае, не нуждаются в централизованном хранилище: вся история изменения документов хранится на каждом компьютере. Фактически, каждый компьютер, помимо рабочей копии, хранит локальную копию всего хранилища. В некоторых системах рабочая копия сама является хранилищем.
Когда пользователь такой системы выполняет обычные действия, такие как извлечение определённой версии документа, создание новой версии и тому подобное, он работает со своей локальной копией хранилища. По мере внесения изменений, копии, принадлежащие разным разработчикам, начинают различаться и возникает необходимость в их синхронизации. Такая синхронизация может осуществляться с помощью обмена патчами или так называемыми наборами изменений между пользователями.
Описанная модель аналогична созданию отдельной ветки для каждого разработчика в классической системе управления версиями (в некоторых распределённых системах перед началом работы с локальным хранилищем нужно создать новую ветвь). Пока разработчик изменяет только свою ветвь, его работа не влияет на других участников проекта и наоборот. Однако при необходимости выполнить слияние ветвей (или синхронизацию локальных хранилищ в распределённой модели) могут возникнуть конфликты.
Распределенная система контроля версий позволяет клонировать удаленный репозиторий, производя точную копию. Она также позволяет распростанять изменения из одного репозитория на другой. В нераспределенных VCS разработчику нужен репозиторий для того, чтобы зафиксировать изменения в нем. Это делает разработчика без доступа к репозиторию человеком второго сорта. С распределенной VCS каждый разработчик может склонировать главный репозиторий, поработать над ним и потом распространить свои изменения на главный репозиторий.
2. Виды систем контроля версий
Система контроля версий может быть любой формы и размеров, но есть основные положения об их архитектуре. Некоторые системы поддерживают Атомарные Фиксации, которые значат, что состояние всего репозитория меняется полностью. Без Атомарных Фиксаций, каждый файл или часть меняется отдельно и поэтому состояние всего репозитория в любой точке не может быть зафиксировано.
Большинство обычных VCS (Version Control System ) систем позволяют объединять изменения между ветвями. Это значит, что изменения, зафиксированные в одной ветви, будут зафиксированы в главной линии или в другой ветви с помощью одной автоматической или, по крайней мере, полуавтоматической операцией.
2.1. CVS
Традиционно, де-факто системой контроля версий стала CVS (Система Параллельных Версий), но потом появилось много других, которые помогают лучше. Из всех этих возможностей CVS поддерживает только объединение изменений.
Это зрелая и относительно надежная система контроля версий. Много проектов с открытыми исходными кодами, включая KDE, GNOME и Mozilla используют CVS. Большинство центров открытых исходных кодов, такие как SourceForge, предлагают CVS как сервис, поэтому ее используют во многих других проектах.
Система CVS имеет архитектуру клиент-сервер. Обычно сервер и клиент соединяются через локальную сеть или через Интернет, но могут работать и на одной машине, если необходимо вести историю версий локального проекта. Серверное ПО обычно работает под управлением Unix, тогда как CVS клиенты доступны во всех популярных операционных системах. (4)
Сервер хранит в репозитории текущую версию (версии) проекта и историю изменений, а клиент соединяется с ним, чтобы получить нужную ему версию или записать новую. Получив с сервера нужную версию, клиент создаёт локальную копию проекта (или его части) — так называемую рабочую копию. После того как в файлы, находящиеся в рабочей копии, внесены необходимые изменения, они пересылаются на сервер.(4)
CVS также может содержать различные ветки проекта. Например, стабильная версия проекта может составлять одну ветвь, в которую вносятся только исправления ошибок, тогда как активная разработка может вестись в параллельной ветке, которая включает значительные улучшения или изменения с момента выхода стабильной версии. [4]
Кроме того, стоит также отметить, что данная система использует механизм дельта-компрессии, чтобы более эффективно хранить разнообразные версии одного и того же файла.
Несмотря на свою популярность, CVS имеет ограничения. Например, она не поддерживает переименование файлов и директорий. Кроме того, бинарные файлы не обрабатываются достаточно хорошо. CVS – нераспределенная система и атомарные фиксации изменений не поддерживаются. Так как уже есть лучшие альтернативы, которые содержат более широкий набор функций, вы, возможно, предпочтете начать новый проект используя что-то другое. (2)
Как плюс, CVS очень хорошо документирована в своей книге и во многих онлайн руководствах. Также существуют множество графических клиентов и дополнений.
В арсенале веб-разработчика много полезных инструментов, которые позволяют автоматизировать решение разных задач. Без них время работы сильно увеличивается. А продуктивность падает, потому что приходится вручную делать то, что можно решить с помощью десктопных программ или браузерных расширений.
В статье поговорим о системе контроля версий. Разберёмся, зачем она нужна, как пользоваться инструментом и расскажем о популярных ошибках, которые допускают новички и опытные программисты.
Что такое система контроля версий
Система контроля версий — программное обеспечение, которое обеспечивает командную работу в рамках одного или нескольких проектов. Команда разработчиков взаимодействует с консольным или браузерным инструментом для выгрузки кода на сервер, скачивания его на рабочий компьютер и изменения структуры.
Новичкам обычно сложно вникнуть в технические подробности работы системы контроля версий, поэтому мы постараемся объяснить суть простым языком. Не старайтесь сразу погружаться в термины, пользы от этого будет мало.
Представьте, что играете в компьютерную игру. По мере прохождения миссий происходит сохранение контрольных точек. Даже если выключить компьютер и зайти в приложение через несколько дней или месяцев, прогресс не потеряется. В любой момент можно выбрать контрольную точку и пройти миссию заново.
Самой популярной системой контроля версий является Git, поэтому мы не будем подробно останавливаться на альтернативных решениях и расскажем об этом инструменте.
Собрали основные понятия, которые будут полезны всем, кто захочет освоить работу в Git:
- Репозиторий. Каталог, в котором хранится файловая система проекта. Для каждого проекта создаётся отдельный репозиторий. Существуют локальные и удалённые репозитории. В первом осуществляется работа над проектом на компьютере, а второй выступает в роли хранилища.
- Ветка. Дочерняя версия основного репозитория. Она входит в его состав, но не влияет на работу. После того, как разработчики закончат работу над новой функцией или исправят все баги, можно совместить дочерний и родительский репозитории.
- Коммит. Операция позволяет зафиксировать текущее состояние проекта. После выполнения команды через консоль или использования браузерной версии Git, новая версия добавляется в репозиторий.
- Форк. Копия репозитория, которую можно использовать для изменения исходного кода без отправки изменений в основной репозиторий. Форки часто применяют для open-source проектов, когда любой разработчик может собрать свой проект на основе готового ядра.
- Пул и пуш. Первая операция позволяет выкачивать содержимое репозитория на компьютер, а вторая отправляет измененные файлы на сервер.
- Мастер. Основная ветка репозитория, в которой хранится ядро проекта. В неё добавляют изменения только после тщательного тестирования.
- Кодревью. Процесс проверки кода на соответствие техническому заданию или требованиям внутри команды. Когда один разработчик хочет добавить свой код в ядро, остальные члены команды проверяют его и если проблем нет, происходит обновление главной ветки.
Система контроля версий — полезный инструмент, который нужен не только программистам, работающим в команде. Он пригодится и самостоятельным разработчикам для удобного хранения данных проекта. Если что-то пойдёт не так, в любой момент можно вернуться к контрольной точке и начать заново.
Зачем она нужна
Мы уже частично ответили на этот вопрос, но чтобы новички лучше поняли принцип работы, остановимся на нём ещё раз. Если представить работу над проектом в виде прохождения игры, то контрольные точки — промежуточные версии проекта.
Допустим, программист в одиночку работает над плагином для Wordpress. Заказчик добавил в техническое задание обязательное условие — использование Git или аналогов. У него большие планы по разработке продукта, поэтому он хочет, чтобы данные находились в свободном доступе.
Программист создаёт репозиторий и начинает работать над плагином. В основной ветке у него хранится первая рабочая версия продукта. После каждого изменения разработчик добавляет новый коммит, а для внедрения масштабных изменений создаёт параллельные ветки.
Если над сайтом, плагином или сервисом работает команда разработчиков, без системы контроля версий не обойтись. Каждый из них отделится от master-ветки и будет работать над своими задачами. После завершения работы, коллеги проведут кодревью и проект можно собрать воедино.
Если Git не решит проблему самостоятельно, программисты увидят её и смогут устранить вручную. Окончательное решение всегда остаётся за разработчиком. Он контролирует процесс и решает, как будет происходить дальнейшая работа.
Какие задачи решает система контроля версий:
Git или другая система контроля версий также важна в работе программиста, как и сохранение бэкапов. В любой момент могут понадобиться исходники. И если их не будет, появятся дополнительные проблемы.
Как пользоваться системой контроля версий
Уже давно появился стереотип, что программисты очень любят работать с консолью. Новички представляют, что опытные разработчики вводят 20 команд в минуту и не используют веб-версии с user-friendly интерфейсами.
Git в стандартном варианте устанавливается на компьютер и представляет собой командную строку с минималистичным интерфейсом. Разработчики обычно разделяются на два лагеря: одни пользуются консольной версией, а вторые предпочитают вариант с графической оболочкой.
Если не хотите осваивать консоль и тратите много времени на ввод простых команд, лучше выбрать GitHub. Это крупнейший веб-сервис, на котором размещены тысячи проектов для совместной разработки. Платформа основана на системе контроля версий Git и обеспечивает удобную командную работу.
Любой пользователь может зарегистрироваться на сайте GitHub, чтобы создавать репозитории для своих проектов. Платформа отлично подходит для новичков и даёт полезный опыт. В системе много проектов с открытым исходным кодом, которые можно дорабатывать по своему усмотрению.
По данным GitHub в системе 56 млн разработчиков, больше 100 млн репозиториев и 3 млн организаций. Клиенты, которые обращаются к программистам за разработкой сайта, сервиса или приложения часто добавляют в список требований использование GitHub.
Git и GitHub не получится освоить за несколько часов, если раньше не было опыта работы с системами контроля версий. Новичкам не надо пытаться сразу выучить все термины. Лучше разобраться с основными понятиями, изучить несколько полезных статей и протестировать Git самостоятельно.
Популярные ошибки при работе с Git
Собрали распространённые ошибки, которые мешают начинающим разработчикам полностью использовать возможности системы контроля версий и создают дополнительные проблемы. Некоторые ошибки актуальны и для опытных программистов:
- Отказ от использования Git. Многие новички отказываются от системы контроля версий, когда запускают консоль и не понимают, как с ней работать. Можно заменить десктопную версию на GitHub и вообще не взаимодействовать с консолью.
- Поверхностное изучение документации. В официальной справке много полезной информации, которая экономит время при работе с репозиториями. Её надо обязательно прочитать и запомнить важные особенности.
- Игнорирование правил работы с Git. Идти против системы нельзя, потому что проект окажется под угрозой. Например, не стоит добавлять непроверенные изменения в основную ветку.
- Неправильное использование команд. При работе с консольной версией нельзя запускать команду, если до конца не уверены, какую операцию она выполняет.
- Ошибочные комментарии к коммитам. После нескольких часов активной работы с кодом лучше не отправлять файлы на сервер, а отложить задачу на потом. Разработчики часто оставляют неправильные комментарии к версиям проекта, а коллеги используют их наработки, чтобы продолжить работу.
- Добавление лишних файлов. Если залили файлы, которые не относятся к проекту, их можно удалить или исключить из структуры.
Система контроля версий — must have инструмент для разработчиков с разным опытом. Новичкам лучше сразу освоить его, чтобы использовать для своих проектов и получить дополнительное преимущество перед конкурентами, которые не знают Git или аналоги.
Системы контроля версий (их ещё называют системами управления версиями) – один из инструментов, который использует в своей работе любой программист от первокурсника до опытного тим-лида с сотнями успешных проектов.
— Ссылки на примеры кода в репозиториях помещают в своё портфолио.
— Большие проекты с открытым программным кодом получают тысячи улучшений, благодаря размещению на специализированном хостинге.
— От 30 до 70% кода, использованного в программном продукте, профессиональные разработчики могут скопировать с проектов, представленных в открытых репозиториях.
Незаменимы системы контроля версий в командной разработке, где синхронизация процесса играет важную роль.
С необходимостью отката программы к предыдущей версии рано или поздно сталкивается любой программист.
В точке А программа отлично работает, а попытка расширить функционал, ввести дополнительные переменные, классы и пр. приводит в появлению ошибки.
Реализовать такую процедуру помогает использование системы контроля версий (СКВ), которое позволяет четко отследить историю разработки, найти стабильную версию и продолжить работу.
В системе контроля версий может содержаться, как программный код, так и любая другая информация (включая текстовые файлы, изображения и т.п.)
Как осуществляется контроль версий
Существует несколько моделей хранения данных:
Примитивная модель хранения версий
В примитивной модели актуальные копии проекта перезаписываются в отдельную директорию через определённый промежуток времени.
Достоинства:
— возможность восстановления данных одной из записанных версий.
Недостатки:
— сложности с поиском необходимой версии в обширной и плохо структурированной базе данных;
— возможность потери данных вследствие возникновения физических поломок оборудования;
— отсутствие возможности совместной разработки.
Локальные системы контроля версий
Локальные СКВ обычно хранят на компьютере список изменений, внесенных в файлы. Основываясь на этих данных, система контроля версий воссоздает нужную версию файла (актуальную на определенный момент времени).
Локальные системы контроля версий
Достоинства:
— возможность восстановления данных из определенной версии (точно определяется по времени записи);
— высокая скорость выполнения восстановления (база данных четко структурирована, поэтому сложностей при поиске не возникает, сетевая задержка отсутствует, поскольку данные хранятся непосредственно на рабочем компьютере).
Недостатки:
— возможность потери данных вследствие возникновения физических поломок оборудования;
— отсутствие возможности совместной разработки.
Централизованные системы контроля версий
Централизованные системы контроля версий предполагают сохранение версий проектов на общий сервер, с которого потом получают нужные версии клиенты.
Централизованные системы контроля версий
Достоинства:
— возможность восстановления данных из определенной версии (точно определяется по времени записи);
— возможность ведения командной разработки проекта;
Недостатки:
— отсутствие доступа к данным при сбое работы сервера;
— довольно низкая скорость работы (из-за возникновения сетевых задержек).
Децентрализованные системы контроля версий
В децентрализованных системах контроля версий при каждом копировании удалённого репозитория (расположенного на сервере) происходит полное копирование данных в локальный репозиторий (установленный на рабочем компьютере). Каждая копия содержит все данные, хранящиеся в удалённом репозитории. В случае, возникновения технической неисправности на стороне сервера, удаленный репозиторий можно перезаписать с любой сохраненной копии.
Децентрализованные системы контроля версий
Достоинства:
— возможность восстановления данных из определенной версии (точно определяется по времени записи);
— возможность ведения командной разработки проекта;
— при сбое работы сервера система сохраняет данные в локальном репозитории, что позволяет эффективно вести процесс разработки, а после восстановления работы сервера, передать все изменения в удаленный репозиторий;
— при физической поломке сервера данные можно легко перенести в новый удалённый репозиторий с любого локального репозитория;
— высокая скорость работы (в ходе работы данные записываются и получаются из локального репозитория, поэтому сетевые задержки отсутствуют).
Современные системы контроля версий
Существует много систем контроля версий (Git, Darcs, Mercurial, Bazaar, Monotone и т.д), сходных по принципу работы и конечным задачам. Отличаются они друг от друга архитектурой, использованными решениями и удобством работы.
Самая популярная на сегодняшний день система контроля версий – Git.
Git
Git
Умение работать с git’ом — обязательный навык для программиста любого профиля. Можно долго обсуждать преимущества и недостатки разных систем контроля версий, но большинство компаний используют git, поэтому уметь работать с git’ом нужно всем.
Git – распределённая система контроля версий. Что даёт ей все преимущества децентрализованной СКВ:
— высокую скорость проведения всех операций (за счет отсутствия сетевой задержки);
— идеальные условия для командной разработки;
— страховку от потери информации при возникновении проблем с центральным сервером.
Для контроля версий в git используются 2 репозитория: локальный и удаленный. Локальный репозиторий (полноценный репозиторий, а не ссылки или копии отдельных ветвей) находится на компьютере разработчика, а удаленный на удалённом сервере. Доступ к удаленному репозиторию обеспечивается благодаря гит-хостингу Github, Google Code, GitLab и т.д.
Как работает git
Взаимодействие с удаленным репозиторием происходит при наличии интернета и, по сути, представляет собой синхронизацию двух репозиториев.
Команда push копирует новые данные, содержащиеся в локальном репозитории, в удалённый репозиторий, а команда pull передает данные из удаленного репозитория в локальный.
Каждая версия документа, внесенные обновления и т.д записываются в локальный репозиторий.
Дерево проекта
Дерево файлов в системе контроля версий
Дерево может быть прямым (в этом случае каждое последующее сохранение файлов производилось после предыдущего без возвращения к более ранним версиям) и разветвленным.
Git-хостинг
Для комфортной работы с git нужно зарегистрироваться на любом git-хостинге. Их довольно много: Github, Sourceforge, Google Code, GitLab, Codebase и т.д.
Самый популярный на данный момент git-хостинг – это Github.
Популярность его обоснована простым интуитивно понятным интерфейсом, поддержкой проектов с открытым кодом (возможностью бесплатно размещать такие проекты на хостинге) и обширным функционалом.
Git-клиент
Для удобства работы с системой контроля версий git разработан целый ряд графических git-клиентов. Это программы, позволяющие эффективно работать с системой контроля версий, используя графический интерфейс.
Многие IDE предполагают возможность работы с git.
Работа с Git через IDE
Работа с системами контроля версий — важный навык, нужный каждому программисту.
В этом уроке мы с вами познакомимся с мощнейшим инструментом, которым должен владеть каждый уважающий себя разработчик. Встречайте короля систем контроля версий – Git. Расскажем, чем же он так хорош, где применяется, а главное - как его установить и настроить.
Урок 2. Git. Внутренняя реализация. Создание изменений: индексация и коммиты. Команды: init, status, add, commit.
1. Что такое системы контроля версий
2. Зачем нужен контроль версий?
3. Разновидности архитектур VCS
3.1. Локальная система контроля версий
3.2. Централизованная система контроля версий
3.3. Распределенная система контроля версий
4. Как появился Git?
5. Почему именно Git?
1. Установка и настройка Git
1.1. Установка для пользователей Windows
1.2. Установка Git в Linux
2. Видео "Установка, настройка Git, создание репозитория"
3. Домашнее задание
Система управления версиями (от англ. Version Control System, VCS) — программное обеспечение для облегчения работы с изменяющейся информацией. Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, и многое другое.
Такая система фиксирует изменения, что позволяет вам в случае чего откатиться к любой предыдущей версии файла. Кроме отката изменений, система контроля версий позволяет сравнивать версии одного и того же файла, чтобы найти в нем изменения, видеть, кто эти изменения внес, когда это было сделано и что могло вызвать проблему.
Такой процесс займет очень много сил и времени, а пользователей оставит недовольными. Вам бы очень помогла система контроля версий. Вы бы загрузили в нее файлы с кодом до внесения изменений, а после обнаружения ошибки, откатились бы к ним за считанные секунды. Функция отката изменений позволила бы вам оперативно загрузить в магазины старую версию приложения, которая работает без ошибок.
Понятно, что проект для команды - это бесценные знания, накопленные за все время его существования, и никому бы не хотелось, чтобы с ними что-то случилось. Система контроля версий защищает эти накопления от человеческого фактора, непредвиденных последствий и разных форс-мажоров.
Обычно, работая в команде, каждый разработчик трудится над какой-то своей частью проекта: создает новые функции, оптимизирует уже существующие, исправляет ошибки в уже написанном коде. Сам проект обычно организован в виде дерева файлов. Контроль версий помогает сотрудникам одновременно работать над проектом, отслеживать, кто какие изменения внес, и избегать при этом различных конфликтов (например, когда два человека изменят один и тот же файл по-разному).
Помимо этого, как уже было сказано выше, любое изменение кода может привести к непредвиденным последствиям и сломать весь проект вообще. Система контроля версий защищает и от этого.
Существует три основных разновидности архитектур систем контроля версий: локальная, централизованная и распределенная. Рассмотрим их все.
3.1. Локальная система контроля версий
Вы спросите: почему нельзя просто сохранять файл под разными именами, а затем открывать нужный? Да, так делать можно, но это вызовет массу проблем. Вы можете забыть, какой файл содержит итоговую версию, можете запутаться в миллионе одинаковых файлов, отличающихся парой строк кода. Вы не сможете быстро сравнить две версии, чтобы посмотреть, какие изменения были внесены.
Для решения этих проблем была придумана локальная система контроля версий. Схематически она представляет из себя следующее:
Из рисунка видно, что есть несколько версий одного и того же файла. А сам файл сейчас находится в состоянии третьей версии.
Одной из самых популярных локальных систем контроля версий на сегодняшний день (не считая Git) остается система RCS. Она работает по принципу сохранения изменений в ваших файлах. То есть она хранит не целую новую версию, а только указания к изменению первоначального файла. Например, "добавить к предыдущей версии строку import math ". Таким образом, последовательно изменяя файл, система воссоздает любую из его версий.
Подытожим:
Локальные VCS хранятся у вас на компьютере. Пример локальной VCS - RCS - одна из первых систем контроля версий, разработанная в 1985 году.
Составим список преимуществ и недостатков локальных VCS.
Преимущества:
1. Позволяет хранить историю изменения файлов локально, без интернета.
2. Вы независимы от сторонних серверов.
Недостатки:
1. Вы можете потерять все файлы, если с вашем компьютером что-то случится.
2. Вы не можете работать в команде, поскольку репозиторий доступен только вам.
3.2. Централизованная система контроля версий
Как было сказано выше, одна из проблем, с которой вы столкнетесь, работая в команде разработчиков - это то, что вам нужно делиться файлами (и их версиями) с другими разработчиками.
Например, чтобы старший разработчик проверил ваш код на ошибки, перед тем, как дать вам разрешение на внесение изменений в рабочий файл. Для решения этой проблемы была придумана централизованная система контроля версий. Схематически она устроена так:
Из рисунка видно, что есть один сервер с сохраненными версиями всех файлов, а разработчики обращаются к нему за файлами.
Такими системами были очень популярные в свое время CVS, Subversion и Perforce. Долгое время такой тип системы контроля версий считался стандартом. Такая система довольно удобна с точки зрения руководства компании. Она позволяет им следить, кто и чем занимается в текущий момент, позволяет настроить: кому какие файлы можно редактировать, а кому - нельзя.
Тем не менее, централизованная система контроля версий имеет множество недостатков. Если сервер отключится на несколько часов, то работа целой компании будет парализована: никто не сможет сохранять версии файлов с кодом.
Если будет поврежден жесткий диск сервера, на котором хранятся данные, то восстановить их не удастся (если только не были сделаны копии), и вся работа будет потеряна.
В этом плане такая система мало чем отличается от локальной: если вы храните все данные проекта только на одной машине, вы рискуете потерять все из-за непредвиденного сбоя в работе этой машины.
Кроме того, поскольку вы не храните никаких данных локально, вам нужен бесперебойный высокоскоростной интернет на протяжении целого дня, чтобы скачивать и загружать данные с сервера. Это, конечно, не проблема, но однозначно минус.
Подытожим:
Централизованная VCS хранит все данные на сервере, а сотрудники получают к ним доступ.
Примерами удаленных систем контроля версий являются CVS, Subversion и Perforce.
Преимущества централизованных VCS:
1. Вы можете работать в команде с другими разработчиками.
2. Ваше начальство видит, чем вы занимаетесь.
3. У администратора есть четкий контроль, кто и что может делать. Администрировать центральную VCS намного проще, чем локальные на каждой машине.
Недостатки централизованных VCS:
1. Все данные хранятся только на одном сервере. Если он выключится, то работу всей компании парализует.
2. Если с сервером что-то случится, а копий данных нет, то весь проект может быть потерян.
3. Для работы необходим хороший интернет на протяжении целого дня.
3.3. Распределенная система контроля версий
Распределенная система контроля версий решает все описанные выше проблемы. К этой группе систем относится Git, Mercurial, Bazaar и некоторые другие. На схеме распределенные системы контроля версий выглядят так:
Особенность этой архитектуры в том, что клиенты не хранят у себя отдельные файлы, они хранят полную копию всех версий проекта. Поэтому, если что-то случится с сервером, работа не остановится, а продолжится, как ни в чем не бывало. Работники будут сохранять версии у себя на компьютере, а как только сервер восстановится, они загрузят все эти версии на него.
Кроме того, почему сервер обязательно должен быть один? Правильный ответ: серверов может быть сколько угодно! Это открывает безграничные возможности для коллаборации разработчиков. Ведь это значит, что если вы делаете какое-нибудь открытое программное обеспечение и используете систему контроля версий, любой человек сможет скопировать данные с вашего сервера на свой, улучшить это ПО, не боясь ошибок (ведь можно откатиться к предыдущей версии), а затем (с вашего согласия) записать улучшенную версию на ваш сервер. И так с миллионами людей по всему миру.
Подытожим
Распределенные VCS - лидер по популярности на сегодняшний день. Примеры таких систем - это Git, Mercurial и Bazaar.
Преимущества распределенных VCS:
1. Работа компании теперь не зависит от работы сервера. Если сервер отключится, то каждый сотрудник продолжит работу с локальной копией репозитория, а после загрузит ее на сервер.
2. Можно работать с несколькими удаленными репозиториями, делиться кодом с другими людьми и коллаборировать целыми компаниями.
ОБЩИЙ ИТОГ
Для закрепления повторим все, что было сказано ранее. Итак, VCS открывает перед вами следующие возможности:
1. Сохранять все изменения в файлах в хронологическом порядке, при этом не путаясь в именах миллионов копий одного и того же файла.
2. Избегать неприятных ошибок в коде, вызванных непредвиденным поведением новых функций.
3. Отслеживать, над какими файлами вы работаете (и работаете ли вообще). Вам это вряд ли пригодится, а вот вашему начальству – очень.
4. Работать параллельно над одним и тем же проектом вместе с командой, не боясь конфликтов, например, одновременного изменения одного и того же файла.
5. Делиться своим кодом. А разработчики со всего мира могут улучшать его и записывать изменения на ваш сервер.
Git - это самая популярная на сегодня система контроля версий. Это развитый проект с открытым кодом, активно поддерживаемый и совершенствуемый. Как я уже говорил выше, Git устроен по принципу распределенной архитектуры, но поддерживает и локальную работу (в таком случае ваш компьютер будет единственным сервером, где хранятся все версии проекта).
Git был разработан командой Линуса Торвальдса в 2005 году, как open-source аналог уже существующим системам. Но разработка Git не была спонтанным решением. Дело в том, что с самого первого релиза в 1991 году разработка ядра Linux выполнялась по старинке: старая версия архивировалась, а новые патчи от разработчиков становились новой версией.
Но с ростом популярности рос и объем данных, поэтому в 2002 году было принято решение перевести ядро Linux на распределенную систему управления версиями BitKeeper от BitMover Inc . Однако между компаниями произошел разлад и BitMover Inc . отозвали лицензию на бесплатное использование своего ПО.
Этот инцидент и подстегнул Линуса Торвальдса с командой разработчиков создать свою открытую распределенную систему контроля версий. Ребята хотели разработать надежное решение, обладающее высокой скоростью работы и упрощающее командную разработку.
Читайте также: