Введення в системи контролю версій - основи git

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

Про контроль версій

Що таке контроль версій, і навіщо він вам потрібен?

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

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

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

У найпростішому випадку вищенаведену проблему можна вирішити зберіганням декількох копій файлів, наприклад, один для виправлення помилок в першій версії проекту і другий для нових змін. Так як зміни зазвичай не дуже великі в порівнянні з розміром файлу, то можна зберігати тільки змінені рядки використовуючи утиліту diff і пізніше об'єднувати їх за допомогою утиліти patch. Але що якщо проект складається з декількох тисяч файлів і над ним працює сотня осіб? Якщо в цьому випадку використовувати метод із зберіганням окремих копій файлів (або навіть тільки змін) то проект зупиниться дуже швидко. У наступних лекціях, для прикладів я буду використовувати вихідні коди програм, але насправді під версійність контроль можна помістити файли практично будь-якого типу.

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

Локальні системи контролю версій

Як вже говорилося раніше - один із прикладів локальної СУВ гранично простий: багато хто воліє контролювати версії, просто копіюючи файли в інший каталог (як правило додаючи поточну дату до назви каталогу). Такий підхід дуже поширений, тому що простий, але він і частіше дає збої. Дуже легко забути, що ти не в тому каталозі, і випадково змінити не той файл, або скопіювати файли не туди, куди хотів, і затерти потрібні файли. Щоб вирішити цю проблему, програмісти вже давно розробили локальні ВКВ з простою базою даних, в якій зберігаються всі зміни потрібних файлів

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

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

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

Наступною основною проблемою виявилася необхідність співпрацювати з розробниками за іншими комп'ютерами. Щоб розв'язати цю проблему, були створені централізовані системи контролю версій (ЦСКВ). У таких системах, наприклад CVS, Subversion і Perforce, є центральний сервер, на якому зберігаються всі файли під версійність контролем, і ряд клієнтів, які отримують копії файлів з нього. Багато років це було стандартом для систем контролю версій.

Такий підхід має безліч переваг, особливо над локальними ВКВ. Наприклад, всі знають, хто і чим займається в проекті. У адміністраторів є чіткий контроль над тим, хто і що може робити, і, звичайно, адмініструвати ЦСКВ набагато легше, ніж локальні бази на кожному клієнті. Однак при такому підході є й кілька серйозних недоліків. Найбільш очевидний - централізований сервер є вразливим місцем всієї системи. Якщо сервер вимикається на годину, то протягом години розробники не можуть взаємодіяти, і ніхто не може зберегти нової версії своєї роботи. Якщо ж пошкоджується диск з центральною базою даних і немає резервної копії, ви втрачаєте абсолютно все - всю історію проекту, хіба що за винятком кількох робочих версій, збережених на робочих машинах користувачів.

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

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

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

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

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

Subversion

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

І в цій ситуації в гру вступають розподілені системи контролю версій (РСКВ). У таких системах як Git, Mercurial, Bazaar або Darcs клієнти не просто вивантажують останні версії файлів, а повністю копіюють весь репозиторій. Тому в разі, коли "вмирає" сервер, через який йшла робота, будь-який клієнтський репозиторій може бути скопійований назад на сервер, щоб відновити базу даних. Кожен раз, коли клієнт забирає свіжу версію файлів, він створює собі повну копію всіх даних.

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

Навіщо потрібні розподілені системи?

Короткий опис популярних розподілених СУВ