Pro GIT/Вступ/Про контроль версій

Матеріал з Вікіпідручника
Перейти до навігації Перейти до пошуку

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

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

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

Малюнок 1-1. Схема локальної СКВ.

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

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

Одним з найбільш популярних інструментів СКВ є система rcs, котра досі поширена на багатьох ПК нині. Навіть популярна операційна система Mac OS X має утіліту rcs, котра встановлюється разом з Developer Tools. Робота цього інструменту базується на збереженні наборів патчів (це різниця між файлами) від одніє ревізії до іншої в спеціальному форматі на дискі; це дає мжливість потім відтворити вигляд будь-якого файлу в будь-який момент часу, накладаючи патчі.

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

Малюнок 1-2. Схема централізованого СКВ.

Наступна важлива проблема полягала в потребі співпрацювати з розробниками на інших машинах. Для вирішення цієї проблеми були розроблені централізовані системи контролю версій (ЦСКВ). Ці системи, такі як CVS, Subversion та Perforce, мають єдиний сервер, котрий містить усі версії файлів, а клієнти отримують копії файлів з цього центрального місця. Протягом багатьох років це було стандартом для СКВ. (див. Малюнок 1-2).

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

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

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

Малюнок 1-3. Схема розподілених СКВ.

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

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






Коротка історія GIT