Праблема рэзервовых копій

Уявіце сабе, што ў вас ёсць нейкі вялікі праект. Вы яго пішаце і ў які момант дасягаеце нейкай лагічнай завершанасці і выкатваеце версію 1.0, якой пачынаюць карыстацца юзеры.

Праца, аднак, на гэтым не сканчаецца і вы выкатваеце версію 1.1 з выпраўленнем памылак і дапаўненнямі, потым версію 1.2, потым 1.3, а потым усё перапісваеце нанава і аб'яўляеце аб выхадзе версіі 2.0. Ну і так далей - праца над праектам звычайна ніколі не сканчаецца.

У працэсе распрацоўкі, аднак, ёсць рызыка нешта зламаць у кодзе, альбо выпадкова выдаліць праект ці яго частку. Каб не страціць ўсю працу, вы перыядычна захоўваеце код праекта ў асобную папку. Сваё захаванні вы проста нумаруеце па парадку, паказваючы нейкі каментар да захаванні, аб тым, якія змены вы ўнеслі ці які функцыянал вы ўжо зрабілі да гэтага моманту захавання.

Аднак, раптам аказалася, што нельга проста ўзяць і выкаціць версію 2.0, таму што карыстальнікі першай версіі абурваюцца - яны пакуль не гатовыя пераходзіць на другую. Окей, кажаце вы, і пачынаеце працаваць над другой версіяй, паралельна выпускаючы абнаўленні ў першую. Ваш праект распадаецца на дзве папкі - для першай версіі і для другой. Таксама распадаецца папка для рэзервовага капіравання. Пры гэтым частка кода першай і другой версіі аднолькавыя. Уносячы праўкі ў гэты код у адной версіі праекта, вы павінны не забыць унесці праўкі і ў другой версіі. Вы, аднак, часам забываеце гэта зрабіць. З'яўляюцца дзіўныя багі. Праца стаіць.

У працэсе над версіяй 2.0 вы вырашылі дадаць новую фічу. Аднак, рабіць яе доўга і вы вырашаеце разбіць другую версію на дзве папкі, здубляваўшы код. У першай папцы вы будзеце весці далейшую распрацоўку над вашым праектам, а ў другой рабіць прыдуманую фічу. Нарэшце, фіча дароблена. За гэты час асноўны праект стаў ужо версіяй 2.3. Цяпер вам трэба аб'яднаць код з фічай з асноўным кодам праекта. Вы пачынаеце капіяваць файлы з кодам у асноўную папку, папутна разбуроўваючы канфлікты новага кода і старога. Гэта адмаўляе ў вас тры працоўныя дні. Праца стаіць.

Праект вырас. Вы вырашаеце паклікаць на дапамогу сябра. Вы выдаеце сябру заданне і прысылаеце яму архіў з праектам. Сябар робіць заданне і вяртае вам архіў з новымі файламі, а таксама са старымі, у якія ён унёс змены. Паўдня вы траціце на тое, каб аддзяліць новыя файлы ад старых. Затым яшчэ дзень вы траціце на тое, каб праінтэграваць змены ў свае файлы.

Вы клічаце на дапамогу яшчэ двух сяброў. Цяпер вас чацвёра. Щодня вам прысылаюць архівы з зробленай працай. Вы інтэгруеце новыя часткі ў праект і рассылаеце ўсім архівы праекта з зменамі. Праца прасоўваецца павольна, так як пакуль вы інтэгруеце адно змяненне, вашыя сябры чакаюць, пакуль вы прышлеце ім новую версію праекта і не могуць працаваць далей, каб зусім не рассінхранізавацца.

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

Гучыць не вельмі, так? Аднак, распрацоўшчыкі сапраўды раней працавалі так, як я вышэй апісаў. Гэта, вядома ж, было вельмі незручна. Таму з'явілася спецыяльная сістэма Git, аб магчымасцях якой мы пагаворым у наступным уроку.