Что такое vcs расскажите как работает vcs

Git для начинающих. Часть 1. Что такое системы контроля версий?

Система контроля версий (Version Control System, VCS) представляет собой программное обеспечение, которое позволяет отслеживать изменения в документах, при необходимости производить их откат, определять, кто и когда внес исправления и т.п. В статье рассмотрены виды VCS, принципы их работы, а также приведены примеры программных продуктов.

Что такое система контроля версий?

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

Для решения таких проблем как раз и используется система контроля версий, она позволяет комфортно работать над проектом как индивидуально, так в коллективе. VCS отслеживает изменения в файлах, предоставляет возможности для создания новых и слияние существующих ветвей проекта, производит контроль доступа пользователей к проекту, позволяет откатывать исправления и определять кто, когда и какие изменения вносил в проект. Основным понятием VCS является репозиторий (repository) – специальное хранилище файлов и папок проекта, изменения в которых отслеживаются. В распоряжении разработчика имеется так называемая “рабочая копия” (working copy) проекта, с которой он непосредственно работает. Рабочую копию необходимо периодически синхронизировать с репозиторием, эта операция предполагает отправку в него изменений, которые пользователь внес в свою рабочую копию (такая операция называется commit) и актуализацию рабочей копии, в процессе которой к пользователю загружается последняя версия из репозитория (этот процесс носит название update).

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

Системы контроля версий можно разделить на две группы: распределенные и централизованные.

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

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

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

Subversion (SVN) – система контроля версий, созданная на замену CVS. SVN была разработана в 2004 году и до сих пор используется. Несмотря на многие преимущества по сравнению с CVS у SVN все-таки есть недостатки, такие как проблемы с переименованием, невозможность удаления данных из хранилища, проблемы в операции слияния ветвей и т.д. В целом SVN был (и остается) значительным шагом вперед по сравнению с CVS.

Распределенные системы контроля версий

Распределенные системы контроля версий (Distributed Version Control System, DVCS) позволяют хранить репозиторий (его копию) у каждого разработчика, работающего с данной системой. При этом можно выделить центральный репозиторий (условно), в который будут отправляться изменения из локальных и, с ним же эти локальные репозитории будут синхронизироваться. При работе с такой системой, пользователи периодически синхронизируют свои локальные репозитории с центральным и работают непосредственно со своей локальной копией. После внесения достаточного количества изменений в локальную копию они (изменения) отправляются на сервер. При этом сервер, чаще всего, выбирается условно, т.к. в большинстве DVCS нет такого понятия как “выделенный сервер с центральным репозиторием”.

Большое преимущество такого подхода заключается в автономии разработчика при работе над проектом, гибкости общей системы и повышение надежности, благодаря тому, что каждый разработчик имеет локальную копию центрального репозитория. Две наиболее известные DVCS – это Git и Mercurial.

Начнем с Mercurial, эта система представляет собой свободную DVCS, которая построена таким образом, что в ней отсутствует понятие центрального репозитория, для работы с этой VCS используется (как правило) консольная утилита hg. Mercurial обладает всеми возможностями системы контроля версий, такими как ветвление, слияние, синхронизация с другими репозиториями. Данный проект используют и поддерживают большое количество крупных разработчиков, среди них Mozilla, OpenOffice, OpenJDK и многие другие. Сам продукт написан на языке Python и доступен на большинстве современных операционных систем (Windows, Mac OS, Linux), также существует значительное количество утилит с графическим интерфейсом для работы с Mercurial. Основным конкурентом Mercurial на рынке распределенных систем контроля версий является Git, который, на сегодняшний день, выиграл гонку за лидерство.

Git – распределенная система контроля версий, разработанная Линусом Торвальдсем для работы над ядром операционной системы Linux. Среди крупных проектов, в рамках которых используется git, можно выделить ядро Linux, Qt, Android. Git свободен и распространяется под лицензией GNU GPL 2 и, также как Mercurial, доступен практически на всех операционных системах. По своим базовым возможностям git схож с Mercurial (и другими DVCS), но благодаря ряду достоинств (высокая скорость работы, возможность интеграции с другими VCS, удобный интерфейс) и очень активному сообществу, сформировавшемуся вокруг этой системы, git вышел в лидеры рынка распределенных систем контроля версий. Необходимо отметить, что несмотря на большую популярность таких систем как git, крупные корпорации, подобные Google, используют свои VCS.

Это была вводная лекция по системам контроля версий. В дальнейшем, все изложение будет касаться только git.

Источник

Контроль версий VCS

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

Что такое контроль версий, и зачем он вам нужен?

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

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

Вообще, если, пользуясь VCS, вы всё испортите или потеряете файлы, всё можно будет легко восстановить. Вдобавок, накладные расходы за всё, что вы получаете, будут очень маленькими.

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

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

Начало работы с проектом

Первым действием, которое должен выполнить разработчик, является извлечение рабочей копии проекта или той его части, с которой предстоит работать. Это действие выполняется с помощью стандартной команды извлечения версии (checkout или clone) либо специальной команды, фактически выполняющей то же самое действие.

Разработчик задаёт версию, которая должна быть скопирована, по умолчанию обычно копируется последняя (или выбранная администратором в качестве основной) версия.

По команде извлечения устанавливается соединение с сервером и проект (или его часть — один из каталогов с подкаталогами) в виде дерева каталогов и файлов копируется на компьютер разработчика.

Обычной практикой является дублирование рабочей копии: помимо основного каталога с проектом на локальный диск (либо в отдельный, специально выбранный каталог, либо в системные подкаталоги основного дерева проекта) дополнительно записывается ещё одна его копия.Работая с проектом, разработчик изменяет только файлы основной рабочей копии.

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

Возможности VCS

1) Ветвление

Что же предоставляет нам ветвление?

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

Таким образом, независимо друг от друга, обе команды разработчиков могут работать над модулем.

Рассмотри графический пример ветвления:

на этом изображение вы можете видеть весь процесс ветвления в VCS:

Mainline – это процесс жизни проекта, основная ветка;

branch – это ветка, которая была начата на выходе линии branch c Mainline и в точке входа обратно в Mainline это merge;

merge – мы рассмотрим ниже.

2) Слияние версий (merge)

Три вида операций, выполняемых в системе управления версиями, могут приводить к необходимости объединения изменений. Это:

• Обновление рабочей копии (изменения, сделанные в основной версии, сливаются с локальными).

• Фиксация изменений (локальные изменения сливаются с изменениями, уже зафиксированными в основной версии).

• Слияние ветвей (изменения, сделанные в одной ветви разработки, сливаются с изменениями, сделанными в другой).

Ниже вы можете наблюдать пример слияния(merge) c одной ветви в другую.

3) Конфликты и их разрешение

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

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

Для решения конфликта разработчик должен решить какая с версий файла есть правильной и осуществить слияние в ручную.

Какие VCS существуют?

На данный момент я знаю только 3 самых популярных VCS:

1) Git – самый популярный и многофункциональный.

2) Subversion – не менее популярный, но немного уступает git-у.

3) Mercurial – отдал ему 3-е почетное место так как особо тесно с ним не работал, но не буду спорить если он круче git-а.

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

Источник

Система контроля версий: определение, функции, популярные решения

Система контроля версий – это обязательный инструмент в арсенале программиста любого уровня: от новичка, который только осваивается в профессии, до тимлида, чей опыт исчисляется многими годами и проектами.

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

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

Принцип работы системы контроля версий

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

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

Принцип работы системы контроля версий

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

Задачи для системы контроля версий

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

Ваш Путь в IT начинается здесь

Пусть, к примеру, разработку плагина для WordPress ведет один специалист. Заказчик вносит в ТУ требование обязательно использовать Git либо аналоги. Для него в будущем важно наличие свободного доступа к данным.

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

Задачи для системы контроля версий

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

А теперь представьте, что работу над плагином ведут несколько человек. Тогда применение СКВ даже не обсуждается. Это позволит каждому разработчику, отделившись от основной ветки, выполнять свой конкретный круг задач. После чего специалисты проверят код на ошибки и объединят вместе все части проекта.

Если система не справится с проблемой, то разработчики получат информацию об этом и вручную всё «подчистят». В конечном счете, именно программист контролирует и процесс, и окончательный результат.

Вот перечень задач, выполняемых системой контроля версий файлов:

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

Карьерная мастерская это:

Уже 50 000 человек прошли мастерскую и сделали шаг к новой профессии!

Зарегистрироваться и получить подарки

Для программистов СКВ – вещь необходимая, в их работе без сохранения бэкапов просто не обойтись. На практике всегда в какой-то момент приходится возвращаться к исходникам, и если такой возможности не будет, то проблем не избежать.

Типы систем контроля версий

Локальные СКВ

Среди первых систем подобного плана была RCS, разработанная в 1985 году и сразу ставшая популярной.

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

СКВ подобного плана решали лишь проблему хранения больших объемов данных.

Современные СКВ условно бывают двух видов, а именно, централизованные и распределенные системы контроля версий.

Чтобы работа приносила удовольствие, нужно сначала найти правильную профессию.

Мы подготовили документы, которые помогут не ошибиться с выбором и определить, какая профессия в IT подходит именно тебе.

Благодаря этим гайдам 76% наших студентов смогли найти востребованную профессию своей мечты.

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

Скачивай и используй уже сегодня:

Гайд по профессиям в IT

5 профессий с данными о навыках и средней заработной плате

100 тыс. р. за 100 дней с новой профессией

6 правил, которым необходимо следовать для облегчения обучения

Все профессии, которые есть в IT-сфере

63 профессии и необходимые для них навыки

Критические ошибки, которые могут разрушить карьеру

6 направлений деятельности и полезная литература по каждому из них

Централизованные СКВ

Далее предстояло решить проблему привлечения к работе над одним проектом нескольких специалистов (за разными компьютерами). Для этого и были разработаны централизованные системы контроля версий, такие как, к примеру, CVS, Subversion, Perforce. Они имеют собственный центральный сервер, где накапливаются все файлы проекта. Система контролирует и их сохранность, и выдачу их копий определенному ряду пользователей. Именно по такой схеме много лет и работали СКВ.

Централизованные СКВ

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

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

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

Распределенные СКВ

И вот тут незаменимыми становятся распределенные системы контроля версий. Это, к примеру, Git, Mercurial, Bazaar, Darcs. Суть их работы состоит в выгрузке клиентам не только версий файлов с последними изменениями, а всего репозитория. Репозиторий (на сленге – «репа») – это место хранения и поддержания данных. Более того, условно говоря, различают центральный и локальные репозитории.

Потому что как только клиент скачивает измененную версию файлов, к нему в компьютер копируются все данные репозитория в полном объеме.

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

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

Обзор наиболее популярной системы контроля версий GIT

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

GIT относится к распределенным системам контроля версий, и как децентрализованная СКВ имеет свои преимущества:

Версии хранятся тут в двух репозиториях, локальном (расположен на компьютере разработчика, причем именно репозиторий с полным объемом данных, а не ссылки на отдельные версии проекта) и удаленном (лежит на удаленном сервере). Получение данных с удаленного репозитория идет через гит-хостинги Github, Google Code, GitLab и прочее.

Обзор наиболее популярной системы контроля версий GIT

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

Любые изменения в документе и его новые версии сохраняются в локальном репозитории.

Набор всех сохраненных версий называют «деревом» проекта, и оно находится в репозитории.

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

Есть еще разветвленное дерево. Оно получается, если приходится дорабатывать старые версии, вносить в них изменения и потом сохранять.

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

Обзор наиболее популярной системы контроля версий GIT

Для настройки и последующей работы с системой контроля версий GIT понадобится регистрация на каком-либо из git-хостингов, к примеру на Github, Sourceforge, Google Code, GitLab, Codebase или на других.

Наибольшей популярностью из названых пользуется Github.

Почему именно он? Благодаря удобному интерфейсу, открытому коду (то есть, платить за размещение проекта на хостинге не нужно). Плюс у Github довольно широкие функциональные возможности.

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

Существует много IDE, допускающих использование GIT.

Список терминов для работы с системой контроля версий GIT

Git (Гит) – система контроля версий файлов.

GitHub (Гитхаб) – специальный сервис, на котором хранятся репозитории. Именно через него идет работа над проектами.

Репозиторий GIT – файловый каталог, то есть, место, где лежат: файлы конфигураций; файлы с журналами проведенных в репозитории операций; индекс расположения файлов; и, собственно, само хранилище контролируемых файлов.

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

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

Fork (Форк) – это копия репозитория, которая, по сути, представляет собой внешнюю ветку текущего репозитория. Такую копию может создать на Гитхабе любой пользователь, поработать с ней и через пулреквест прислать на ваш репозиторий измененный вариант.

Обновиться из апстрима – это когда своя локальная версия форка обновляется до последней сохраненной в репозитории версии (с которой и создавался форк).

Обновиться из ориджина – это когда версия локального репозитория обновляется до версии соответствующего ему удаленного репозитория.

Clone (Клонирование) – создание отдельного каталога, в который скачивается репозиторий с удаленного сервера. Далее этот каталог используется в работе в качестве репозитория.

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

Master (Мастер) – основная ветка репозитория, называемая еще главной.

Commit (Коммит) – сохранение изменений в репозиторий. Выполняется разработчиком на своем локальном компьютере.

Pull (Пул) – прием последних сохраненных изменений с удаленного репозитория.

Push (Пуш) – отправка свежих коммитов на удаленный репозиторий.

Pull Request (Пулреквест) – запрос на объединение основного репозитория с его форком. Вы, как владелец репозитория, решаете, удовлетворить этот запрос, или отклонить его.

Merge (Мёрдж) – слияние изменений, произведенных в разных ветках одного репозитория. На практике чаще происходит слияние основного репозитория с изменениями, произведенными в его ветке.

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

Ошибки при работе с GIT

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

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

Источник