Система за контрол на версиите () е механизмът, по който се управлява работата по даден софтуерен проект. За да се улесни разработката на софтуер са създадени специални системи, които намаляват неудобствата при съвместна работа на много хора върху един проект.
Системите за контрол на версиите обикновено използват едно централно хранилище, в което се съхраняват файловете на проекта. Когато някой започне да работи по този проект, той създава копие на файловете от това хранилище на своята система и работи с тези копия. В процеса на работа потребителят може да изпраща към хранилището направените от него промени и да получава промените, направени по проекта от другите хора в екипа.
След обновяване на хранилището, в него се запазват старите версии на променените файлове. Така тези файлове могат да бъдат възстановени при необходимост. Системата за контрол на версиите също така следи за конфликти – различни промени на различните потребители, които ползват хранилището.
Преглед В компютърното софтуерно инженерство, контрол на версиите е всяка практика, която следи и предлага контрол върху промените в изходния код. Понякога, софтуерните разработчици използват Система за Контрол на Версиите (VCS, ) както за кода, така и за да поддържат документацията и конфигурационните файлове по даден проект. Въпреки че примерът даден тук е свързан с програмен код, практически всякакъв тип компютърни файлове могат да бъдат поставени под контрол чрез VCS. Ако например графичен дизайнер има нужда да запази всички версии, варианти или стадии на изображение, или графично оформление, то би било добра практика да използвате такава VCS. Най-простата употреба и обяснение на VCS е, че потребителят би могъл лесно да се върне към предишна работеща версия на документ, по който работи в случай, че нещо се обърка.
На най-елементарно ниво разработчиците биха могли да пазят копия на различните версии на компютърната програма и да ги именуват подходящо, давайки им например поредни номера. Този елементарен подход е бил използван за различни големи софтуерни проекти. И докато този метод би могъл да работи, той е неефективен заради необходимостта да бъдат поддържани много, почти идентични копия на програмата. Това изисква сериозна самодисциплина от страна на програмистите и често води до грешки. За решението на този проблем са били разработени, системи за автоматизиране на някои, или всички етапи от процеса за контрол над версиите. Големите, бързоразвиващи се проекти с много автори се нуждаят от система за контрол на версиите за да организират и оптимизират максимално ефективно всички етапи от процеса на софтуерна разработка. VCS са станали важна част от този процес поради следните предимства, които предлагат: Сътрудничество – група от разработчици, дори и да се намират на различни географски местоположения, могат да работят по един и същ набор от документи или файлове без да пречат един на друг. Архивиране и Възстановяване – Файловете се поставят в хранилището на проекта след редактирането им и след това можете да се върнете към всеки един момент от развитието на тези файлове. Синхронизация – Дава възможност на членовете на екипа да споделят документи и да могат да разполагат с най-актуалните им версии. Отмяна – В случай, че нещо сериозно се обърка, системата дава възможност да се върнем към последната „работеща“ версия. Следене на Промените – Всяка промяна по файловете в хранилището се асоциира с пореден номер и се запазва в история на промените. Когато файла бива променян, може да се добави и кратко обяснение за промените, тяхната необходимост и проблемите, които те решават, което обяснение се запазва заедно с поредния номер в историята на промените на VCS, а не в самия файл. Това прави лесно проследяването на развитието на документа през времето. Управление на промените – промените могат да бъдат инспектирани, обсъждани, одобрявани или отхвърляни по необходимост, като при желание състоянието на документа или файла може да се върне такова каквото е било на определен етап от развитието си. Следене на Принадлежността – VCS запазва името на редактиращия към всяка промяна направена от него. Разклоняване и Обединяване – Възможност за разклоняване на копие от кода в отделна локация и редактирането му в изолация, като при това промените му се следят отделно. По-късно е възможно сливането на кода обратно с друго разклонение. Непрекъсната Интеграция – възможността, която предлагат системите за контрол на версиите, развитието на даден софтуерен продукт да се раздели на малки части (промени), дава възможността да се провеждат операции, тестове и проверки върху всяка последователна промяна, в непрекъснат стил
Структура и Общи Функции Повечето системи за контрол на версиите включват следните концепции, въпреки че наименованията могат да варират:
Основна структура Repository (Хранилище) – базата данни съхраняваща файловете Server (Сървър) – компютърът, на който е разположена базата данни Client (Клиент) – компютърът свързващ се с хранилището Working Copy (Работно копие) – локалното копие на файловете, където се правят промените Trunk (Стъбло) – Основната локация в хранилището, от която започва развитието на проекта. Главната линия, посока за разработка. Можем да мислим за кода почти като горски път, разклоняващ се, и сливащ се обратно, или продължаващ разклонен. Branch (Разклонение) – Копие на кода от даден момент на развитие на проекта, което може да се развива независимо, или да се обедини обратно.
Основни функции Add (Добавяне) – поставяне на файл в хранилището за първи път. Т.е. започване на проследяването му чрез VCS. Revision (Ревизия) – поредната версията на файла(напр. v1, v2, v2.3 и т.н.) Head (Хед) – последната версия на проекта в дадено разклонение в хранилището. Check out (Изтегляне) – Изтеглянето на файл от хранилището. Тази функция има 2 основни задачи. На сървъра – VCS запомня, че файла е бил изтеглен за редактиране и при нужда уведомява останалите членове на екипа. На клиента – подготвя работна версия на файла за редактиране давайки му съответните разрешения. Тази функция е начин да заявите вашите намерения пред останалите, така че те могат да се съобразят и да избегнат паралелното редактиране на същия файл, което би довело до допълнителни усложнения (конфликт) при опит за качване. Някои VCS предлагат автоматичното заключване на файла, ако той е бил изтеглен, така че да бъде невъзможно паралелното му изтегляне от друг сътрудник. Check in, Commit (Качване) – Качването на файл в хранилището(ако е бил променен). Файла приема нов номер на ревизия и вече не е маркиран като изтеглен, така че членовете на екипа могат да изтеглят последната му версия. Някои VCS заключват за редактиране локалното копие на файла след качване. Коментар за Качването – кратък коментар описващ промените по файла. Добра практика е промените да се описват оптимално, така че в историята на промените да бъдат ясно упоменати и разбираеми причините и корективите, които са били предприети. Това може да бъде изключително полезно след време, когато е нужно да се разбере подобна информация, а спецификата е забравена. Changelog/History (История на промените) – Списък с всички промени направени по даден файл от началото на неговото добавяне в VCS Update/Sync (Синхронизиране) – Синхронизиране на локалните файлове с последните техни версии от хранилището Revert (Връщане) – Отхвърляне на локалните промени по файла и презареждането на последната му версия от хранилището.
Разширени Функции Branch(Разклонение) – създаване на отделно копие на файл или папка за независимо ползване (тестване, дебъгване и т.н.). Diff/Change/Delta (Разлики) – откриване на различията между два файла. Полезно за визуализирането на настъпили промени между определени ревизии. Merge(Съединяване, сливане) – Прилагане на промените от един документ към друг, който да бъде актуализиран. Например могат да се обединят елементи от едно разклонение с друго. Conflict (Конфликт) – когато чакащи промени към един файл в хранилището си противоречат (не могат да се приложат и двете промени) Resolve (Решение) – разрешаване на проблема с противоречащи си чакащи промени и качването на коректен вариант Locking (Заключване) – установяване на контрол върху файл, така че никой не може да го редактира докато не бъде отключен. Някои VCS използват това за избягване на конфликти Breaking the lock (Силово Отключване) – силово отключване на файла, така че той да може да бъде редактиран. Налага се когато някой заключи файла и се отправи на почивка например. Tag/Label (Тагване) – разклоняване, обикновено съдържащо стабилна версия на проекта готова за пускане, при което се задава име или пореден номер на версията. Прави по-удобно проследяването на развитието на проекта и възможността за бързо връщане към стабилно негово състояние.
Модели за контрол на версиите Всички системи за контрол на версиите трябва да решат един фундаментален проблем: как системата ще позволи на потребителите да споделят данни без да си пречат един на друг, защото е лесно промени направени от един потребител да бъдат пренебрегнати от друг по невнимание. Ето един пример. Двама потребители – Георги и Петър – свалят един и същ файл за редактиране. Всеки прави уникални промени в своето работно копие. Георги завършва пръв и качва готовия файл. Петър завършва с работата по-късно и също качва неговата версия на файла. Това което може да се случи е, че в хранилището ще съществуват и двата файла, но промените направени от Георги няма да имат никакъв ефект.
Lock – Modify – Unlock Някои системи за контрол на версиите използват lock-modify-unlock модел за разрешаването на гореописания проблем. При този модел системата позволява само на един потребител да редактира даден файл. Когато Георги заключи файла за редактиране, никой освен него не може да направи същото. Потребителят редактира файла, след което го качва (commit) обратно хранилището и го отключва. Оттук нататък Петър може да започне работа по файла спазвайки същия ред.
Проблемът с този модел е, че той може сериозно за възпрепятства работата по даден проект и често се превръща в бариера за потребителите. Заключването на файла може да доведе до административни проблеми. Понякога Георги, който е заключил файла, може да забрави за това. Междувременно, Петър трябва да направи промени, но ръцете му са вързани. Георги отива в отпуск или се разболява, и тогава се налага ангажирането на администратор, който да отключи файла за да бъде възможна работата по него. Всичко това приключва с ненужно забавяна и загуба на време. Заключването може да причини излишна сериализация. Ако Георги редактира началото на файла, а на Петър се налага да направи промени в края му, то тогава двете промени не влизат в конфликт и работата може да бъде свършена едновременно, и с подходящо сливане няма да има проблеми. В този случай не е нужно изчакването на ред. Заключването на файл може да създаде фалшиво усещане за сигурност. Ако например Георги заключи и редактира файл А, в същото време Петър редактира файл Б. Но файл А и Б са зависими един от друг и промените направени по тях са семантично несъвместими. Тогава двата файла спират да работят по между си. Заключването не е в състояние да предотврати подобна ситуация, но вместо това създава погрешно усещане за сигурност у двамата потребители, което води до липса на комуникация относно съвместимостта на файловете.
Copy – Modify – Merge Алтернатива на гореописания модел е Copy-Modify-Merge, където всеки потребител разполага с локално работно копие на файла. Потребителите могат да работят паралелно по техните работни копия и накрая тези файлове се сливат (merge) в една обща финална версия. Системата за контрол на версиите често предлага помощ и автоматизация при процеса на сливане, но понякога, за да протече този процес коректно, е необходима и човешка намеса.