Перелік лекцій

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

Коротка історія появи Git

Ядро Linux — це проект досить великого обсягу з відкритим програмним кодом. Більшу частину часу підтримання ядра Linux (1991-2002) виконувалося у вигляді патчів та архівів. У 2002 році проект ядра Linux почав використовувати закриту РСКВ BitKeeper.

У 2005 році відносини між спільнотою розробників ядра Linux і комерційною компанією, що розробила BitKeeper почали псуватись, і безкоштовне використання продуктом було скасовано. Це підштовхнуло розробників Linux (і зокрема Лінуса Торвальдса, автора Linux) розробити власну систему, спираючись на деякі знання, які вони отримали під час використання BitKeeper. Деякі з цілей нової системи були:

• швидкість
• проста архітектура
• сильна підтримка для нелінійного розвитку (тисячі паралельних гілок)
• децентралізація
• можливість ефективно управляти великими проектами, такими як ядро Linux (швидкість і розмір даних)

Знімки проєкту

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

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

Git зберігає дані як знімків проекту за хронологією.

Локальність операцій

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

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

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

Цілісність даних

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

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

Три стани

Git має три основних стани, в яких можуть перебувати ваші файли: збережений у коміті (commited), змінений (modified) та індексований (staged):

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

З цього випливають три основні частини проекту під управлінням Git: директорія Git, робоче дерево та індекс.

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

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

Індекс — це файл, що зазвичай знаходиться в директорії Git і містить інформацію про те, що буде збережено у наступному коміті. Також цей файл називають “областю додавання” (staging area), проте ми переважно будемо користуватись технічним терміном Git “індекс”.

Найпростіший процес взаємодії з Git виглядає приблизно так:

1. Ви редагуєте файли у своїй робочій директорії.
2. Вибірково надсилаєте до індексу лише ті зміни, що їх ви бажаєте зберегти в наступному коміті, і лише ці зміни буде збережено в індексі.
3. Створюєте коміт: знімок з індексу остаточно зберігається в директорії Git.
4. Повертаєтьеся до п.1

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