Контроль версий VCS – Devcolibri – Android для начинающих

Контроль версий 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-а.

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

P.S. Кто знает еще какие то неплохие VCS то предлагаем их на рассмотрение в комментариях :)

ПОХОЖИЕ ПУБЛИКАЦИИ

    None Found

33425
16/04/2013

9 комментариев к статье "Контроль версий VCS"

Добавить комментарий

Сайт использует cookie-файлы для того, чтобы вам было удобнее им пользоваться. Для продолжения работы с сайтом, вам необходимо принять использование cookie-файлов.

Я ознакомлен(а)