Изпратете добрата си работа в базата знания е лесно. Използвайте формата по-долу

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

публикувано на http://www.allbest.ru/

Министерство на образованието и науката на Руската федерация

Федерален държавен бюджет за образование

Институция за висше професионално образование

„ТОМСКИ ДЪРЖАВЕН УНИВЕРСИТЕТ

СИСТЕМИ ЗА УПРАВЛЕНИЕ И РАДИОЕЛЕКТРОНИКА" (ТУСУР)

Отдел радиосистеми(RTS)

Курсова работа

в курса "Информационни технологии"

СИСТЕМИ ЗА КОНТРОЛ НА ВЕРСИИ

Студенти от група 121-3 Королев Д.О.,

Кулешов М.В., Садов Д.А., Таймасов С.С.

Ръководител Nozdrevatykh B.F.

Курсова работа 46 стр., 31 фигури, 2 таблици, източници.

СИСТЕМА ЗА КОНТРОЛ НА ВЕРСИИ, GIT, SVN, MERCURIAL.

Тази курсова работа разглежда най-популярните системи за контрол на версиите.

Целта на работата е да се запознаят със системите за контрол на версиите, да разберат тяхната работа, инсталиране и конфигуриране.

По време на работата бяха инсталирани, конфигурирани и тествани три вида системи за контрол на версиите.

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

Курсовата работа е завършена в текст Microsoft редактор Word 2010 и се предлага в печатен и електронен формат.

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

Въведение

3.1 Първи стъпки с проекта

3.2 Ежедневен работен цикъл

3.3 Клонове

3.4 Обединяване на версии

3.5 Конфликти и тяхното разрешаване

3.6 Брави

3.7 Версии на проекта, тагове

4.1 Локални системи за контрол на версиите

4.2 Централизиран модел

5.1.1 Системни изисквания

5.1.2 Концепция

5.1.3 Първи стъпки

5.2.1 Системни изисквания

5.2.2 Инсталиране

5.2.3 Основна концепция

5.2.4 Създаване на хранилище

5.2.5 Импортиране на проект

5.2.7 Правене на промени

5.2.8 Добавяне на нови файлове

5.2.9 Отмяна на промените

5.3.1 Системни изисквания

5.3.2 Концепция

5.3.3 Първи стъпки

Заключение

Приложение А

Приложение Б

Приложение Б

Въведение

Днес в свят, в който има голяма сума сложни системи, има нужда от модификация електронни документина различни етапи от тяхното развитие. По време на своето съществуване един електронен документ може да бъде обект на голям брой промени. Често обаче се случва, че за по-нататъшна работаНеобходима е не само последната версия на документа, но и различни предишни версии.

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

В резултат на това са разработени софтуерни инструменти, които опростяват този механизъм. Тези инструменти се наричат ​​системи за контрол на версиите. Има няколко системи от този вид, всяка от които е подходяща при определени условия на тяхното използване.

Основната идея на системите за контрол на версиите е да запомнят всички направени промени, както и коментари от потребителите, които са ги направили. След това става ясно кой, кога и какво е променил, защо и защо. И което е важно, всички тези промени могат след това да бъдат отменени по всяко време.

В съответствие с целта е необходимо да се решат следните задачи:

Дефинирайте понятието система за контрол на версиите;

Разберете как работят такива системи;

Прегледайте правилата за инсталиране и стартиране;

Анализирайте съществуващите системи за контрол на версиите;

Помислете за основните типове на този тип система.

Целите на работата предопределиха нейната структура. Курсовата работа се състои от пет глави, въведение, заключение, библиография и приложение.

1. Концепцията за система за контрол на версиите

Системата за контрол на версиите (VCS) е софтуер за улесняване на работата с променяща се информация. Системата за контрол на версиите ви позволява да съхранявате множество версии на един и същ документ, да се върнете към по-ранни версии, ако е необходимо, и да определите кой е направил определена промяна и кога.

2. Използване на система за контрол на версиите

Този тип системи се използват най-вече в разработката софтуер, така че да можете да съхранявате изходните кодове на програмите, които се разработват. VCS позволява на разработчиците да съхраняват предишни версии на файлове от разработката и да ги извличат от там. Той съхранява информация за версията за всеки файл (и пълната структура на проекта) в колекция, обикновено наричана хранилище. Но въпреки това тези системи могат да се използват в други области на знанието, които включват огромен брой често променящи се електронни документи. Например, те се използват все повече в CAD, обикновено като част от системи за управление на данни за продукти (PDM). Версионирането се използва в инструментите за управление на конфигурацията.

Използването на VCS определено е задължително за разработчика, ако проектът е повече от няколкостотин реда или ако няколко разработчици работят заедно по проекта.

Системите за контрол на версиите решават следните проблеми:

Съхраняване на файлови версии;

Възможност за получаване на предишни версии на съхранени файлове;

Вижте промените, направени между версиите, посочени в заявката;

3. Типова процедура за работа със системата

Всеки VCS има свои специфични характеристики в набора от команди, начина на работа на потребителите и администрирането. Въпреки това, общата оперативна процедура за повечето VCS е напълно стереотипна. Тук се предполага, че проектът, какъвто и да е той, вече съществува и неговото хранилище се намира на сървъра, до който разработчикът има достъп.

3.1 Първи стъпки с проекта

Първата стъпка, която разработчикът трябва да предприеме, е да извлече работно копие на проекта или частта от него, върху която ще се работи. Това действие се извършва с помощта на стандартна команда за проверка на версията (проверка или клониране) или специална команда, която всъщност изпълнява същото действие. Разработчикът определя версията, която трябва да се копира; по подразбиране най-новата версия (или избраната от администратора като основна) обикновено се копира.

Командата за извличане установява връзка със сървъра и проектът под формата на дърво от директории и файлове се копира на компютъра на разработчика. Често срещана практика е да се дублира работно копие: в допълнение към основната директория с включен проект местен дискОсвен това е записано още едно негово копие. Когато работи по проект, разработчикът променя само файловете в основното работно копие. Второ локално копие се съхранява като справка, което ви позволява да определите по всяко време, без да се свързвате със сървъра, какви промени са направени в конкретен файлили проекта като цяло и от коя версия е направено работното копие; като правило всеки опит ръчна промянатова копие води до грешки в работата на VCS софтуера.

3.2 Ежедневен работен цикъл

С някои вариации, определени от характеристиките на системата и детайлите на възприетия бизнес процес, обичайният цикъл на работа на разработчика през работния ден изглежда така:

1) Актуализиране на работното копие. Тъй като се правят промени в основната версия на проекта, работното копие на компютъра на разработчика става старо: несъответствието му с основната версия на проекта се увеличава. Това увеличава риска от противоречиви промени. Следователно е удобно да се поддържа работно копиев състояние, възможно най-близко до текущата основна версия, за което разработчикът извършва операция за актуализиране на работното копие възможно най-често.

2) Модификация на проекта. Разработчикът модифицира проекта, като променя включените файлове в работното копие в съответствие със спецификацията на дизайна. Тази работа се извършва локално и не изисква извиквания към VCS сървъра.

3) Коригиране на промените. След като приключи следващия етап от работата по задача, разработчикът ангажира своите промени, прехвърляйки ги на сървъра, или към главния клон, ако работата по задачата е напълно завършена, или към отделен клон за разработка за тази задача. VCS може да изисква от разработчика да актуализира работното копие, преди да се ангажира. Ако системата поддържа отлагане на промените, промените могат да бъдат прехвърлени към сървъра без ангажиране. Ако одобрената работна политика в системата за твърда валута позволява това, тогава промените могат да се записват не ежедневно, а само след приключване на работата по задачата; в този случай всички промени, свързани със заданието, се запазват само в локалното работно копие на разработчика, докато заданието не бъде завършено.

3.3 Клонове

Можете да направите дребни корекции в проекта чрез директно редактиране на работното копие и след това записване на промените директно в главния клон (trunk) на сървъра. Въпреки това, когато извършвате значително количество работа, този ред става неудобен: липсата на запис на междинни промени на сървъра не позволява да се работи върху нищо в групов режим; освен това рискът от загуба на промени по време на локални аварии се увеличава и способността за анализиране и връщане към предишни е загубена кодови варианти в рамките на тази работа. Следователно за такива промени обичайната практика е да се създават клонове, създавайки версия на нова версия на проекта или част от него, чието развитие се извършва успоредно с промените в основната версия. Когато работата, за която е създаден клонът, приключи, клонът се реинтегрира в основния клон. Това може да стане с командата merge или чрез създаване на корекция, съдържаща промените, направени по време на разработката на клона, и прилагане на тази корекция към текущата основна версия на проекта.

3.4 Обединяване на версии

Три вида операции, извършвани в контрола на версиите, могат да доведат до необходимостта от обединяване на промените:

Актуализиране на работното копие;

Записване на промени;

Сливане на клонове.

Всяка система има механизъм за автоматично сливане, който работи въз основа на следните принципи:

Промените могат да се състоят от модифициране на съдържанието на файл, създаване на нов файл или директория, изтриване или преименуване на вече съществуващ файл или директория в проекта;

Ако две промени се отнасят до различни и несвързани файлове и/или директории, те винаги могат да бъдат обединени автоматично. Тяхното обединяване е, че промените, направени във всяка версия на проекта, се копират в обединената версия;

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

Конфликтните обикновено са:

Изтриване и промяна на същия файл или директория;

Изтриване и преименуване на същия файл или директория;

Създаване в различни версиифайл със същото име и различно съдържание;

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

Промените в един и същ файл, освен ако не е текстов файл, винаги са в конфликт и не могат да бъдат обединени автоматично.

Във всички случаи основната версия, която трябва да бъде обединена, е версията, в която обединените версии са били разделени. Ако това е операция за ангажиране, тогава базовата версия ще бъде версията на последната актуализация преди извършването; ако е актуализация, тогава версията на предишната актуализация; ако се сливат клонове, тогава версията, в която е създаден съответният клон. Съответно, наборите от промени, които се сравняват, ще бъдат наборите от промени, направени от база към сегашна версиявъв всички комбинирани варианти.

Абсолютно мнозинство модерни системиКонтролът на версиите е насочен предимно към проекти за разработка на софтуер, в които основният тип файлово съдържание е текст. Съответно механизмите за автоматично обединяване на промените са фокусирани върху обработката на текстови файлове.

При определяне на допустимостта на обединяване на промени в рамките на един и същ текстов файл работи стандартен механизъм за сравнение на текст ред по ред (пример за неговата реализация е системната помощна програма GNU diff), който сравнява обединените версии с базовата и изгражда списък с промени, тоест добавени, изтрити и заменени набори от редове. Намерените набори от модифицирани низове, които не се пресичат, се считат за съвместими и тяхното сливане се извършва автоматично. Ако обединените файлове съдържат промени, които засягат един и същи файлов ред, това води до конфликт. Такива файлове могат да се обединяват само ръчно. Всички файлове, различни от текстови, са двоични от гледна точка на VCS и не позволяват автоматично сливане.

3.5 Конфликти и тяхното разрешаване

Ситуация, при която при обединяването на няколко версии направените в тях промени се припокриват една с друга, се нарича конфликт. Ако има конфликт на промени, системата за контрол на версиите не може автоматично да създаде обединен проект и е принудена да се свърже с разработчика. Както бе споменато по-горе, конфликти могат да възникнат на етапите на извършване на промени, актуализиране или сливане на клонове. Във всички случаи, когато бъде открит конфликт, съответната операция се спира, докато не бъде разрешен.

За разрешаване на конфликт системата като цяло предлага на разработчика три опции за конфликтни файлове: базов, локален и сървър. Конфликтните промени или се показват на разработчика в специален софтуерен модул за обединяване на промените, или просто се маркират със специално маркиране директно в текста на обединения файл.

Конфликтите във файловата система се разрешават по-лесно: само изтриването на файл може да бъде в конфликт с някоя от другите операции, а редът на файловете в директорията няма значение, така че разработчикът може само да избере коя операция трябва да бъде запазена в обединена версия.

3.6 Брави

Заключващият механизъм позволява на един от разработчиците да вземе само собствена употребафайл или група от файлове, в които да направите промени. Докато файлът е заключен, той остава само за четене за всички други разработчици и всеки опит да се направят промени в него се отхвърля от сървъра. Технически блокирането може да се организира по различни начини. За съвременните системи е характерен следният механизъм:

Файловете, които изискват заключване за работа, са маркирани със специален флаг „заключени“;

Ако даден файл е маркиран като заключен, тогава, когато работно копие бъде извлечено от сървъра, му се дава атрибут само за четене в локалната файлова система, което го предпазва от случайно редактиране;

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

1. сървърът проверява дали файлът вече е блокиран от друг разработчик; ако е така, блокиращата команда е неуспешна.

2. файлът на сървъра се маркира като „блокиран“, като се записва ID на разработчика, който го е блокирал, и времето за блокиране;

3. Ако блокирането на сървъра е успешно, атрибутът „само за четене“ се премахва от файла с работно копие в локалната файлова система, което ви позволява да започнете да го редактирате.

Ако по време на работа се окаже, че файлът не трябва да се променя, той може да извика командата за отключване , освобождаване на ключалката). Всички промени във файла ще бъдат отменени, локалният файл ще се върне в състояние само за четене, атрибутът „заключен“ ще бъде премахнат от файла на сървъра и други разработчици ще могат да променят този файл;

След приключване на работата със заключения файл, разработчикът извършва промените. Обикновено блокирането се премахва автоматично.

3.7 Версии на проекта, тагове

Системата за контрол на версиите осигурява съхраняването на всички съществуващи версии на файлове и в резултат на това всички версии на проекта като цяло, които са възникнали от началото на неговото развитие. Но самата концепция за „версия“ в различни системиможе да се тълкува по два различни начина.

Някои системи поддържат файлови версии. Това означава, че всеки файл, който се появява в проекта, получава собствен номерверсии. Всеки път, когато разработчик извърши промени във файл, съответната част от направените промени се прилага към файла и файлът получава нов, обикновено пореден номер на версия.

За други системи понятието „версия“ се отнася не до отделен файл, а до цялото хранилище. Новосъздадено празно хранилище има версия 1 или 0, всички промени в ангажиментите водят до увеличаване на този брой. Тук всъщност няма номер на версия за отделен файл.

И двата варианта обаче не са много удобни. За по-удобно маркиране на версиите на проекта, системите за контрол на версиите поддържат концепцията за тагове.

Етикетът е символичен етикет, който може да бъде свързан с конкретна версия на файл и/или директория в хранилище. С помощта на съответната команда всички или част от файловете на проекта, които отговарят на определени условия, могат да получат даден етикет. По този начин можете да идентифицирате версията на проекта, като фиксирате състоянието му в даден желан момент. Като правило системата за маркиране е доста гъвкава и ви позволява да маркирате множество версии на файлове и директории с един етикет. Това ви позволява да изградите „версия на проекта“ по произволен начин.

4.1 Локални системи за контрол на версиите

Най-предпочитаният VCS за наблюдение на домашното развитие ще бъде локалният тип. За да се реши този проблем, бяха разработени специални VCS с проста база данни, в която се съхраняват всички локални файлове.

Фигура 4.1 Схема на локален SCR

Един от най-популярните VCS от този тип е RCS, който все още е инсталиран на много компютри.

4.2 Централизиран модел

Традиционните системи за контрол на версиите използват централизиран модел, при който се управлява едно хранилище на документи специален сървър, който изпълнява повечето функции за контрол на версиите. Потребителят, който работи с документи, трябва първо да получи версията на документа, от която се нуждае от хранилището; Обикновено се създава локално копие на документа, така нареченото „работно копие“. Може да се получи най-новата версия или някоя от предишните, които могат да бъдат избрани по номер на версия или дата на създаване, понякога по други критерии. След извършване на необходимите промени в документа, новата версия се поставя в хранилището. За разлика от простото запазване на файл, предишната версия не се изтрива, но също остава в хранилището и може да бъде извлечена от там по всяко време.

Такива системи, като CVS, Subversion и Perforce, имат централен сървър, който съхранява всички файлове под контрол на версиите, и редица клиенти, които получават копия на файловете от него. Това е стандартът за системите за контрол на версиите от много години.

Фигура 4.2 Схема за централизиран контрол на версиите

Този подход има много предимства, особено пред локалния SLE. Например всеки знае кой какво прави в проекта. Администраторите имат ясен контрол върху това кой какво може да прави и, разбира се, CSKB е много по-лесен за администриране от локалните бази данни на всеки клиент.

Този подход обаче има няколко сериозни недостатъка. Най-очевидното е, че централизираният сървър е слабото място на цялата система. Ако сървърът спре за един час, тогава разработчиците не могат да взаимодействат за един час и никой не може да запази нова версия на тяхната работа. Ако дискът с централната база данни е повреден и няма резервно копие, вие губите абсолютно всичко - цялата история на проекта, с изключение на няколко работни версии, записани на работните машини на потребителите. Локалните VCS са обект на същия проблем: ако цялата история на проекта се съхранява на едно място, рискувате да загубите всичко.

4.3 Разпределени системи за контрол на версиите

Такива системи използват разпределен модел вместо традиционния модел клиент-сървър. Като цяло те не се нуждаят от централизирано хранилище: цялата история на промените в документа се съхранява на всеки компютър, в локално хранилище и, ако е необходимо, отделни фрагменти от историята на локалното съхранение се синхронизират с подобно хранилище на друг компютър. Следователно, в случай че сървърът, през който работата е била прекратена, се повреди, всяко клиентско хранилище може да бъде копирано обратно на сървъра, за да се възстанови базата данни. В някои от тези системи локалното хранилище се намира директно в директориите на работното копие.

Фигура 4.3 Разпределен VCS модел

Когато потребител на такава система извършва нормални действия, като извличане на конкретна версия на документ, създаване на нова версия и други подобни, той работи със своето локално копие на хранилището. Тъй като се правят промени, хранилищата, принадлежащи на различни разработчици, започват да се различават и има нужда да ги синхронизирате. Такава синхронизация може да бъде постигната чрез обмен на пачове или така наречените набори между потребителите.

Описаният модел е логически близо до създаването на отделен клон за всеки разработчик в класическа система за контрол на версиите. Разликата е, че до синхронизирането другите разработчици не виждат този клон. Докато разработчикът модифицира само собствения си клон, работата му не засяга други членове на проекта и обратно. След завършване на отделната част от работата, направените промени в клоновете се обединяват с основния (общ) клон. Както при сливане на клонове, така и при синхронизиране на различни хранилища са възможни конфликти на версиите. В този случай всички системи предоставят определени методи за откриване и разрешаване на конфликти при сливане.

От гледна точка на потребителя, разпределената система се отличава с необходимостта от създаване на локално хранилище и наличието на команден езикдве допълнителни команди: командата за получаване на хранилище от отдалечен компютър и прехвърляне на вашето хранилище на отдалечения компютър. Първата команда обединява промените от отдалечените и локалните хранилища и поставя резултата в локалното хранилище; вторият, напротив, обединява промени от две хранилища и поставя резултата в отдалечено хранилище. Обикновено командите за сливане в разпределени системи ви позволяват да избирате кои набори от промени да бъдат насочени към или изтеглени от друго хранилище, да коригирате конфликтите на сливане директно по време на операцията или след неуспеха й и да опитате отново или да възобновите незавършено сливане. Обикновено прехвърлянето на вашите промени в хранилището на някой друг е успешно само ако няма конфликти. Ако възникнат конфликти, потребителят трябва първо да обедини версиите в своето хранилище и едва след това да ги прехвърли на други.

Обикновено се препоръчва да се организира работата със системата така, че потребителите винаги или предимно да извършват сливания в техните хранилища. Това означава, че за разлика от централизираните системи, където потребителите изпращат своите промени на централния сървър, когато сметнат за добре, в разпределените системи е по-естествено обединяването на версиите да бъде инициирано от лицето, което трябва да получи резултата (например разработчик, управляващ сървър за изграждане).

Основните предимства на разпределените системи са тяхната гъвкавост и значително по-голямата (в сравнение с централизираните системи) автономност на индивидуалното работно място. Компютърът на всеки разработчик всъщност е независим и напълно функционален сървър; от такива компютри можете да изградите система с всякаква структура и ниво на сложност, като зададете желания ред на синхронизиране.

Недостатъците на разпределените системи включват увеличаване на необходимия обем дискова памет: всеки компютър трябва да съхранява пълна хронология на версиите, докато в централизирана система обикновено се съхранява само работно копие на компютъра на разработчика, тоест част от хранилището в даден момент и направените промени. По-малко очевиден, но неприятен недостатък е, че е почти невъзможно да се приложат някои от функционалностите, предоставени от централизирани системи в разпределена система. Това:

- Блокиране на файл или група от файлове (за съхраняване на блокиращия атрибут е необходим централен сървър, който е публично достъпен и постоянно онлайн). Това налага да се вземат специални административни мерки, ако трябва да се работи с бинарни файлове, които не са подходящи за автоматично сливане;

- Наблюдение на конкретен файл или група от файлове;

- Единична непрекъсната номерация на системни версии и/или файлове, при която номерът на версията нараства монотонно. В разпределените системи човек трябва да се задоволи с обозначения на локални версии и да използва етикети, чиято цел се определя от споразумение между разработчиците или корпоративните стандарти на компанията;

- Работа на локален потребител с отделна извадка с малък обем от съоръжение за съхранение със значителен размер и вътрешна сложност на отдалечен сървър.

Могат да бъдат идентифицирани следните типични ситуации, при които използването на разпределена система осигурява забележими предимства:

- Периодична синхронизация на няколко компютъра под контрола на един разработчик. Използването на разпределена система елиминира необходимостта от разпределяне на един от компютрите като сървър;

- Съвместна работа по проект от малка, географски разпределена група разработчици без разпределяне на споделени ресурси. Както в предишния случай, работната схема се изпълнява без основен сървър, а релевантността на хранилищата се поддържа чрез периодични синхронизации по схемата „всеки с всеки“;

Голям разпределен проект, участниците в който могат да работят всеки от своята страна дълго време, но нямат постоянна връзка с мрежата. Такъв проект може да използва централизиран сървър, с който се синхронизират копия на всички негови участници. Възможно е да се работи без „групови“ сървъри, след което разработчиците на една група синхронизират промените помежду си, след което всеки от тях прехвърля промените към централния сървър.

5. Примери за системи за контрол на версиите

5.1 GIT

5.1.1 Системни изисквания

GitРаботи под следните операционни системи: Windows, Linux и Mac OS.

За да инсталирате Git на Windows, просто трябва да изтеглите инсталационния exe файл от страницата на проекта в GitHub и да го стартирате.След инсталирането ще имате както конзолна версия (включително SSH клиент), така и стандартна графична.

5.1.2 Концепция

Gitе разпределена система за контрол на версиите. В него файловете могат да бъдат в едно от трите състояния: ангажирани, модифицирани и подготвени. „Извършен“ означава, че файлът вече е записан във вашата локална база данни. Променените файлове включват файлове, които са променени, но все още не са ангажирани. Поетапните файлове са модифицирани файлове, които са маркирани за включване в следващия комит.

По този начин проектите, използващи Git, имат три части: Git директория, работна директория и промеждутъчна област.

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

Работната директория е копие на конкретна версия на проекта, извлечена от базата данни. Тези файлове се изтеглят от компресирана база данни в директорията Git и се поставят на диск, за да ги преглеждате и редактирате.

Областта за етап е обикновен файл, обикновено съхраняван в директорията Git, който съдържа информация за това какво трябва да влезе в следващия комит. Понякога се нарича индекс, но напоследък стана стандартно да се нарича област за етап ( област за етап) .

Стандартен работен процес с помощта на Git изглежда по следния начин:

1. Правите промени във файловете във вашата работна директория.

2. Подгответе файлове, като добавите техните моментни снимки към областта за подготвени файлове.

3. Направете ангажимент, който взема подготвените файлове от индекса и ги поставя в Git директорията за постоянно съхранение.

Ако работната версия на файла съвпада с версията в директорията Git, файлът се счита за ангажиран Ако файлът е променен, но е добавен към подготвената област с данни, той е подготвен Ако файлът е променен след разтоварване от базата данни, но не е бил изготвен, тогава се счита за модифициран.

5.1.3 Първи стъпки

Всички работят в Git се намира в хранилище, което съдържа всички файлове на работата. Можете да създадете хранилище по различни начини.

1. Чрез контекстното меню. За да направите това, просто трябва да щракнете с десния бутон върху желаната директория и да изберете Git Init Here.

Фигура 5.1.1 Създаване на хранилище чрез контекстното меню

2. Използване на командния ред. За да направите това, по подобен начин в необходимата директория изберете Git Bash в контекстното меню. Ще се отвори команден ред, в който създаваме хранилището с помощта на командата Git Init.

Фигура 5.1.2 Създаване на хранилище с помощта на командния ред

Ако никога преди не сте използвали git, първо трябва да въведете вашето име и имейл чрез следните команди, съответно:

git config --global user.name "Вашето име"

git config --global user.email [имейл защитен]

Създаденото хранилище ще съдържа .git директория. За да добавите файл към хранилището, просто трябва да го копирате във вашата работна директория. Нека добавим файла ex.txt към хранилището. С помощта на командата git status ще се уверим, че Git е видял файла.

Фигура 5.1.3 Добавяне и проверка на файл в хранилището

След това, за да добавите файл под контрол на версиите, трябва да индексирате тези файлове и да извършите първото извършване на промени. Това може да стане с няколко git add команди, указващи файловете, които да бъдат индексирани, и след това git commit.

Фигура 5.1.4 Добавяне на файл под контрол на версиите

Командата git status е основният инструмент, използван за определяне кои файлове в какво състояние са.

За да започнете да проследявате (добавете под контрол на версията) нов файл, използвайте командата git add „filename“. Тази команда приема като параметър пътя до файл или директория, ако това е директория, командата рекурсивно добавя (индексира) всички файлове в дадената директория.

Git commit -m “comment” е команда за създаване на комит, коригираща промяна.

Използвайки графичния интерфейс Git Gui, ще повторим предишната операция. За да направите това, изберете елемента Git Gui в контекстното меню.

Фигура 5.1.5

В прозореца, който се отваря, изберете „Създаване на ново хранилище“. След това посочваме директорията, в която искаме да поставим хранилището.

Фигура 5.1.6 Създаване на хранилище в Git Gui

Добавете файла Ex.txt към директорията. След това щракнете върху бутона „Прочетете отново“. За да добавите файл към контрола на версиите, трябва да щракнете върху бутона „Подгответе всички“. Файлът Ex.txt трябва да се премести от прозореца „Променен“ в прозореца „Подготвен“. За да коригирате промяната, използвайте бутона „Запазване“.

5.1.5 Създаване на копие на хранилището

В наши дни имате огромен брой опции за хостинг, от които да избирате, всяка със собственапредимства и недостатъци.

В този раздел ще разгледаме процеса на създаване на акаунт и нов проект в GitHub. Това ще ви даде представа за включените неща.

GitHub е най-големият Git хостинг сайт за проекти с отворен код днес и един от малкото, които предлагат публичен и частен хостинг.

Първото нещо, което трябва да направите, е да създадете акаунт и да създадете вашето хранилище на http://github.com/plans.

След това в командния ред на Git въведете командите, които вече знаем:

Git добави ex.txt

Git commit -m "коментар"

Git дистанционно добавя произход https://github.com/Arbuz-z-z/MyHomework.git

Git push -u оригинал на произход

Командата git remote add е за добавяне на отдалечени хранилища, а командата git push е за изпращане на локални промени към отдалечен сървър.

Фигура 5.1.7

Въведете потребителското име и паролата, посочени по време на регистрацията:

Фигура 5.1.8

Сега нашият проект е публикуван в GitHub, в хранилището - MyHomework с файла Tusur.txt и можем да дадем линк към него на всеки, с когото искаме да споделим проекта.

Фигура 5.1.9 Хранилище в GitHub

5.2 TortoiseSVN

5.2.1 Системни изисквания

TortoiseSVN работи на Windows XP (със Service Pack 3) или по-нова версия и се предлага както в 32-битова, така и в 64-битова версия. Инсталаторът за 64-битов Windows също включва 32-битова част.

5.2.2 Инсталиране

TortoiseSVN идва като лесен за използване инсталационен файл.

5.2.3 Основна концепция

Съхранение. Subversion използва централна база данни, която съдържа всички файлове с версии с техните пълна история. Тази база данни се нарича хранилище. Складът обикновено се намира на файлов сървър, на който е инсталиран Subversion, предоставящ данни на клиентите на Subversion (например TortoiseSVN) при поискване. Ако го направиш архивиране, след това копирайте хранилището си, тъй като то е оригиналът на всичките ви данни.

Работно копие. Точно тук работите. Всеки разработчик има свое собствено работно копие, понякога наричано sandbox, на тяхната локална машина. Можете да го получите от хранилището последна версияфайлове, работете върху него локално, без да взаимодействате с никой друг, и когато сте уверени в промените, можете да ангажирате тези файлове обратно в хранилището. Работното копие не съдържа хронологията на проекта, но съдържа копие на всички файлове, които са били в хранилището, преди да започнете да правите промени.

TortoiseSVN е разширение на Windows Explorer, така че първо трябва да стартирате Explorer.

Фигура 5.2.1 Преглед в Explorer

5.2.4 Създаване на хранилище

За този проект ще ни трябва хранилище, създадено на сигурно място, и сървър на Subversion, който да го управлява. Ще използваме функцията за локално съхранение на Subversion, която позволява директен достъп до хранилището, създадено на вашия твърд диск, и не изисква сървър.

Първо, нека създадем нова празна директория на компютъра. Може да е навсякъде, но за този урок ще го наречем s:\svn_repos. Сега щракнете с десния бутон върху новата папка и изберете TortoiseSVN от контекстното меню > Създаване на хранилище тук... Хранилището, създадено в папката, е готово за използване. Ще създадем и вътрешна структура на папки, като щракнете върху бутона „Създаване на структура на директория“.

Фигура 5.2.2 Създаване на хранилище

Фигура 5.2.3 Преглед на хранилището

5.2.5 Импортиране на проект

В момента имаме склад, но в момента е напълно празен. Да предположим, че имаме набор от файлове в E:\\TortoiseSVN, които бихме искали да добавим. Нека отидем в папката TortoiseSVN в Explorer и щракнете с десния бутон върху нея. Сега изберете TortoiseSVN > Импортиране..., което ще изведе диалогов прозорец.

Фигура 5.2.4 Прозорец за импортиране

Хранилището на Subversion е достъпно чрез URL, което ни позволява да посочим хранилището навсякъде в Интернет. IN в такъв случайтрябва да посочим нашето локално хранилище, което има URL file:///s:/svn_repos и към което добавяме името на нашия проект TortoiseSVN.

Друга важна характеристика на този диалогов прозорец е прозорецът за импортиране на съобщения, където можем да добавим съобщение за това, което правим. Когато трябва да прегледаме историята на проект, тези съобщения ще бъдат ценна помощ, за да видим какви промени са направени и кога.

5.2.6 Проверка на работно копие

Сега имаме проект в нашето хранилище и трябва да създадем работно копие за ежедневна работа. Струва си да се отбележи, че импортирането на папка не превръща автоматично тази папка в работно копие. За да създадете ново работно копие, Subversion използва термина "Check Out". Ще извлечем папката TortoiseSVN от нашето хранилище в папка за разработка, наречена e:\\TortoiseSVN\svn_repos. Нека създадем тази папка, след това щракнете с десния бутон върху нея и изберете TortoiseSVN > Извличане... Въведете URL адреса за извличане, в този случай file:///s:/svn_repos/TortoiseSVN, и щракнете върху OK. Нашата папка за разработка ще бъде пълна с файлове от хранилището.

Външният вид на тази папка е различен от обикновената папка. Всеки файл вече има зелен флаг в левия ъгъл. Това са икони за състояние на TortoiseSVN, които присъстват само в работното копие. Зелен статус означава, че файлът не се различава от версията на файла в хранилището.

5.2.7 Правене на промени

Можете да започнете работа. В папка TortoiseSVN започваме да променяме файлове - да кажем, че правим промени във файловете TortoiseSVN.docx. Имайте предвид, че иконите на тези файлове вече са червени и показват, че промените са направени локално.

Щракнете с десния бутон върху един от модифицираните файлове и изберете TortoiseSVN > Разлики. Инструментът за сравнение на файлове TortoiseSVN ще се стартира и ще ви покаже точно кои редове във файловете са променени.

Фигура 5.2.5 Сравнение на файлове

Сега нека актуализираме хранилището. Това действие се нарича „Извършване на промени“. Да щракнем Кликнете с десния бутонв папката TortoiseSVN и изберете командата TortoiseSVN > Комитиране. Ще се появи диалогов прозорец за ангажиране със списък с променени файлове и до всеки ще има отметка. Можем да изберем само няколко файла от списъка за ангажиране.

Фигура 5.2.6 Комитиране на файлове

5.2.8 Добавяне на нови файлове

Докато работим по проекта, ще ни трябвадобавяне на нови файлове, да предположим, че сме добавили нови функции във файл и сме добавили помощ в съществуващ файл. Щракнете с десния бутон върху папката и изберете TortoiseSVN > Добавяне. Диалоговият прозорец за добавяне показва всички неверсирани файлове и можем да изберем файловете, които искаме да добавим. Друг начин за добавяне на файлове е да щракнете с десния бутон върху самия файл и да изберете TortoiseSVN > Добавяне.

Сега, ако отворим папката за ангажиране, новият файл ще бъде показан като „Добавен“, а съществуващият файл като „Променен“.

5.2.9 Отмяна на промените

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

Ако искаме да се отървем от промени, които все още не сме успели да запишем и възстановим необходим файлвъв формата, в която беше преди началото на промените, след което изберете командата TortoiseSVN > Премахване на промените. Това действие ще отмени нашите промени и ще върне фиксираната версия на файла, с който започнахме. Ако искаме да премахнем само някои промени, тогава можем да използваме инструмента TortoiseMerge, за да видим промените и селективно изтриванепроменени линии.

Ако искаме да отменим конкретна ревизия, ще започнем с диалоговия прозорец на журнала и ще намерим проблемната ревизия. Изберете командата Контекстно меню > Отхвърляне на промените от тази версия и тези промени ще бъдат отхвърлени.

5.2.10 Характеристики на TortoiseSVN. Интеграция на Shell

TortoiseSVN се интегрира директно в обвивката на Windows (т.е. Explorer). Това означава, че можете да работите с инструментите, с които вече сте запознати, и не е необходимо да превключвате към различно приложение всеки път, когато имате нужда от функции за контрол на версиите!

И дори не е нужно да използвате Explorer. Контекстните менюта на TortoiseSVN работят в много други файлови мениджъри и в диалоговите прозорци за отваряне на файлове, използвани в повечето стандартни Windows приложения. Все пак трябва да сте наясно, че TortoiseSVN първоначално е проектиран като разширение за Windows Explorer и други приложения може да нямат пълна интеграция, като наслагвания на икони, които може да не се показват.

Състоянието на всеки файл и папка с версия се обозначава с малък знак в горната част на главната икона. По този начин можете да видите състоянието на вашето работно копие с един поглед.

5.2.11 Графичен потребителски интерфейс

Когато преглеждате списък с промени във файл или папка, можете да щракнете върху ревизия, за да видите коментарите за този ангажимент. Наличен е и списък с променени файлове - просто щракнете двукратно върху файл, за да видите какви конкретни промени са направени.

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

Всички команди на Subversion са достъпни от контекстното меню на Explorer. TortoiseSVN добавя свое собствено подменю там.

5.3 Mercurial

5.3.1 Системни изисквания

ППакетите Mercurial са налични за всяка популярна операционна система: Windows, Mac OS, Linux (Ubuntu, Debian, Fedora, OpenSUSE, Gentoo), Solaris.

Най-добрата версия на Mercurial за Windows е TortoiseHg, която може да бъде намерена на http://tortoisehg.org. Този пакет позволява команден ред и графичен потребителски интерфейс.

5.3.2 Концепция

Mercurial е разпределена (децентрализирана) система за контрол на версиите. Това означава, че работният процес обикновено изглежда така:

1. Включено персонален компютърсъздава се ново хранилище (чрез клониране на съществуващо хранилище, създаване на ново и т.н.);

2. Файловете се променят/добавят/изтриват в работната директория на това хранилище;

3. Промените се ангажират в това хранилище (т.е. в локално хранилище на персонален компютър);

4. Стъпки 2 и 3 се повтарят толкова пъти, колкото е необходимо;

5. Ако е необходимо, промените се синхронизират с други хранилища: наборите от промени на други хора се изтеглят и/или техните собствени се избутват.

Тоест, цялата ежедневна работа се извършва в локалното хранилище и когато възникне необходимост, резултатите от тяхната работа се изпращат до едно или повече други хранилища. Броят на стъпките при работа с отдалечени хранилища може да бъде намален чрез настройка на Mercurial на автоматично изпращанепромени в други хранилища при извършване.

5.3.3 Първи стъпки

Можете да работите в Mercurial чрез контекстното меню на Explorer, прозореца на работното пространство TortoiseHg Workbench (програмата създава съответния пряк път по време на инсталацията) или командния ред с помощта на командата hg.

5.3.4 Създаване на хранилище и работа с файлове

В Mercurial всичко се случва вътре в хранилището. Хранилището на проекта съдържа всички файлове, които са „свързани“ с проекта, както и историята на модификациите на тези файлове. Има три различни начина за създаване на хранилище.

За да създадете хранилище чрез контекстното меню на Explorer, просто щракнете с десния бутон върху желаната папка и изберете съответния елемент.

Фигура 5.3.1 Създаване на хранилище

В прозореца, който се показва, можете да потвърдите местоположението на папката на хранилището и да отворите създаденото хранилище в производствената среда.

Фигура 5.3.2 Местоположение на папката на хранилището

Хранилището се създава по подобен начин директно в прозореца на TortoiseHg Workbench: последователността File\New Repository извиква горния прозорец със същото име. В командния ред използвайте командата hg init, за да създадете хранилище в текущата директория<имя хранилища>. Създаденото хранилище ще съдържа .hg директория.

Фигура 5.3.3 Създаване на папка хранилище чрез командния ред

Ако искаме да добавим съществуващи файлове към хранилището, ние ги копираме в работната директория и използваме командата hg add, за да кажем на Mercurial да започне да ги наблюдава. Нека добавим файла към хранилището и да създадем нова версия.

Фигура 5.3.4 Добавяне на файл към хранилището и създаване на нова версия

Нека се уверим, че Mercurial вижда записания файл. Командата status показва състоянието на работното копие в сравнение със състоянието на локалното хранилище. Mercurial показва, че вижда файла example.txt, но този файл все още не е под контрол на версиите (символът "?" отляво на името на файла). За да кажем на Mercurial, че трябва да бъде версиран, ще изпълним hg add. Символът “A” се появява отляво на името на файла, което означава, че файлът readme.txt ще бъде добавен към системата за контрол на версиите по време на следващия комит (при създаване на нова ревизия), който се изпълнява с командата hg commit .

Командата hg commit може да се провали първия път. Mercurial записва вашето име и адрес с всяка ревизия, така че вие ​​или други потребители да можете да се свържете с автора на всяка промяна. За да зададете потребителското име, трябва да направите промени във файла hgrc, който се намира в директорията .hg в работната директория. Първоначалното съдържание на този файл трябва да изглежда така:

# Това е конфигурационен файл на Mercurial.

потребителско име = Име Фамилия [имейл защитен]

Редът "" декларира раздел от конфигурационния файл. Можете да прочетете "потребителско име =..." като "задайте стойността на променливата на потребителското име в раздела на потребителския интерфейс". Секциите продължават, докато започнат нови секции. Празни редовеи редовете, започващи с "#", се игнорират. Можете да използвате произволен текст като стойност на потребителското име, тъй като тази информация е предназначена за използване от други хора, а не за интерпретиране от Mercurial. Примерът по-горе използва обща конвенция за това: комбинация от име и имейл адрес.

Когато извършим промени, Mercurial ни отвежда до текстов редактор, за да въведем коментар, описващ модификациите, които сме направили в този набор от промени. Такова описание се нарича съобщение за промяна (описание на промените, описание на ревизията). Това ще бъде запис за читателите какво направихме и защо и ще бъде изведен, когато стартираме hg log, след като приключим с публикуването на ревизията.

Редакторът, който се отваря, когато стартирате hg commit, ще съдържа празен ред и няколко реда, започващи с "HG:".

HG: Въведете съобщение за ангажиране. Редовете, започващи с "HG:", се премахват.

HG: Оставете съобщението празно, за да прекратите ангажирането.

HG: --

HG: потребител: потребител

HG: клон "по подразбиране"

HG: променен example.txt

Mercurial игнорира редове, започващи с "HG:". Използва ги само, за да ни каже в кои файлове ще запише промени. Редактирането или изтриването на тези редове няма да повлияе на нищо. Ако промените решението си относно публикуването на промени, докато редактирате коментар, просто излезте от редактора, без да запазвате файлът се променя. Това няма да доведе до промени нито в хранилището, нито в работната директория.

Командата hg log по подразбиране отпечатва само първия ред от описанието на промяната. Затова е по-добре да напишете коментара така, че първият ред да е отделен. Няма твърди и бързи правила за останалата част от описанието на редакцията. Самият Mercurial не обработва и не се интересува от съдържанието на съобщенията за промяна, въпреки че вашият проект може да има правила, които диктуват определено форматиране.

Нека повторим тези операции с помощта на GUI на TortoiseHg Workbench. Преди да добавите файла в работната директория, прозорецът изглежда така.

Фигура 5.3.5 Добавяне на файл към работната директория

Нека прехвърлим файла в хранилището и обновим прозореца, като щракнете върху бутона вляво на лентата с инструменти. Нека добавим файла към системата за контрол на версиите, като използваме подходящата команда от контекстното меню (подобно на hg add).

Фигура 5.3.6 Команда на контекстното меню

Фигура 5.3.7 Добавяне на файл

След като файлът бъде добавен, в горния десен прозорец се изписва описание на ревизията и се създава нова ревизия чрез щракване върху бутона „Commit“. В долния десен прозорец се появява запис на направените промени. Ще забележите, че промените са представени под формата на графики.

Фигура 5.3.8 Промяна на графики

Можете също така да извършите промени, като използвате командата Hg Commit в контекстното меню на файл, поставен в хранилището, без да стартирате Workbench.

Фигура 5.3.9 Извършване на промени

Командата hg log или hg diff тук съответства на „Сравнете ревизиите на файла“ (щракнете с десния бутон върху името на файла).

Фигура 5.3.10 Сравнение на ревизии на файлове

В същия прозорец можете да се върнете към една от предишните ревизии, като използвате командата „Връщане към ревизия...“ или „Връщане на промените...“ в главния прозорец. Нека демонстрираме с пример, като първо сме записали още няколко промени във файла example.txt. Линията, маркирана в червено, е обърната, променя се.

Фигура 5.3.11 Отмяна на промените

5.3.5 Създаване на копие на хранилището

Въпреки че можете да копирате хранилището като нормална директория, по-добре е да използвате вградената команда на Mercurial. Нарича се hg clone, защото създава идентично копие на съществуващо хранилище. Едно от предимствата на използването на hg clone е, че ви позволява да клонирате хранилища по мрежата. Друго е, че помни откъде сме го клонирали.

Всяко хранилище на Mercurial е завършено, самостоятелно и независимо. Той съдържа собствено копие на файловете на проекта и тяхната история. Клонираното хранилище помни откъде е клонирано, но не комуникира с това хранилище или с което и да е друго, докато не му кажете. Следователно вие сте свободни да експериментирате с вашето хранилище. Това е безопасно, защото вашето хранилище е „затворен пясъчник“, промените в който няма да засегнат нищо друго освен него.

Нека създадем отдалечено копие на нашето хранилище (ще използваме папката Google Drive, което само по себе си е облачна услуга), за което ще изпълним последователността от команди File\Clone storage в TortoiseHg Workbench. Резултатът е показан на следващата фигура.

Фигура 5.3.12 Създаване на отдалечено копие на хранилището

Mercurial ни позволява да изпращаме промени в друго хранилище от хранилището, в което се намираме този моментние сме. Нека добавим нова ревизия (под коментара за локална промяна) към изходното хранилище и изпълним командата Storage\Synchronization\Push. Интерфейс работна средави позволява да изберете само онези ревизии, които трябва да бъдат натиснати. Моля, обърнете внимание, че е създаден нов клон в хранилището на отдалечен трезор за получената версия.

...

Подобни документи

Възможности на система за контрол на версиите - програма, предназначена за работа с променящи се документи. Неговите свойства и практики на използване. Вътрешна структура на хранилището. Работно копие на документи с версии. Централизирана и разпределена VCS.

презентация, добавена на 05.01.2014 г


Анализ на методите и средствата за контрол на достъпа до файлове. Проблеми със сигурността при работа с файлове, инструменти за контрол на достъпа. Идеология на изграждане на интерфейс, изисквания към архитектурата. Работа на системните класове. Оценка на себестойността на софтуерен продукт.

дисертация, добавена на 21.12.2012 г


Анализ на архитектурата на ОС Windows 8. Сравнение с предишни версии (Модерен UI интерфейс, работа с акаунти, модел за сигурност, диспечер на задачите, история на файловете, възстановяване на системата, Storage Spaces). Характеристики на различни версии на Windows 8.

курсова работа, добавена на 25.01.2016 г


Етапи на развитие автоматизирана системаприемане и резервиране на поръчки за маси в заведения. Анализ на средата за разработка на Android Development Tools. основни характеристикикомпонентни диаграми iOS приложения. Разглеждане на системата за контрол на версиите на сървъра.

курсова работа, добавена на 14.05.2014 г


Графични интерфейси и разширения за DOS. История на развитието на операционната система Microsoft Windows. Иновации в съвременните му версии: потребителски интерфейс, езикова интеграция, системи за сигурност. Хронология на развитие и архитектура на системата GNU/Linux.

резюме, добавено на 25.10.2010 г


Комплект за разработка на DirectX за Microsoft Windows, характеристики на набори от COM-съвместими обекти в неговия състав. Основни характеристики на версиите, шейдърни езици. Описание на основните използвани функции. Изходният код на програмата, примери за нейната работа.

курсова работа, добавена на 16.02.2015 г


Windows като посредник между потребителя и операционната система, улесняващ процеса на комуникация между тях, историята на формирането и развитието на първите му версии. Функционални характеристикиИ Windows разлики 95/98/ME и Windows NT/2000/XP/Vista/7, техните архитектурни решения.

презентация, добавена на 23.10.2013 г


Намаляване на разходите за ремонтни дейности за отстраняване на дефекти, постигнато чрез използване на информационна система за контрола им. Анализ предметна области софтуер. Изчисляване на спестявания поради повишена потребителска производителност.

дисертация, добавена на 19.01.2017 г


Понятие, същност, структура и видове операционни системи. Характеристики на операционната зала Windows системи XP, изисквания за неговото инсталиране, сравнителен анализ на версиите, конфигурационни характеристики, актуализации на версиите, инсталиране на драйвери на устройства и добавяне на нови.

резюме, добавено на 20.10.2009 г


Появата на първите версии на Windows графични интерфейсии разширения за DOS. Windows семейства 3.x и Windows 9.x, техните характеристики и основни функции. Еволюцията на технологията Plug and Play. Най-значимите подобрения в модерни версии Windows.

Изненадан съм колко много инженери по електроника не използват системи за контрол на версиите в своите проекти. И аз бях така, докато не опитах. Сега започвам всеки проект със създаване на хранилище.

Какво е?

И така, системите за контрол на версиите (VCS) са програма, която ви позволява да запазите цялата история на разработката на даден проект.

Защо е необходимо това?

Това е много, наистина мега-удобен инструмент за разработка. Случва се да сте писали и писали програма и накрая да сте счупили нещо. Ако програмата беше в контрол на версиите, можете лесно да се върнете към предишна версия на проекта и да видите какво се е променило, това ме е спасявало много пъти.

Например, наскоро започнах да изпитвам ограничения на скоростта в FPGA проект. Буквално за 5 минути намерих версия, в която още не са забивали и открих причината

Ако по един проект работят няколко човека, е почти невъзможно да се работи без система за контрол - започва хаос, всеки прави нещо различно и не е ясно кой какво е направил. С SUV можете удобно да видите кой какво е направил, промените, направени от други, стават много по-малко неочаквани.

Освен това има и по-екзотични приложения. Например, предавам промените в този сайт на сървъра, използвайки система за контрол на версиите.

Кое да избера?

Има огромно разнообразие от системи за контрол на версиите. Лично аз избрах Mercurial за себе си. Страхотна система, който препоръчвам на всеки - бърз, кросплатформен, с отличен графичен клиент. Съществуването на сайта се оказа много силен аргумент в негова полза. Никога не съм съжалявал за избора си.

Освен Mercurial, git и svn са доста често срещани сега. Git е по-често срещан в тълпата на Linux, svn е по-често срещан в корпоративна среда. Опитах се да ги използвам (макар и не за много дълго), но не видях нищо, което би си струвало да напусна mercurial.

Има уебсайт, където можете да съхранявате вашите проекти. Забележително е, че за разлика от github можете да създавате затворени хранилища безплатно (хранилището е място, където се съхраняват проекти). Трябва да платите само за тези проекти, които са затворени и върху които работят повече от 5 души. В същото време ограничението може да бъде разширено до 8 чрез изпращане на покани. Все още не съм превишил тази граница. Освен това има wiki и инструмент за проследяване на грешки, като цяло всичко необходимо за разработване на проекти.

Когато започнах да работя с него, сайтът поддържаше само Mercurial (отчасти поради това избрах Mercurial), но сега можете да създавате git хранилища там. Освен това можете да свържете вашия домейн към bitbucket. Ето например моята версия: hg.bsvi.ru

Как да започна?

Първо трябва да изтеглите клиента. Използвам tortoiseHg. Мисля, че няма да има проблеми с инсталацията.

След инсталирането е добра идея да зададете потребителско име по подразбиране. За да направите това, трябва да редактирате файла C:/Users/BSVi/mercurial.ini, трябва да добавите реда там

Потребителско име = bsvi

Естествено, bsvi трябва да бъде заменено с вашето име.

Сега сме готови да създадем проект и да започнем да правим нещо. За да направите това, щракнете върху „Създаване на хранилище“:

Там попълваме име, описание, избираме език. Можете да добавите wiki и инструмент за проследяване на грешки.

Сега щракнете върху бутона „клониране“ и копирайте това, което се появява там:

По-нататъшните операции зависят от това кой файлов мениджър използвате. Лично аз използвам далеч. Просто поставям копирания ред в командния ред:

Ако използвате explorer (хм), total commander или нещо подобно, тогава трябва да щракнете с десния бутон и да изберете:


Там в полето източник трябва да вмъкнете пътя, естествено, без hg клонинг:

Ще бъдете попитани за вашата парола и ще се появи директорията test-repo, в която всъщност ще се намира проектът.

Нека добавим няколко файла

Ако вече имате разработки за проекта, можете просто да ги копирате в директория. За образователни цели ще създадем файл main.c със следното съдържание:

#включи int main() (връща 0;)

Сега да се ангажираме. Комитът прави промени в проект. За да направите това, стартирайте hg workbench. Просто пиша thg на командния ред, за изследователи файлови мениджъритрябва да натиснете RMB->Hg Workbench.

Ще има въпросителен знак до нашия файл (това означава, че не е добавен към проекта). Нека поставим отметка до него и напишем описание на направеното:


Естествено, след това щракнете върху бутона „commit“.

Това е всичко, направени са промени в проекта. Тук трябва да обърнете внимание, че промените са направени само на локалния компютър (т.е. те все още не са на сървъра). За да прехвърлите промените на сървъра, трябва да щракнете върху бутона „push“, ето го:

Естествено, за да изпратите промените на сървъра, ще ви трябва парола.

Да сменим файла

Сега нека разгледаме една от много важните характеристики на системите за контрол на версиите - проследяване на версията на файла. Нека добавим екранен изход към нашата програма:

#включи int main() (printf("mercurial rules!"); return 0; )

Да отидем на hg workbench. Когато работя върху проект, дори не го затварям (повече за това по-късно), натискам f5, за да актуализирам списъка с файлове. Сега можете да видите какво се е променило след последния комит:

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

Какво да правим с боклука?

Когато работите по проект, се появява много боклук - например обектни файлове, файлове, генерирани от IDE, някои временни файлове, и така нататък. Би било хубаво да премахнете всичко, което не е свързано със самия проект от хранилището. Има файл за това.hgignore (да, с точка в началото на името).

Нека добавим боклук към проекта. Например създадох main.obj:

Ако сега актуализирате списъка с файлове, тогава, естествено, hg workbench ще предложи да добавите този файл към проекта:

Сега нека създадем файл.hgigonre и да напишем там, че искаме да игнорираме всички файлове с разширение obj:
синтаксис:glob *.obj

Ако актуализирате списъка с файлове, obj файловете ще изчезнат, но ще се появи .hgignore файлът, който може да бъде ангажиран:

Как мога да върна промените?

Нека възстановим нашата програма до състоянието, в което е била преди да бъде показана на екрана. За да направите това, просто изберете ангажимента, към който искате да се върнете назад, и щракнете върху този бутон:

Можете да върнете назад отделен файл по почти същия начин.

Заключение

Това е всичко, това са минималните познания за системите за контрол на версиите, които ще ви позволят да запазите историята на развитието на проекта. Естествено, има много други възможности, за които ще говоря по-късно.

Много хора смятат, че системите за контрол на версиите трябва да се използват само ако разработвате нещо в голяма тълпа, но това не е вярно :) Дори когато работите върху проект сам, системите за контрол на версиите са голяма помощ.

Например, ето екранна снимка на моя UTC (който разработвам сам) на най-трудното място в hg workbench:

Миша Радионов

Какво представляват системите за контрол на версиите и защо са ви необходими?

Връщане към

Представете си ситуацията: наели сте разработчик да добави, да кажем, функция за бърза поръчка към вашия онлайн магазин. Тъй като сайтът трябва да функционира и да генерира приходи през цялото време, разработчикът решава да работи на своя локален сървър.

Докато работи, дизайнерът изпрати ново лого, който веднага заменихте в шаблона на основната версия на сайта. В същото време намалихте шрифта в имената на продуктите, така че всичко да пасне на екрана на нетбука на един от вашите клиенти. След това актуализирахте няколко изображения на продукта. В този момент разработчикът реши да ви направи услуга - да изчисти откровено ненужната функционалност в неговата версия на вашия сайт, която предишният разработчик е написал. Както често се случва, и двамата смятате, че не сте направили нищо сериозно. Но грешите.

Когато версията на разработчика се качи на сайта, всички участници в разработката се хващат за главите. Резултатите от вашата работа се изтриват, появяват се грешки. Не е ясно какъв е проблемът. Надяваме се, че на този етап ще имате поне работещ архив под ръка, а в най-лошия случай ще прекарате няколко дни в ръчно откриване на проблеми. Как да избегнем попадането в такава ситуация? Нека да говорим.

Какво е VCS?

Система за контрол на версиите (от английски Version Control System, VCS или Revision Control System) - софтуер за улесняване на работата с променяща се информация. Wikipedia

А сега по прост начин

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

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

Обикновено за работа със система за контрол на версиите се използва отделен компютър (сървър) или интернет услуга, която предоставя възможност за наемане на такъв сървър.

Прост пример

Ако няколко души работят върху един документ на Excel, тогава само един човек може да редактира файла; останалите имат достъп само за четене. С помощта на VCS получавате възможност да редактирате файл наведнъж и от всички. Единственото условие е след извършване на промени, файлът да бъде записан на сървъра, а не на локален компютър. Но както бе споменато по-горе, инструментите ви позволяват да извършвате такива действия лесно и просто.

Система за контрол на версиите във Flag studio

В нашата работа използваме системата за контрол на версиите Git. Тази система е една от най-разпространените VCS. Това води до голяма подкрепа от Git общността. Друго предимство е лекотата на овладяване на системата, тъй като... има широк спектър софтуерни продуктиразработен специално за тази система.

Използваме програма за разработка на код, наречена IntelliJ IDEA. Той предоставя IDE, тоест голяма функционална база за разработчиците, включително удобен за потребителя интерфейсза работа с контрол на версиите. Така че, без да напускаме програмата, можем да видим какви промени са направени от един или друг разработчик на сайта, от който се нуждаем. Или, без да се страхувате да загубите промените си, вземете промените, направени от друг разработчик. Интерфейсът на IDEA изглежда по следния начин:

Използваме облачната услуга Bitbucket за съхраняване на версии. Тази услуга има удобен интерфейс и в допълнение към услугите за съхранение на вашите версии ви позволява да управлявате правилата за достъп до вашите продукти различни потребители. Предимството на използването на облачно хранилище е, че няма изисквания за познаване на настройката и администрирането на сървъра. Получавате всичко от кутията и можете да започнете да го използвате веднага. Всичко, което качвате в bitbucket, е лично, т.е. без ваше разрешение никой друг дори не може да види какво съхранявате. Bitbucket интерфейс:

Какво ни дава използването на VCS?

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

Какво дава това на нашите клиенти?

Да се ​​върнем към ситуацията, обсъдена в началото. Както би било с VCS. Разработчикът качва своя код в отделен клон. Преглеждате промените и ги прилагате само ако видите, че всичко е наред. Всичко се съхранява на едно място, безопасно, бързо и удобно. И когато има няколко разработчици, изобщо няма да можете да правите без VCS.

Моля, активирайте JavaScript, за да видите

Основи на VCS

Въведение

Преди да говорите за каквато и да е конкретна система за контрол на версиите, трябва да разберете какво представлява тя, какви са те и защо са се появили на първо място. Тази лекция има за цел да предостави първоначално въведение в контрола на версиите и системите за контрол на версиите и първо ще говоря за произхода на инструментите за контрол на версиите, кои системи за контрол на версиите са популярни в момента и какви са основните разлики между тях.

Относно контрола на версиите

Какво е контрол на версиите и защо ви е необходим?

Вероятно си струва да започнете с определението за система за контрол на версиите (VCS) - това е система, която записва промените в един или повече файлове, така че в бъдеще да е възможно да се върнете към някои стари версии на тези файлове.

Напоследък файловете са крайният резултат за много професии (например писане, научна работа и, разбира се, разработка на софтуер). Много време и усилия се изразходват за разработване и поддържане на тези файлове и никой не иска да отделя още повече време и усилия за възстановяване на данни, загубени в резултат на промени.

Нека си представим, че програмист разработва проект, състоящ се от един малък файл (между другото, примерът е съвсем реален, а не синтетичен и е срещан в реалния живот). След пускането на първата версия на проекта той е изправен пред труден избор: необходимо е да се коригират проблемите, докладвани от потребителите на първата версия и в същото време да се разработи нещо ново за втората. Дори ако просто трябва да коригирате възникнали проблеми, има голяма вероятност след някаква промяна проектът да спре да работи и трябва да определите какво е променено, за да улесните локализирането на проблема. Също така е препоръчително да поддържате някакъв дневник на направените промени и корекции, за да не извършвате една и съща работа няколко пъти.

В най-простия случай горният проблем може да бъде решен чрез съхраняване на няколко копия на файловете, например едно за коригиране на грешки в първата версия на проекта и второ за нови промени. Тъй като промените обикновено не са много големи в сравнение с размера на файла, възможно е да съхранявате само променените редове с помощта на помощната програма diff и по-късно да ги обедините с помощта на помощната програма patch. Но какво ще стане, ако проектът се състои от няколко хиляди файла и върху него работят стотина души? Ако в този случай използваме метода със съхранение отделни копияфайлове (или дори само промени), тогава проектът ще спре много бързо. В следващите лекции ще използвам програмни изходни кодове за примери, но всъщност почти всеки тип файл може да бъде поставен под контрол на версиите.

Ако сте графичен или уеб дизайнер и бихте искали да съхранявате всяка версия на изображение или оформление - и вероятно бихте го направили - тогава използването на система за контрол на версиите е много мъдро решение. VCS дава възможност за връщане на отделни файлове към по старому, върнете се към предишно състояниецелия проект, преглед на промените, настъпващи във времето, определяне кой е последният, който е направил промени в модул, който внезапно е спрял да работи, кой и кога е въвел някаква грешка в кода и много повече. Като цяло, ако, докато използвате VCS, съсипете всичко или загубите файлове, всичко може лесно да бъде възстановено. Освен това режийните разходи за всичко, което получавате, ще бъдат много малки.

Локални системи за контрол на версиите

Както бе споменато по-рано, един пример за локален SUV е изключително прост: много хора предпочитат да контролират версиите, като просто копират файлове в друга директория (обикновено добавяйки текуща датакъм името на каталога). Този подход е много често срещан, защото е прост, но също така се проваля по-често. Много е лесно да забравите, че сте в грешната директория и случайно да промените грешния файл или да копирате файлове на грешното място и да презапишете нужните ви файлове. За да решат този проблем, програмистите отдавна са разработили локален VCS с проста база данни, която съхранява всички промени в необходимите файлове

Една от най-популярните VCS от този тип е RCS (Revision Control System), която все още е инсталирана на много компютри. Дори в съвременната операционна система Mac OS X помощната програма rcs се инсталира заедно с инструментите за разработчици. RCS е разработен в началото на 80-те години от Walter F. Tichy. Системата ви позволява да съхранявате версии само на един файл, така че трябва да управлявате множество файлове ръчно. За всеки файл под системен контрол се съхранява информация за версията специален файлс името на оригиналния файл, към който накрая се добавят символите ",v". Например, за файла file.txt, версиите ще се съхраняват във файла file.txt,v. Тази помощна програма се основава на работа с набори от корекции между двойки версии (корекцията е файл, описващ разликата между файловете). Това ви позволява да пресъздадете всеки файл по всяко време, като прилагате последователни корекции. Системата използва помощната програма diff за съхраняване на версии. Въпреки че RCS отговаря на минималните изисквания за система за контрол на версиите, той има следните основни недостатъци, които също послужиха като тласък за създаването на следната разглеждана система:

• Работа само с един файл, като всеки файл трябва да се контролира отделно;
• Неудобен механизъм едновременна работаняколко потребителя със системата, хранилището просто се блокира, докато потребителят, който го е блокирал, не го отключи;
• Никой не ви освобождава от резервни копия, рискувате да загубите всичко.

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

Следващото голямо предизвикателство беше необходимостта от сътрудничество с разработчици на други компютри. За да се реши това, бяха създадени централизирани системи за контрол на версиите (CVCS). Такива системи, като CVS, Subversion и Perforce, имат централен сървър, който съхранява всички файлове под контрол на версиите, и редица клиенти, които получават копия на файловете от него. Това е стандартът за системите за контрол на версиите от много години.

Този подход има много предимства, особено пред локалния SLE. Например всеки знае кой какво прави в проекта. Администраторите имат ясен контрол върху това кой какво може да прави и, разбира се, CSKB е много по-лесен за администриране от локалните бази данни на всеки клиент. Този подход обаче има няколко сериозни недостатъка. Най-очевидният е, че централизираният сървър е слабото място на цялата система. Ако сървърът спре за един час, тогава разработчиците не могат да взаимодействат за един час и никой не може да запази нова версия на тяхната работа. Ако дискът с централната база данни е повреден и няма резервно копие, вие губите абсолютно всичко - цялата история на проекта, с изключение може би на няколко работни версии, записани на работните машини на потребителите.

CVS

CVS (система за едновременни версии) все още е най-широко използваната система, но бързо губи популярността си поради недостатъци, които ще обсъдя по-долу. Дик Грюн разработи CVS в средата на 80-те години. За съхраняване на отделни файлове CVS (както и RCS) използва файлове във формат RCS, но ви позволява да управлявате групи от файлове, разположени в директории. CVS също използва архитектура клиент-сървър, в която цялата информация за версията се съхранява на сървъра. Използването на архитектура клиент-сървър позволява CVS да се използва дори от географски разпределени екипи от потребители, където всеки потребител има своя собствена работна директория с копие на проекта. Както подсказва името, потребителите могат да споделят системата.

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

CVS също ви позволява да поддържате множество линии на разработка на проект, като използвате разклонения за разработка. Така, както бе споменато по-горе, можете да коригирате грешки в първата версия на проекта и едновременно с това да разработите нова функционалност.

CVS се използва от голям брой проекти, но разбира се не беше без недостатъци, които по-късно доведоха до появата на следващата разглеждана система. Нека да разгледаме основните недостатъци:

• Тъй като версиите се съхраняват в RCS файлове, не е възможно да се запазят версии на директория. Стандартен методза да заобиколите това препятствие е да запишете някакъв файл (например README.txt) в директория;
• Преместването или преименуването на файлове не подлежи на контрол на версиите. Стандартният начин да направите това е първо да копирате файла, да премахнете стария с помощта на командата cvs remove и след това да го добавите с новото му име с помощта на командата cvs add;

Подривна дейност

Subversion (SVN) е разработен през 2000 г. по инициатива на CollabNet. SVN първоначално е разработен като "по-добър CVS" и основната цел на разработчиците е да коригират грешките, направени в дизайна на CVS, като същевременно поддържат подобен интерфейс. SVN, подобно на CVS, използва архитектура клиент-сървър. Най-значимите промени в сравнение с CVS включват:

• Атомни промени (комит). Ако обработката на записване бъде прекъсната, няма да бъдат направени промени.
• Преименуването, копирането и преместването на файлове запазва цялата история на промените.
• Директориите, символните връзки и метаданните са обект на контрол на версиите.
• Ефективно съхранение на промени за двоични файлове.

Разпределени системи за контрол на версиите

И в тази ситуация влизат в действие разпределените системи за контрол на версиите (DVCS). В системи като Git, Mercurial, Bazaar или Darcs, клиентите не просто проверяват най-новите версии на файловете, но копират цялото хранилище. Следователно, в случай че сървърът, през който се извършва работата, „умре“, всяко клиентско хранилище може да бъде копирано обратно на сървъра, за да се възстанови базата данни. Всеки път, когато клиент вземе нова версия на файлове, той създава за себе си пълно копиевсички данни.

Освен това повечето от тези системи ви позволяват да работите с множество отдалечени хранилища, така че можете да работите по различен начин с различни групи хора по един и същи проект едновременно. По този начин в един проект можете да провеждате едновременно няколко вида работни процеси, което е невъзможно в централизираните системи.

Защо са необходими разпределени системи?

Както подсказва името, една от основните идеи на разпределените системи е липсата на ясно обозначено централно хранилище за версии - хранилище. В случай на разпределени системи, набор от версии може да бъде напълно или частично разпределен между различни хранилища, включително отдалечени. Този модел се вписва перфектно в работата на разпределени екипи, например екип от разработчици, разпределени по целия свят, работещи върху един проект с отворен код. програмен код. Разработчикът на такъв екип може да изтегли цялата информация за версията и след това да работи само на локалната машина. Веднага след като бъде постигнат резултатът от един от етапите на работа, промените могат да бъдат качени в едно от централните хранилища или публикувани за преглед на уебсайта на разработчика или в пощенски списък. Други участници в проекта, от своя страна, ще могат да актуализират своето копие на хранилището на версиите с нови промени или да изпробват публикуваните промени в отделен тестов клон за разработка. За съжаление, без добра организация на проекта, липсата на едно централно хранилище може да бъде недостатък на разпределените системи. Ако в случай на централизирани системи винаги има едно общо хранилище, откъдето можете да получите най-новата версия на проекта, тогава в случай на разпределени системи трябва организационно да решите кой от клоновете на проекта ще бъде основният. Защо разпределена системаконтролът на версиите може да представлява интерес за някой, който вече използва централизирана система - като Subversion? Цялата работа включва вземане на решения и в повечето случаи трябва да опитате различни опции: когато работите със системи за контрол на версиите, клоновете за разработка се използват за разглеждане на различни опции и работа върху големи промени. Въпреки че това е доста естествена концепция, не е лесно да се използва в Subversion. Освен това всичко става по-сложно в случай на множество последователни сливания от един клон към друг - в този случай трябва точно да посочите първоначалната и крайната версия на всяка промяна, за да избегнете конфликти и грешки. За разпределените системи за контрол на версиите клоновете за разработка са една от фундаменталните концепции - в повечето случаи всяко копие на магазин за версии е клон за разработка. По този начин механизмът за обединяване на промените от един клон в друг в случай на разпределени системи е един от основните, което позволява на потребителите да полагат по-малко усилия при използване на системата.

Кратко описание на популярни разпространени SUV

• Git е разпределена система за контрол на версиите, разработена от Линус Торвалдс. Първоначално Git е предназначен за използване в процеса на разработка Linux ядра, но по-късно започва да се използва в много други проекти - като, например, X.org и Ruby on Rails, Drupal. В момента Git е най-бързата разпределена система, използваща най-малкото хранилище за ревизии. Но в същото време, за потребители, мигриращи, например, от Subversion, Git интерфейсът може да изглежда сложен;
• Mercurial е разпределена система, написана на Език Pythonс няколко разширения в C. Проектите, които използват Mercurial, включват Mozilla и MoinMoin.
• Bazaar е система, разработена от Canonical, известна със своята дистрибуция на Ubuntu и уебсайт https://launchpad.net/. Системата е написана основно на Python и се използва от проекти като MySQL.
• Codeville е разпределена система, написана на Python, която използва иновативен алгоритъм за комбиниране на промени (сливане). Системата се използва например при разработката на оригиналния BitTorrent клиент.
• Darcs е разпределена система за контрол на версиите, написана на Haskell, използвана например от проекта Buildbot.
• Monotone е система, написана на C++ и използваща SQLite като хранилище за ревизии.

Въпросът би бил уместен преди 25 години. От около 10 години използването на система за контрол на версиите е задължително за всеки екип. Общо, удобно, сигурно съхранение на изходни кодове с история на промените, колективна собственост върху кода, разделяне на задачите и функционалност на приложението в екипа. Както и автоматизация на компилации, внедрявания и непрекъсната интеграция като цяло.

Иван Немитченко, GitLab
Улеснете живота си, като разработвате софтуерни продукти заедно.

Александър Макарчук, qb
Оптимизиране на развитието на екипа.

Петър Урваев, SimbirSoft
По време на разработката кодът на проекта се променя активно. В същото време е необходимо да се водят записи за вече извършеното и да се координират действията на отделните участници за едновременна промяна на кода, така че подобренията от участниците в проекта да вземат предвид всички предишни редакции, направени от други участници. Системата за контрол на версиите ви позволява да автоматизирате този процес.

2. Какви фактори влияят върху избора на система за контрол на версиите?

Николай Фетюхин,MST
Поддръжка на ядрото на системата за контрол на версиите и специфичната му реализация, запознаване на екипа с нея. Най-често се използва една система за всички проекти. Изключения могат да бъдат например изискванията на клиента.

Иван Немитченко, GitLab
Популярността на определена система, от която следва всичко останало: поддръжка на приложения и услуги, количество и качество на документацията, наличие на експерт „наблизо“ и др.

Александър Макарчук, qb
В нашия случай изборът се основава на популярността на системата за контрол на версиите и нивото на владеене на разработчиците с нея.

Петър Урваев, SimbirSoft
На първо място, възможностите на системата за контрол на версиите съответстват на процеса на разработка, възприет от екипа. Второ, с каква система за контрол на версиите работят по-често участниците в проекта?

3. Как да внедрите използването на контрол на версиите в екип?

Николай Фетюхин,MST
В наши дни дори съвременните студенти завършват с общо разбиране защо са необходими системи за контрол на версиите, така че въпросът за внедряването не е напълно правилен. Обикновено всички проекти просто започват със създаване на хранилище по подразбиране. Ако в общия случай, тогава трябва да говорите с екипа, да разберете защо няма система за контрол на версиите в проекта (понякога има различни много специфични случаи) и ако проблемите могат да бъдат преодолени, след това проведете няколко семинара в рамките на екипа на конкретна система за контрол на версиите (ако е необходимо) и стартирайте.

Иван Немитченко, GitLab
Дайте им възможност да работят без система за контрол на версиите, така че да почувстват цялата болка. След това им „пуснете“ Git cheatsheet и те ще научат и внедрят всичко сами. Но така може да се работи с ученици и студенти. Зрелите разработчици обикновено нямат този въпрос.

Александър Макарчук, qb
Бавно, но сигурно всеки стига до това сам.

Петър Урваев, SimbirSoft
В мнозинството модерни проектинеобходимостта от използване на система за контрол на версиите не повдига никакви въпроси. Когато се научите да работите с него, достатъчно е да го конфигурирате да удобна работаи прочетете кратка лекция за основните възможности на използваната система за контрол на версиите, давайки примери за използване.

4. Какво направи Git стандарт в света на системите за контрол на версиите? Ще успее ли някой да го измести от ръководния му пост?

Николай Фетюхин,MST
Git първоначално въведе някои полезни неща, като локални ангажименти, а също така реши много проблеми със сливането на клонове, които измъчваха предишния създател на тенденциите, Subversion (SVN). От самото начало се бори за популярност с Mercurial (Hg), който е по-опростен в някои аспекти, но в крайна сметка поведе.

Иван Немитченко, GitLab
Благодарение на факта, че Линус Торвалдс атакува проблема с разпределената разработка от дясната страна, като вземе предвид недостатъците на предшестващите системи. Ход? За какво?

Александър Макарчук, qb
Благодарение на факта, че Git е страхотен. Никой няма да го измести за много дълго време.

Петър Урваев, SimbirSoft
Основното предимство на Git е разработването на инструменти за работа с него и възможността в него да се съхраняват резултатите от работата по няколко паралелно отворени задачи, така че междинните резултати да не си влияят един на друг, а в същото време крайните резултати да могат да се комбинират доста лесно в една окончателна версия на приложението. Също така, важна роля за универсалната популярност на Git в света на CVS изигра ресурсът GitHub, който хоства хиляди хранилища на различни езици.

5. Какво не харесват разработчиците в Git? Защо някои хора избират други по-малко популярни решения?

Николай Фетюхин,MST
Единственият значителен недостатък на Git за нас са някои проблеми с проследяването на промените: разклоненията могат да бъдат изтрити и може да остане само ангажимент за сливане. Това до голяма степен се дължи на факта, че Git има клонове, прикачени към ангажименти. Git също има по-стръмна крива на обучение от гореспоменатите Mercurial или Subversion.

Александър Макарчук, qb
В рамките на нашите задачи всички са доволни.

Петър Урваев, SimbirSoft
Git е доста удобен, но изисква обучение (за тези, които още не го знаят) и активни стъпки за преминаване към него, така че някои екипи предпочитат да останат със системите за контрол на версиите, които използват. Също така, изборът на система за контрол на версиите може да се определи от използваните инструменти за разработка.

6. Колко често се използват системи за контрол на версиите за управление на файлове, различни от код?

Николай Фетюхин,MST
В момента навсякъде. Същите облачни системи като One Drive, Yandex.Disk, Dropbox и Google Drive се основават на идеология, която копира системи за контрол на версиите.

На практика използването на конвенционални системи за контрол на версиите за съхраняване на документи е обичайно, но не твърде често; възникват тънкости при изчисляването на промените, тъй като повечето от днешните често срещани формати на документи са двоични и техните набори от промени не са четими от хора.

Александър Макарчук, qb
Постоянно използван.

Петър Урваев, SimbirSoft
Системите за контрол на версиите са насочени предимно към работа с голям брой малки файлове, което се използва главно в разработката. Използване подобни системиза файлове с нетекстови формати (двоични) като правило е неефективно, а в някои случаи е напълно невъзможно. Следователно, за съхраняване на други файлове обикновено се използват специализирани системи, адаптирани за работа с определени формати на данни.