Што такое «сістэма кантролю версій» і чаму гэта важна? Сістэма кантролю версій — гэта сістэма, якая запісвае змены ў файл або набор файлаў на працягу часу і якая дазваляе вярнуцца пазней да пэўнай версіі. Для кантролю версій файлаў у гэтай кнізе ў якасці прыкладу будзе выкарыстоўвацца зыходны код праграмнага забеспячэння, хоць на самай справе вы можаце выкарыстоўваць кантроль версій амаль што для любых тыпаў файлаў.
Калі вы графічны або web-дызайнер і хочаце захаваць кожную версію малюнка або макета (хутчэй за ўсё, захочаце), сістэма кантролю версій (далей СКВ) — як раз тое, што трэба. Яна дазваляе вярнуць файлы да стану, у якім яны былі да зменаў, вярнуць праект да зыходнага стану, убачыць змены, убачыць хто апошні нешта мяняў і выклікаў праблему, хто паставіў задачу і калі, а так сама многае іншае. Выкарыстанне СКВ таксама значыць, што вы спакойна можаце ўсё выправіць калі страцілі файлы ці нешта зламалі. У дадатак да ўсяго, вы атрымаеце ўсё гэта без якіх-небудзь дадатковых намаганняў.
Многія людзі ў якасці метаду кантролю версій ўжываюць капіраванне файлаў у асобны каталог (магчыма нават, каталог з адзнакай па часе, калі яны дастаткова кемлівыя). Дадзены падыход вельмі распаўсюджаны з-за яго прастаты, аднак ён неверагодна моцна схільны з’яўленню памылак. Можна лёгка забыцца у якім каталогу вы знаходзіцеся і выпадкова змяніць не той файл або скапіяваць не тыя файлы, якія вы хацелі.
Для таго, каб вырашыць гэтую праблему, праграмісты даўным-даўно распрацавалі лакальныя СКВ з простай базай дадзеных, якая захоўвае запісы аб усіх зменах у файлах, ажыццяўляючы тым самым кантроль рэвізій.
Адной з папулярных СКВ была сістэма RCS, якая і сёння распаўсюджваецца з многімі кампутарамі. RCS захоўвае на дыску наборы патчаў (адрозненняў паміж файламі) у спэцыяльным фармаце, ужываючы якія яна можа аднаўляць стан кожнага файла ў зададзены момант часу.
Наступная сур’ёзная праблема, з якой сутыкаюцца людзі, — гэта неабходнасць ўзаемадзейнічаць з іншымі распрацоўшчыкамі. Для таго, каб разабрацца з ёй, былі распрацаваны цэнтралізаваныя сістэмы кантролю версій (ЦСКВ). Такія сістэмы, як CVS, Subversion і Perforce, выкарыстоўваюць адзіны сервер, які змяшчае ўсе версіі файлаў, і некаторую колькасць кліентаў, якія атрымліваюць файлы з гэтага цэнтралізаванага сховішча. Прымяненне ЦСКВ з’яўлялася стандартам на працягу многіх гадоў.
Такі падыход мае мноства пераваг, асабліва перад лакальнымі СКВ. Напрыклад, усе распрацоўшчыкі праекта ў пэўнай ступені ведаюць, чым займаецца кожны з іх. Адміністратары маюць поўны кантроль над тым, хто і што можа рабіць, і значна прасцей адміністраваць ЦСКВ, чым апераваць лакальнымі базамі дадзеных на кожным кліенце.
Нягледзячы на гэта, дадзены падыход таксама мае сур’ёзныя мінусы. Самы відавочны мінус — гэта адзіная кропка адмовы, прадстаўленая цэнтралізаваным серверам. Калі гэты сервер выйдзе са строю на гадзіну, то на працягу гэтага часу ніхто не зможа выкарыстоўваць кантроль версій для захавання змяненняў, над якімі працуе, а таксама ніхто не зможа абменьвацца гэтымі зменамі з іншымі распрацоўшчыкамі. Калі жорсткі дыск, на якім захоўваецца цэнтральная БД, пашкоджаны, а своечасовыя бэкапы адсутнічаюць, вы страціце ўсё — усю гісторыю праекта, не лічачы адзінкавых здымкаў рэпазітара, якія захаваліся на лакальных машынах распрацоўшчыкаў. Лакальныя СКВ пакутуюць ад той жа самай праблемы: калі ўся гісторыя праекта захоўваецца ў адным месцы, вы рызыкуеце страціць усё.
Тут у гульню ўступаюць размеркаваныя сістэмы кантролю версій (РСКВ). У РСКВ (такіх як Git, Mercurial, Bazaar або Darcs) кліенты не проста запампоўваюць здымак ўсіх файлаў (стан файлаў на пэўны момант часу) — яны цалкам капіююць рэпазітар. У гэтым выпадку, калі адзін з сервераў, праз які распрацоўшчыкі абменьваліся дадзенымі, памрэ, любы кліенцкі рэпазітар можа быць скапіяваны на іншы сервер каб не спынять працу. Кожная копія рэпазітара з’яўляецца поўным бэкапам ўсіх дадзеных.
Больш за тое, многія РСКВ могуць адначасова ўзаемадзейнічаць з некалькімі выдаленымі рэпазітарамі, дзякуючы гэтаму вы можаце працаваць з рознымі групамі людзей, ужываючы розныя падыходы адначасова ў рамках аднаго праекта. Гэта дазваляе ўжываць адразу некалькі падыходаў у распрацоўцы, напрыклад, іерархічныя мадэлі, што цалкам немагчыма ў цэнтралізаваных сістэмах.