Привіт Хабр. Вирішив торкнутися змученої у багатьох статтях теми, конкретніше – описати багато в чому нестандартне (я б сказав, несорцеве) використання систем контролю версій (далі – ВКВ). Товариші програмісти, давайте сховаємо тухлі помідори і пройдемо повз, бо ця стаття – не для вас. Так, ви вже вивчили всі тонкощі роботи Git, SVN, CVS і знаєте багато інших розумних слів. Дозвольте ж і нам, простим смертним, ознайомитися з усіма перевагами використання ВКВ.
Запрошую під кат всіх охочих ознайомитися з ВКВ, а також усіх тих, хто, так чи інакше, має справу з швидкозмінними даними.

Навіщо це потрібно

Сам я є студентом технічного інституту і завжди працюю з документами (текстами, малюнками, кресленнями), змінюючи їх по три (десять, сто) разів на день. Іноді виходить так, що правки, зроблені протягом останнього тижня, необхідно скасувати та повернутися до документів у стані тижневої давності. Добре, якщо правок було зроблено небагато, у цьому випадку можуть допомогти півсотні ударів по Ctrl+Z. Однак якщо протягом цього тижня тривала більш-менш активна робота з документом, просто так відновити статус «до важливої ​​виправлення, зробленого тиждень тому» не вийде. Для цього необхідна копія документа на момент «до важливої ​​редагування», а також ще десяток копій «до іншої важливої ​​редагування», «до сумнівної редагування» і «до редагування, яку, швидше за все, доведеться скасувати». У принципі такий підхід можливий і практикується багатьма. Донедавна я й сам тримав важливі версіїфайлів, зберігаючи їх із префіксами «дата_час», і, начебто, був задоволений. Перевагою цього є простота, недоліком – «розбухання» робочих папок і незручність використання. І, якщо з першим із них можна якось боротися (великими жорсткими дисками та 7zip'ом), то із незручністю щось треба було робити.

Що з цим можна зробити, або що таке ВКВ

Вириваємо абзац з Вікіпедії: «Система управління версіями (від англ. Version Control System, VCS або Revision Control System) – програмне забезпечення для полегшення роботи з інформацією, що змінюється. Система керування версіями дозволяє зберігати кілька версій одного і того ж документа, при необхідності повертатися до більш раннім версіям, визначати, хто і коли зробив ту чи іншу зміну та багато іншого». Схоже на принцип роботи самої Вікіпедії – всі версії статей з усіма редагуваннями доступні для вивчення.
Таким чином, використання ВКВ у ситуації, коли потрібно зберігати безліч версій файлів – те, що треба. До переваг такого підходу відносяться зручність використання та економія вільного дискового просторузавдяки так званому дельта-стиску (коли зберігаються не самі файли в різних версіях, а зміни від версії до версії, що зменшує обсяг даних, що зберігаються). Давайте спробуєм.

Які бувають ВКВ

Та ж Вікіпедія підказує, що ВКВ бувають централізовані та розподілені, великі та маленькі, з примочками та без. Нас це не особливо цікавить, тому що ми будемо користуватися (по Крайній мірі, спочатку) лише частиною функціоналу ВКВ. Цей самий функціонал і розглянемо.
Практично всі ВКВ є деяким сховищем, у якому зберігаються всі версії файлів, з якими ми працюємо. Тут необхідно уточнити, що версії файлів, що зберігаються, найчастіше визначає користувач. Внесли ми, припустимо, з десяток дрібних правок і вирішили, що час зберегти результати нашої діяльності в сховищі. На думку спадає аналогія з періодичним натисканням Ctrl+S, з тим лише відмінністю, що до цієї версії файлу можна буде звертатися у майбутньому. Природно, що «одним махом» таким чином можна занести в сховище версії скільки завгодно великої кількості файлів. Називається ця дія "commit", або "фіксація змін" по-простому.
Будь-якої миті в репозиторій (а саме так по-розумному називається сховище) можна додати новий або видалити існуючий файл, і ВКВ буде «пам'ятати» коли і що ми додали/видали. А завдяки коментарям при commit'ах можна ще й описати для чого саме цей commit виконується («додали фенечку туди-то»/«видали можливо потрібний шматок звідти»).
Коли ж ми, нарешті, розуміємо, що час нам повернутися до версії тижневої давності, у нас є вся історія змін. І тут ми можемо вибирати, як вчинити. Якщо потрібно скопіювати зі старого файлу потрібний шматочок і вставити в поточну версію - просто виймаємо зі сховища старий файл і копіюємо з нього потрібне. Якщо ж необхідно повністю відкотитися назад і продовжити роботу з старою версієюнам на допомогу знову приходить ВКВ – можна повернутися до ранньої версії і створити так звану нову гілку (branch), зберігши при цьому все, від чого ми відмовилися, відкотившись у версіях на тиждень тому. Таким чином, історію версій проекту графічно можна представити у вигляді дерева – від «коріння» (початку проекту) до «гілок» (вдалих та невдалих правок). Крім того, «гілку» можна створити і штучно, наприклад, у тому випадку, коли з одних вихідних файлів ми вирішимо розвинути дві різні версії– у першій працюємо над одними фенечками, у другій – над іншими. Більше того, у випадку, якщо робочі файли є текстові документи(і в деяких інших), можливе поєднання різних гілок в одну - так зване злиття (merge). Тепер уявімо, що над проектом працюють кілька людей, і кожен займається своєю такою «фенечкою». Наявність загального репозиторію у разі сильно спрощує розробку.

Від теорії до практики, або починаємо використовувати ВКВ

Отже, сподіваюся, я переконав вас у тому, що використання ВКВ – це добре. Залишилося лише навчитися використовувати ВКВ. Цим і займемося.
Існують різні системи контролю версій, що відрізняються одна від одної різними аспектамивикористання. Так як нас не цікавлять (принаймні спочатку) тонкощі роботи різних систем, зупинимося на найпростішій та найдружнішій з них. На мою скромну думку, такою системою, як не дивно, є Mercurial – «кросплатформна розподілена система управління версіями, розроблена для ефективної роботиз дуже великими репозиторіями коду з графічною оболонкою TortoiseHg. Робота з системою можлива під Windows, Linux та Mac OS X.
Відразу зазначу, що описуватиму роботу з системою в Windows. Освоївшим Linux не важко буде вивчити все за аналогією.
Крім того, паралельно навчимося працювати з безкоштовним хостингом Mercurial репозиторіїв – bitbucket.org, необхідним у випадку, якщо ви працюєте над проектом не одні або, що дуже зручно, хочете мати доступ до всіх версій проекту через інтернет. По суті це зручна заміна Dropbox, якщо ви використовували його раніше.
Для початку встановлюємо Mercurial+TortoiseHg звідси: tortoisehg.bitbucket.org.
Ця система працює в консолі, тому для зручності використання пізніше напишемо кілька *. bat файлів для типових операцій.
Усі операції виконуються командою hg. Викликаний без параметрів, вона виводить список основних команд.
Як репозиторій виступає будь-яка обрана нами директорія (я використовуватиму папку “C:project”), в якій і повинні зберігатися всі файли нашого майбутнього проекту. Зрозуміло, ніхто не забороняє мати кілька репозиторіїв на одному комп'ютері.
Щоб система зрозуміла, що ми хочемо створити репозиторій, виконуємо команду:
hg init c:\project
після якої буде створено папку "c:\project\", якщо вона не була створена раніше і папка "c:\project\.hg\", в якій Mercurial зберігатиме всю службову інформацію.
Тут же згадуємо, що хочемо отримати не лише локальний репозиторій на своєму комп'ютері, а й віддалений репозиторій, в який будемо відправляти всі наші зміни (або, як кажуть розумники, «пушити» зміни у віддалений репозиторій, від англ. «push»). Для цього йдемо на bitbucket.org, реєструємось, і створюємо свій перший репозиторій (Repositories – Create new repository). Даємо репозиторію ім'я (я для визначеності назву його remote_project) і тиснемо на Create repository.
Тепер у нас є два репозиторія - локальний, що знаходиться в папці "c:\project\" і віддалений, розташований за адресою "bitbucket.org/ім'я_вашої_обліки/remote_project/", де ім'я_вашої_обліки - вказане при реєстрації на bitbucket, remote_project - ім'я репозиторія обране під час його створення.
Для того, щоб продовжити вивчення, нам необхідно помістити щось у наш локальний репозиторій. Просто створіть у ньому (у моєму випадку – у папці “c:\project”) будь-який файл вашого майбутнього проекту або скопіюйте туди ваш поточний проект.
Тепер, строго кажучи, нам необхідно вказати Mercurial: «ми додали в папку проекту такий і такий файли і пару нових папок», для цього передбачена команда "hg add". Однак, більш зручний інший підхід – при черговому commit'і ми накажемо Mercurial підхопити всі свіжостворені файли з папки проекту та забути про видалені, це набагато легше, ніж кожного разу при створенні нового документа виконувати “hg add c:\project\new_document.doc ”.
Отже, приступаємо до нашого першого commit'у. Виконується він наступною командою:
hg commit –A –m “comment to commit”
Розберемо все по порядку. Команда повинна вводитися тоді, коли ми перебуваємо у репозиторії (тобто попередньо необхідно виконати “cd c:\project”). Опція "-A" необхідна для того, щоб Mercurial "підхопив" свіжостворені файли (див. вище), опція "-m" дозволяє додати до commit'у коментар. Ці коментарі будуть відображатися під час перегляду версій (або changeset'ів – списків змін) у TortoiseHg та на сторінці проекту у bitbucket.org. Дуже важливо давати осмислені коментарі, щоб потім не мучитися, згадуючи, коли ж було зроблено ту чи іншу правку.
Тепер у нашому репозиторії зберігається початкова версія нашого проекту. Всі подальші commit'и виконуються аналогічно після того, як ми вирішимо, що час зберегти поточну версію.
Зроблений commit можна "вштовхнути" у віддалений репозиторій командою:
hg push https://bitbucket.org/ім'я_вашої_обліки/remote_project
При цьому необхідно перебувати в папці, що відповідає репозиторію. Після введення команди буде запрошено ім'я та пароль нашого облікового запису на bitbucket.org, щоб не вводити їх при кожному push'і команду можна замінити на наступну:
hg push hg push https://ім'я_вашої_обліки:пароль_вашої_обліки@bitbucket.org/ім'я_вашої_обліки/remote_project
Так як всі команди ми заб'ємо в файл *.bat, в цьому випадку пароль буде зберігатися в відкритому вигляді, що є деякою загрозою безпеці, проте для мене це прийнятно.
Отже, для зручності створюємо в зоні прямої досяжності файли commit.bat, push.bat та commit&push.bat з таким змістом:
[Зміст файлу commit.bat]
IF !%1==! goto exit1
cd C:\project
hg commit -A -m "%*"
goto exit0
:exit1
echo "NO COMMAND-LINE ARG!"
:exit0
Цей файл, викликаний з аргументами, виконає commit проекту із занесенням аргументів у коментарі до commit'у. Приклад: виконуємо “commit.bat my first commit” та отримуємо commit із коментарем “my first commit”. У FAR'і для цього зручно використовувати поєднання Ctrl+Enter.
[Зміст файлу push.bat]
cd C:\project
hg push https://ім'я_вашої_обліки:пароль_вашої_обліки@bitbucket.org/ім'я_вашої_обліки/remote_project
Цей файл здійснить push у віддалений репозиторій.
[Зміст файлу commit&push.bat]
IF !%1==! goto exit1
cd C:\project
hg commit -A -m "%*"
goto exit0
:exit1
echo "NO COMMAND-LINE ARG!"
:exit0
call./push.bat
Цей файл, викликаний з аргументами, виконає послідовний commit та push проекту із занесенням аргументів у коментарі до commit'у.
Крім того, для дрібних проміжних commit'ів я рекомендую створити файл commit_date_time.bat:
[Зміст файлу commit_date_time.bat]
cd C:\project
hg commit -A -m "%DATE% %TIME%"
Цей файл зробить commit із зазначенням поточної дати та часу як коментар, що часто буває зручно.
Питання про частоту commit'ів і push'ів кожен вирішує в індивідуальному порядку залежно від інтенсивності та складності внесених правок. Хоча й рекомендується керуватися правилом «частіше – краще».
Правим кліком на файлі/папці репозиторію можна запустити Repository Explorer (TortoiseHg - Repository Explorer), де представлені всі наші commit'и з коментарями до них. У цьому вікні відображається деревоподібна структура нашого репозиторію, звідси ж можна проводити commit'и, push'и, відкати до попередніх версій (backout'и) та інші операції.
За адресою bitbucket.org/ім'я_вашої_обліки/remote_project знаходиться аналогічний набір changeset'ів, при цьому можна завантажити будь-яку версію проекту одним архівом, що іноді також дуже зручно.
Загалом початкове знайомство з Mercurial на цьому вважаю закінченим. За більш детальною інформацієюможна звернутися за адресою: translated.by/you/mercurial-the-definitive-guide/into-ru/trans/

Для кого ця стаття

Закінчу, мабуть, тим, з чого було б почати – для кого ця стаття? Відповідь проста – для тих, хто хоче навчитися використовувати ВКВ. Мені вдалося «підсадити» на ВКВ кількох дизайнерів, інженерів і навіть письменника. Спробуйте і ви – цим ви, можливо, сильно полегшите роботу.

PS Переніс у блог «Системи управління версіями».

Теги: Додати теги

Система контролю версій ( Version Control System, VCS) являє собою програмне забезпечення, яке дозволяє відстежувати зміни в документах, при необхідності проводити їх відкат, визначати, хто і коли вніс виправлення тощо. У статті розглянуто види VCS, принципи їх роботи, а також наведено приклади програмних продуктів.

Що таке система контролю версії?

Напевно, всім знайома ситуація, коли при роботі над проектом виникає необхідність внести зміни, але при цьому потрібно зберегти працездатний варіант, у такому випадку, як правило, створюється нова папка, назва якої швидше за все буде "Нова папка" з доповненням у вигляді дати або невеликий позначки, у неї копіюється робоча версіяпроекту та вже з ним проводиться робота. Згодом кількість таких папок може значно зрости, що створює труднощі щодо відкату на попередні версії, відстеження змін тощо. Ця ситуація значно погіршується, коли над проектом працює кілька людей.

Для вирішення таких проблем використовується система контролю версій, вона дозволяє комфортно працювати над проектом як індивідуально, так і в колективі. VCSвідстежує зміни у файлах, надає можливості для створення нових та злиття існуючих гілок проекту, здійснює контроль доступу користувачів до проекту, дозволяє відкочувати виправлення та визначати хто, коли та які зміни вносив до проекту. Основним поняттям VCSє репозиторій ( repository) – спеціальне сховище файлів та папок проекту, зміни в яких відстежуються. У розпорядженні розробника є так звана робоча копія ( working copy) проекту, з якою він безпосередньо працює. Робочу копію необхідно періодично синхронізувати з репозиторієм, ця операція передбачає відправку до нього змін, які користувач вніс до своєї робочої копії (така операція називається commit) та актуалізацію робочої копії, в процесі якої до користувача завантажується остання версія з репозиторію (цей процес носить назву update).

Централізовані та розподілені системи контролю версій

Системи контролю версій можна розділити на дві групи: розподілені та централізовані.

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

ЦентралізованіСистеми контролю версій являють собою програми типу клієнт-сервер, коли репозиторій проекту існує в єдиному екземплярі і зберігається на сервері. Доступ до нього здійснювався через спеціальний клієнтський додаток.Як приклади таких програмних продуктів можна навести CVS, Subversion.

CVS (Concurrent Versions System, Система одночасних версій) одна з перших систем, що набули широкого поширення серед розробників, вона виникла в кінці 80-х років минулого століття. В даний час цей продукт не розвивається, це в першу чергу пов'язано з низкою ключових недоліків, таких як неможливість перейменування файлів, неефективне їх зберігання, практично повна відсутністьконтролю цілісності

Subversion (SVN) – система контролю версій, створена на заміну CVS. SVNбула розроблена в 2004 році і досі використовується. Незважаючи на багато переваг у порівнянні з CVSу SVNтаки є недоліки, такі як проблеми з перейменуванням, неможливість видалення даних зі сховища, проблеми в операції злиття гілок і т.д. В цілому SVNбув (і залишається) значним кроком уперед порівняно з CVS.

Розподілені системи контролю версій

Розподілені системи контролю версій ( Distributed Version Control System, DVCS) дозволяють зберігати репозиторій (його копію) кожного розробника, працюючого з цією системою. При цьому можна виділити центральний репозиторій (умовно), до якого будуть відправлятися зміни з локальних і, з ним ці локальні репозиторії будуть синхронізуватися. При роботі з такою системою користувачі періодично синхронізують свої локальні репозиторії з центральним і працюють безпосередньо зі своєю локальною копією. Після внесення достатньої кількості змін до локальної копії вони (зміни) надсилаються на сервер. У цьому сервер, найчастіше, вибирається умовно, т.к. у більшості DVCSнемає такого поняття як “виділений сервер із центральним репозиторієм”.

Велика перевага такого підходу полягає в автономії розробника при роботі над проектом, гнучкості загальної системита підвищення надійності завдяки тому, що кожен розробник має локальну копію центрального репозиторію. Дві найбільш відомі DVCS– це Gitі Mercurial.

Почнемо з Mercurial, ця система являє собою вільну DVCS, яка побудована таким чином, що в ній немає поняття центрального репозиторію, для роботи з цією VCSвикористовується (як правило) консольна утиліта hg. Mercurialмає всі можливості системи контролю версій, такими як розгалуження, злиття, синхронізація з іншими репозиторіями. Даний проектвикористовують та підтримують велика кількістьвеликих розробників, серед них Mozilla, OpenOffice, OpenJDKі багато інших. Сам продукт написаний мовою Pythonі доступний на більшості сучасних операційних систем (Windows, Mac OS, Linux), також існує значна кількість утиліт з графічним інтерфейсомдля роботи з Mercurial. Основним конкурентом Mercurialна ринку розподілених систем контролю версій є Git, який, на сьогоднішній день, виграв гонку за лідерство

Git– розподілена система контролю версій, розроблена Лінусом Торвальдсем для роботи над ядром операційної системи Linux. Серед великих проектів, у межах яких використовується git, можна виділити ядро Linux, Qt, Android. Gitвільний та поширюється під ліцензією GNU GPL 2 і, також як Mercurial, доступний практично всіх операційних системах. За своїм базовим можливостям gitсхожий Mercurial(та іншими DVCS), але завдяки ряду переваг ( висока швидкістьроботи, можливість інтеграції з іншими VCS, зручний інтерфейс) і дуже активній спільноті, що сформувалася навколо цієї системи, gitвийшов у лідери ринку розподілених систем контролю версій.Попри велику популярність таких систем як git, великі корпорації, подібні Google, використовують свої VCS.

Це була вступна лекція з систем контролю версій. Надалі, весь виклад стосуватиметься лише git.

Якщо вам більше подобається вчитися з відео-лекцій, то рекомендуємо класний курс з gitвід GeekBrains , перейдіть по засланніта знайдіть у розділі “Курси” курс “Git. Швидкий старт". Він безкоштовний, потрібно лише зареєструватися на сайті. Рекомендуємо уважніше подивитися на цей ресурс, на ньому ще багато чого цікавого!

У вас з'явилася нова чудова бізнес-ідея, пов'язана з розробкою?Чи потрібно розробити технологічно складне рішення? Чи маєте велику команду програмістів, які працюють над одним завданням? Тоді запам'ятайте ці три слова:система контролю версій .

Система контролю версій (cvs), 2017 - Порівнюємо: Git, SVN, Mercurial

, або vcs- це те, що не дасть проекту розвалитися на шматки, коли над ним працює багато людей. Програмісти, менеджери, копірайтери можуть працювати кожен над своїм шматочком, не заважаючи один одному і не завдаючи шкоди, яку неможливо було б виправити.

Якщо ви ще не знайомі з концепцієюсистеми контролю версій, то ось все дуже наочно показано.

Або подивіться відео від GitHub.

Яка система контролю версій підійде для вашого проекту?

Ми порівняли кілька популярних рішень, щоб вам було простіше зробити вибір.

Це вузькоспеціальна технічна тема. Ми постаралися зробити наш огляд зрозумілим всім. Але якщо у вас немає досвіду у програмуванні, обов'язково порадьтеся з вашим відділом розробки, перш ніж приймати рішення.

Системи контролю версій, у тому числі широко відомі SVN (Subversion) і Git, спочатку створювалися, щоб команди розробників могли працювати над спільними проектами, не створюючи плутанини. У системі контролю не треба самостійно відстежувати гілки коду та вивчати примітки до них. Натомість використовується центральний репозиторій, де все впорядковано, структуровано. Тут зручно оновлювати файли, додавати коментарі та навіть проводити злиття гілок проекту.

Думки щодо того, якасистема контролю версійнайкраща, сильно різняться, і це призводить до бурхливим суперечкамсеред програмістів. Підбираючи та вивчаючисистеми контролю версійдля вашого проекту, не забувайте, що переваги того чи іншого рішення часто є суб'єктивними. Наприклад, особисті переваги програміста чи, скажімо, такі показники як швидкодія, можливості плагінів IDE тощо.

Головна відмінність між системами контролю версій у тому, які вони: клиент-серверные чи децентралізовані (p2p). Чи є у них центральний репозиторій (сервер), звідки код береться і куди повертається з внесеними змінами. Або це копія в локальному сховищі, оновлювана за допомогою бенкетів. децентралізована мережа, що використовується для синхронізації, обміну патчами (наборами змін) та підтримки поточного коду.

Варто також врахувати швидкодію, функціональність та поріг входження/освоєння конкретноїсистеми контролю. Розглянемо найпоширенішісистеми контролю версійі ті причини, через які програмісти воліють ті чи інші рішення.

Система одночасних версій (CVS)

CVS з'явилася в 1980-х і досі популярна як розробники комерційних продуктів, так і open-source розробники.

CVS поширюється на умовахВідкрита ліцензійна угода GNU і дозволяє отримувати з сервера потрібну версіюпроекту - «check-out» (витяг) , а потім пересилати назад на сервер,check-in» (повернення),із внесеними змінами.

Спочатку CVS була створена, щоб уникнути конфлікту версій. Всім учасникам для роботи надавалася лише остання версія коду. То була перша система контролю версій. Користувачеві потрібно було швидко фіксувати зміни у репозиторії, доки інші не випередили його.

Зараз CVS має підтримку роботи над проектами із гілками коду. Виходить кілька варіантів продукту з різними характеристиками, які можна буде поєднати пізніше.

Сервера CVS зазвичай працюють під керуванням Unix, але CVS -Клієнти доступні і в інших популярних операційних системах. CVS - «зріла», перевірена часомсистема контролю версій. Це, як і раніше, опенсорсна система, але на сьогоднішній день нові функції додаються досить рідко.

При цьому CVSNT, - версія, що виділилася в окремий проект, CVS для серверів Windows, - зараз досить активно розширює функціонал.

Переваги:

• Випробувана часом технологія, що утримується на ринку десятки років.

Недоліки:

• Перейменування або переміщення файлів не відображається в історії
• Ризики безпеки, пов'язані із символічними посиланнями на файли
• Немає підтримки атомарних операцій, що може призвести до пошкодження коду
• Операції з гілками програмного кодудорогі, оскільки цясистема контролюне призначена для довгострокових проектів з гілками коду

Apache Subversion (SVN)

SVN створювалася як альтернатива CVS з метою виправити недоліки CVS і водночас забезпечити високу сумісність із нею.

Як і CVS , SVN це безкоштовна системаконтролю версій з відкритим кодом. З тією різницею, що поширюється під ліцензією Apache, а не підвідкритим ліцензійною угодою GNU.

Для збереження цілісності бази даних SVN використовує звані атомарні операції. З появою нової версії до фінального продукту застосовують або всі виправлення, або жодне з них. Таким чином код захищають від хаотичних часткових правок, які не узгоджуються між собою і викликають помилки.

Багато розробників перейшли наSVN, оскільки нова технологіяуспадкувала найкращі можливості CVS і водночас розширила їх.

У той час як у CVS Операції з гілками коду дорогі і не передбачені архітектурою системи, SVN створена саме для цього. Тобто, для більших проектів із розгалуженням коду та багатьма напрямками розробки.

Як недоліки SVN згадуються порівняно низька швидкістьі нестача розподіленого управлінняверсіями. Розподіленийконтроль версій використовує пірингову модель, а не централізований сервер для зберігання оновлень програмного коду. І хоча пірінгова модель працює краще в open source проектах, вона не є ідеальною в інших випадках. Недолік серверного підходу в тому, що коли сервер падає, то клієнти не мають доступу до коду.

Переваги:

• Система на основі CVS
• Допускає атомарні операції
• Операції з розгалуженням коду менш затратні
• Широкий вибір плагінів IDE
• Не використовує пірингову модель

Недоліки:

• Досі зберігаються помилки, пов'язані з перейменуванням файлів та директорій
• Незадовільний набір команд для роботи з репозиторієм
• Порівняно невелика швидкість

Git

Ця система була створена для управління розробкою ядра Linuxі використовує підхід, який докорінно відрізняється від CVS і SVN.

В основу Git закладалися концепції, покликані створити швидшу розподіленусистему контролю версій, на противагу правилам і рішенням, використаним у CVS . Так як Git розроблялася головним чином під Linux, то саме в цій ОС вона найшвидше працює.

Git також працює на Unix-подібних системах (як MacOS), а для роботи на платформі Windowsвикористовується пакет mSysGit.

Програмний код може бути недоступним, коли комп'ютер використовується без репозиторію. Для вирішення цієї проблеми є обхідні шляхи і деякі розробники вважають, що швидкодія Git є справедливою платою за незручності.

Крім того, у Git є безліч інструментів для навігації з історії змін. Кожна робоча копія вихідного коду містить історію розробки, що вкрай корисно, коли програмуєш без Інтернет-з'єднання.

Переваги:

• Чудово підходить для тих, хто ненавидить CVS/SVN
• Значне збільшення швидкодії
• Дешеві операції з гілками коду
• Повна історія розробки доступна офлайн
• Розподілена, пірингова модель

Недоліки:

• Високий поріг входження для тих, хто раніше використовував SVN
• Обмежена підтримка Windows(В порівнянні з Linux)

Mercurial

Mercurial була випущена одночасно з Git. це такожрозподілена система контролю версій.

Mercurial створювалася як альтернатива Git для розробки модулів ядра Linux. Але оскільки обрали все-таки Git, то Mercurial використовується менше. Тим не менш, багато провідних розробників працюють саме з цією системою, наприкладOpenOffice.org .

Система контролю версій Mercurial відрізняється від іншихсистем контролю версійтим, що вона в основному написана на Python (а не С). Однак деякі частини виконані в якості модулів-розширень на C.

Оскільки система децентралізована та написана на Python, багато Python-програмістів схиляються до переходу на Mercurial.

Користувачі зазначають, що Mercurial зберегла деякі характеристики SVN, будучи при цьому розподіленою системою, і завдяки цій схожості, поріг входження в неї нижче тих, хто вже знайомий з SVN. Також документація по Mercurial повніша, що допомагає швидше освоїтися з відмінностями.

Один з істотних недоліків Mercurial полягає в тому, що на відміну від Git в ній не можна поєднати дві батьківські гілки, оскільки Mercurial використовує систему плагінів, а не підтримку скриптів. Це відмінно підходить для деяких програмістів, але багато хто не хоче відмовлятися від можливостей Git.

Переваги:

• У порівнянні з Git легше в освоєнні
• Детальна документація
• Розподілена модельсистеми контролю версій

Недоліки:

• Немає можливості злиття двох батьківських гілок
• Використання плагінів, а не скриптів
• Менше можливостей для нестандартних рішень

Якасистема контролю версій мені підходить?

У більшості випадків розробники використовують CVS тому що це їм звичніше. Якщо команда вже працює над проектом, то перспектива перенесення всіх напрацювань до іншоїсистему контролюякось не надихає. Якби їм таки довелося змінювати систему, то, швидше за все, вони перейшли б на SVN.

CVS вже досягла статусу "зрілої технології", а це означає, що в ній вже не з'явиться радикально нових функцій та рішень. Інерція звички губиться, оскільки люди переходять на SVN. А отже CVS поступово відходить у минуле.

Сьогодні SVN утримує пальму першості серед сервернихсистем контролю версій. Вона включає переваги CVS і перевершує їх. Якщо ж говорити про поширеність, то ви, швидше за все, частіше стикатиметеся з CVS або SVN, ніж з Git або Mercurial. Таким чином, знання однієї серверної технології, хоч і не є необхідним, полегшить вам перехід.

Завдяки широкому використанню та зрілості технології, у SVN накопичена велика базазнання, що дає користувачам можливість легко отримувати допомогу.

У Git явно вища швидкодія порівняно з конкурентами. Для проектів, що створюються під розподіленісистеми контролю версій, це очевидне покращення.

Істотним недоліком Git є те, що часом важко пояснити нюанси роботи даноїсистеми контролюі це гальмує робочий процес, поки програмісти звикають до неї. Однак, як тільки «поріг входження» подолано, продуктивність зростає і зручність управління гілками коду сповна окупить витрачений час.

Для тих, хто терпіти не може Git (а ця система має своїх противників у середовищі розробників), Mercurial - це компроміс між SVN і Git. Ця система використовується в багатьох відомих проектах, а також має хорошу документацію.

Сумісна з Windows версія Git також прогресує, наближаючись за своєю швидкодією до Linux-версії, так що ця система може бути вам актуальна, навіть якщо ви не ведете розробку в Linux.

Щоб зрозуміти, яка краще для вас, враховуйте особливості проекту та вашої команди. Поговоріть із розробниками!

Якщо для проекту потрібно єдине дерево вихідного коду, над яким працюватиме невелика група програмістів, то SVN – це ваш варіант. Вона надійна і призначена саме для таких випадків.

Якщо ж ви запускаєте open-source проект, над яким у різний часбудуть працювати кілька програмістів або, якщо передбачається постійне оновленнякоду, то вибирайте Git. Швидкість та керування деревом вихідного коду тут набагато краще, ніж у SVN.

Якщо ви на роздоріжжі або вам просто не подобається, як працюють SVN або Git, тоді до ваших послуг Mercurial.

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

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

Приступаючи до роботи з SVN

Якщо ви ніколи не працювали з SVN або Git, і гадки не маєте, як почати, тохостингове рішення у поєднанні з графічним інтерфейсомдопоможуть вам швидко освоїтися.

Як і здебільшого, найголовніше – розпочати роботу, а там уже прийде розуміння. Експлуатація системи контролю версій дуже схожа працювати з файлами на сервері з використанням FTP-клієнта.

ПРИМІТКА:Є безліч хостингових рішень длясистеми контролю версій, у тому числі з безкоштовним пробним періодом. Ви можете створити на їх базі свій перший репозиторій. спільної праціз файлами коду) абсолютно безкоштовно. Ось деякі з цих сервісів:

Хостинг SVN & GIT

Створення першого репозиторію

Після того як ви створили обліковий запис, необхідно створити репозиторій - для кожної платформи окремо. Зазвичай це виглядає так:

• Увійдіть до свого облікового запису, клікніть за вашими проектами.
• Створення проекту:

• У рядку "Create a New Project" введіть ім'я вашого проекту
• Клацніть на кнопку «Create Project»

• Підключення SVN:

• Після створення проекту виберіть вкладку «Source Control» (версіями вихідного коду)
• Клацніть на посилання «Enable Source Control»
• Надайте репозиторію ім'я
• Натисніть Save

Графічні клієнти SVN та GIT

Отже, репозиторій створено. Тепер потрібно, щоб у ньому все відображалося просто та наочно. Для цього вам знадобиться графічний інтерфейс.

— зручна програмадля роботи зсистемами контролю версійMicrosoft Windows і, можливо, найкращий з представлених Apache Subversion клієнт. TortoiseSVN реалізований як розширення оболонки Windowsщо дозволяє легко інтегрувати його вбраузер. Крім того, це програма з відкритим вихідним кодом, для якої доступні 34 мовні пакети

SmartGit

– графічний клієнт Git ( Open Sourceрозподіленасистема контролю версій). Працює у Windows, Mac OS X та Linux.Вартість ліцензії - $39

«Витяг» репозиторію ("Checkout")

Отже, клієнта обрано. Тепер необхідно створити репозиторій системи контролю. Потрібно ввестиURL-адреса вашого репозиторію, ім'я користувача та пароль.

URL-адреса зазвичай виглядає так:https://svn .hostname.com/svn/ > (ви можете використовувати https:// (SSL), якщо у вас платний аккаунт)

1. Перейдіть до кореневу папку, натисніть кнопку «Check Out» («Витяг») і створіть робочу папкудля клієнтів. Тепер ви можете додавати до неї файли.
2. Після вилучення файлів проекту ви зможете редагувати їх у локальній директорії на вашому комп'ютері.

Після внесення змін до файлів для їх збереження натисніть кнопку Check-in (Повернення) на панелі інструментів. Ви можете переглядати зміни та додавати до них коментарі - це досить хороша ідея, оскільки надалі ви точно знатимете, над чим працювали, які зміни внесені і триматимете в курсі інших учасників проекту.

У вашому клієнті також має бути передбачена можливість у будь-який момент розпочати роботу з ревізіями, відкривши журнал ревізій чи історію змін – тоді, якщо знадобиться, ви зможете зробити «відкат» до попередньої версіїдля кожного файлу окремо. Тепер, коли ви знайомі з базовими концепціями, документація

RCS (Revision Control System, Система контролю ревізій) була розроблена на початку 1980-х років Вальтером Тичі (Walter F. Tichy). Система дозволяє зберігати версії лише одного файлу, таким чином управляти кількома файлами доводиться вручну. Для кожного файлу, що знаходиться під контролем системи, інформація про версії зберігається в спеціальному файлі з ім'ям оригінального файлу до якого в кінці додані символи "v". Наприклад, для файлу file.txt версії зберігатимуться у файлі file.txt,v . Для зберігання версій система використовує утиліту diff, тобто зберігаються лише зміни між версіями.

Розглянемо приклад сесії з RCS (символ $ тут і далі означає запрошення операційної системи). Коли ми хочемо покласти файл під контроль RCS, ми використовуємо команду ci (від check-in, реєструвати):

$ci file.txt

Ця команда створює файл file.txt,v і видаляє Вихідний файл file.txt (якщо не сказано цього не робити). Також ця команда запитує опис для всіх версій, що зберігаються. Оскільки вихідний файл був видалений системою, ми повинні запросити його назад, щоб вносити зміни. Для цього ми використовуємо команду co (від check-out, контролювати):

$co file.txt

Ця команда виймає останню версіюнашого файлу з file.txt, v. Тепер ми можемо відредагувати файл file.txt і після того як закінчимо зміни знову виконати команду ci для того, щоб зберегти нову змінену версію файлу:

$ci file.txt

При виконанні цієї команди система запросить у нас опис змін, а потім збереже нову версію файлу.

Хоча RCS відповідає мінімальним вимогамдо системи контролю версій вона має такі основні недоліки, які також послужили стимулом для створення наступної системи, що розглядається:

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

CVS

CVS (Concurrent Versions System, Система спільних версій) поки залишається найширше використовуваною системою, але швидко втрачає свою популярність через недоліки, які я розгляну нижче. Дік Ґрун (Dick Grune) розробив CVS у середині 1980-х. Для зберігання індивідуальних файлів CVS (також як і RCS) використовує файли в форматі RCS, але дозволяє керувати групами файлів розташованих у директоріях. Також CVS використовує клієнт-сервер архітектуру, в якій вся інформація про версії зберігається на сервері. Використання клієнт-сервер архітектури дозволяє використовувати CVS навіть географічно розподіленими командами користувачів, де кожен користувач має свій робочий директорій з копією проекту.

Як випливає з назви, користувачі можуть використовувати систему спільно. Можливі конфлікти при зміні одного і того ж файлу вирішуються тим, що система дозволяє вносити зміни лише до останньої версії файлу. Таким чином завжди рекомендується перед заливкою своїх змін оновлювати свою робочу копію файлів у разі можливих конфліктуючих змін. При оновленні система вносить зміни до робочої копії автоматично і лише у разі конфліктуючих змін в одному з місць файлу потрібне ручне виправлення місця конфлікту.

CVS також дозволяє вести кілька ліній розробки проекту за допомогою гілок (branches) розробки. Таким чином, як уже згадувалося вище, можна виправляти помилки у першій версії проекту та паралельно розробляти нову функціональність.

Розглянемо невеликий приклад сесії із CVS. Насамперед треба імпортувати проект у CVS, це робиться за допомогою команди import (імпортувати):

$ cd some-project $ cvs import -m "Новий проект" path-in-repository none start

Тут опція -m дозволяє задати опис змін прямо в командному рядку і якщо його опустити, то буде викликано текстовий редактор. Далі вказується шлях яким проект буде зберігатися в репозиторії (path-in-repository в нашому випадку) і після нього дві мітки: мітка розробника (може знадобиться у разі використання CVS для роботи над проектами розробленими кимось іншим) і мітка проекту.

Після того, як ми залили наш проект в репозиторій, необхідно створити новий директорій, в якому буде розташована робоча копія проекту під контролем CVS і завантажити проект за допомогою команди checkout (контроль), або скорочено co :

$ cd some-working-dir $ cvs checkout path-in-repository

Для команди checkout ми вказуємо шлях до нашого проекту у репозиторії котрий ми вказували вище у команді import .

Тепер ми можемо внести в проект зміни та залити їх у репозиторій за допомогою команди commit (здійснити зміни), або скорочено ci :

$ cvs commit -m "Some changes"

Так само як і для команди import ми вказуємо коментар до наших змін за допомогою опції -m.

Якщо ми хочемо оновити наш робочий директор новою версієюпроекту з репозиторію ми використовуємо команду update(оновити), або скорочено up :

$ cvs update

CVS використовувалася великою кількістюпроектів, але звичайно не була позбавлена ​​недоліків які пізніше призвели до появи наступної системи. Розглянемо основні недоліки:

• Оскільки версії зберігаються у файлах RCS, немає можливості зберігати версії директорій. Стандартний спосібобійти цю перешкоду - це зберегти якийсь файл (наприклад, README.txt) у директорії;
• Переміщення або перейменування файлів не піддається контролю версій. Стандартний спосіб зробити це: спочатку скопіювати файл, видалити старий за допомогою команди cvs remove і потім додати його новим ім'ям за допомогою команди cvs add ;

Subversion

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

• Атомарне внесення змін (commit). Якщо обробка комміту була перервана не буде внесено жодних змін.
• Перейменування, копіювання та переміщення файлів зберігає всю історію змін.
• Директорії, символічні посилання та мета-дані схильні до контролю версій.
• Ефективне збереження змін для бінарних файлів.

Розглянемо приклади команд, хоча слід зазначити, більшість з них практично повторюють команди CVS. Щоб використовувати проект із SVN його треба спочатку імпортувати в репозиторій за допомогою команди import (імпортувати):

$ cd some-project $ svn import -m "New project" path-in-repository

На відміну від CVS не потрібно вказувати мітки розробника та проекту, які не часто використовувалися на практиці.

Тепер нам потрібно створити робочу копію проекту за допомогою команди checkout (контроль) або co :

$ cd some-working-dir $ svn checkout path-in-repository

Після внесення змін ми використовуємо команду commit (здійснити зміни) або ci для збереження змін у репозиторії:

$ svn commit -m "Some changes"

І для оновлення робочої копії проекту використовується команда update (оновити) або up .

Система керування версіями(від англ. Version Control System - VCS, або Revision Control System) - спеціальне програмне забезпечення для роботи з інформацією, що часто змінюється, дозволяє зберігати кілька версій одного і того ж документа і при необхідності повертатися до більш ранніх версій, визначати, хто і коли зробив ту чи іншу зміну, а також багато іншого.

Такі системи найбільш широко використовуються при розробці програмного забезпечення для зберігання файлів програми, що розробляється.

Часто буває, що над одним проектом одночасно працюють кілька людей, і якщо дві людини змінюють один і той самий файл, то один з них може випадково скасувати зміни, зроблені іншим. Системи управління версіями відстежують такі конфлікти та пропонують засоби їх вирішення. Більшість таких систем може автоматично поєднати (злити) зміни, зроблені різними розробниками. Однак таке автоматичне об'єднання змін зазвичай можливе лише для текстових файлів і за умови, що змінювалися різні частини цього файлу, що не перетинаються. Це обмеження пов'язано з тим, що більшість систем керування версіями орієнтовані на підтримку процесу розробки програмного забезпечення, а вихідні кодипрограм зберігаються в текстових файлах. Якщо автоматичне об'єднання не вдалося виконати, система може запропонувати вирішити проблему вручну.

Деякі системи керування версіями дають змогу заблокувати файл у сховищі. Блокування не дозволяє іншим користувачам отримати робочу копію або перешкоджає зміні робочої копії файлу (наприклад, засобами файлової системи) та забезпечує, таким чином, винятковий доступ тільки тому користувачеві, який працює з документом.

Більшість систем керування версіями надають такі можливості:

• дозволяють створювати різні варіантиодного документа (гілки) з спільною історієюзмін до точки розгалуження та з різними - після неї;
• дають можливість дізнатися, хто і коли додав чи змінив конкретний набір рядків у файлі;
• ведуть журнал змін, у якому користувачі можуть записувати пояснення у тому, що і чому вони змінили у цій версії;
• контролюють права доступу користувачів, дозволяючи чи забороняючи читання чи зміна даних, залежно від цього, хто запитує цю дію.

Кожна система управління версіями має свої специфічні особливості у наборі команд, порядку роботи користувачів та адмініструванні. Проте загальний порядокроботи для більшості VCS є абсолютно стереотипним. Тут передбачається, що проект, хоч би яким він був, вже існує і на сервері розміщений його репозиторій, до якого розробник отримує доступ.

Початок роботи із системою.Першою дією, яку повинен виконати розробник, є вилучення робочої копії проекту або його частини, з якою належить працювати. Ця дія виконується за допомогою стандартної командивилучення версії (checkout або clone) або за допомогою спеціальної команди, фактично виконує те саме дію. Розробник задає версію, яка має бути скопійована, за замовчуванням зазвичай копіюється остання (або обрана адміністратором як основна) версія.

Щоденний цикл роботи.Звичайний цикл роботи розробника протягом робочого дня виглядає так:

• оновлення робочої копії: у міру внесення змін до основної версії проекту робоча копія на комп'ютері розробника старіє і розбіжність її з основною версією проекту збільшується, це підвищує ризик виникнення конфліктних змін (див. нижче), і виникає потреба підтримувати робочу копію в стані максимально близькому до поточної основної версії проекту версії, тому розробник виконує операцію поновлення робочої копії (update) наскільки можливо часто, що визначається частотою внесення змін, яка залежить від активності розробки, числа розробників, а також від часу, витраченого на кожне оновлення;
• модифікація проекту: розробник модифікує проект, змінюючи файли, що входять до нього в робочій копії відповідно до проектного завдання, ця робота проводиться локально і не вимагає звернень до сервера VCS;
• фіксація змін:завершивши черговий етап роботи над завданням, розробник фіксує (commit) свої зміни, передаючи їх на сервер (або в основну галузь, якщо робота над завданням повністю завершена, або окрему галузь розробки даного завдання).