Системи контролю версій

— Привіт, Аміго!

— Привіт!

— Сьогодні я розповім тобі про системи контролю версій.

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

Проекти з мільйоном рядків коду – це реальність.

— Нічого собі.

— Це все дуже важко. Люди часто заважають одне одному, часто змінюють той самий код тощо. і т.п.

Щоб внести лад у цю плутанину, програмісти почали користуватися системами контролю версій для коду своєї програми.

Система контролю версій – це програма, представлена у вигляді клієнта та сервера.

На сервері програма зберігає дані (код, який пишуть програмісти), а програмісти за допомогою програм-клієнтів додають або змінюють його.

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

— А якнайбільше подробиць. Як це все працює?

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

Для цього тобі треба:

1) Залогініться на сервер (Login).

2) Скопіювати останню версію всіх файлів до себе на комп'ютер – команда Checkout.

3) Внести зміни до файлів.

4) Запустити програму локально та перевірити, що вона компілюється та працює.

5) Відправити свої «зміни» на сервер – команда Commit.

— Загалом ясно.

— Але це ще не все. Ось уяви, що ти прийшов вранці на роботу, а в Індії вже обід і твої індійські колеги вже щось поміняли, і закомітили свої зміни до вашого репозиторію (сховища) на сервері.

Тобі ж треба працювати з останньою актуальною версією даних. Тоді ти виконуєш команду Update.

— А в чому її відмінність від Checkout?

— Checkout призначена для копіювання всіх файлів репозиторію, а команда Update лише для тих файлів, які оновилися на сервері, з часів останньої твоєї команди Checkout /Update.

Ось як це приблизно працює:

Checkout:

Тепер допустимо, ми змінили файл B і хочемо залити його на сервер. Для цього треба використовувати команду Commit:

А ось як працює команда Update:

— Як цікаво. А чи є ще команди?

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

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

— А що робити другому?

Другому запропонують зробити Update, щоб забрати до себе останні зміни із сервера. Це, до речі, хороший стиль – перед комітом робити Update

Потім, під час виконання операції Update, програма-клієнт спробує об'єднати локальні зміни зі змінами, отриманими з сервера.

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

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

— Зрозуміло. Розумно, загалом.

— І ще одна річ – гілки.

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

— Що робити?

— Для цього в репозиторій додали вітки (branches). Тобто. грубо кажучи – поділили репозиторій на дві частини. Але не за файлами чи директоріями, а за версіями.

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

Такий шлях – це і є альтернативна гілка історії.

Або можеш просто спробувати уявити, що гілка – це просто копія репозиторію. Тобто. в якийсь момент, ми клонували репозиторій на сервері і в нас крім головного (який часто називають trunk – ствол) з'явився ще один - branch (гілка).

— Ну, так зрозуміліше.

А чому не можна було просто сказати, що ми скопіювали репозиторій?

— Це не є копіюванням у чистому вигляді.

Такі гілки можна не тільки відокремлювати від стовбура (trunk), але й приєднувати до нього.

— Тобто. можна якусь роботу виконати у гілці, а коли її буде закінчено – додати репозиторій-гілки до репозиторію-ствола?

— Ага.

— І що при цьому станеться з файлами?

— Файли смерджаться (об'єднаються).

— Ну, звучить круто, сподіваюся так само круто і працює.

— А то. Гаразд, давай робити перерву.

Ось тут дуже багато корисної інформації.