Професійна робота з Git

# Починаючи #

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

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

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

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

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

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

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

Insert 18333fig0101.png

Малюнок 1-1. Діаграма локального контролю версій.

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

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

Вставити зображення 18333fig0102.png

Малюнок 1-2. Діаграма централізованого контролю версій.

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

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

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

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

Insert 18333fig0103.png

Малюнок 1-3. Діаграма розподіленої системи контролю версій.

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

## Коротка історія Git ##

Як і багато великих речей в житті, Git почався з невеликої кількості креативного знищення та жорсткого протистояння. Ядро Linux є проектом з відкритим кодом з дуже великим размахом. Більшість часу підтримки ядра Linux (1991-2002), зміни у програмне забезпечення розходилися у вигляді патчів та архівованих файлів. В 2002, для проекту ядра Linux почали використовувати пропрієтарну РСКВ, яка називалася BitKeeper.

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

* Швидкість

* Проста будова

* Сильна підтримка для нелінійної розробки (тисячі паралельних гілок-бренчів)

* Повністю розподілена

* Можливість ефективної підтримки великих проектів, таких як ядро Linux (швидкість та розмір даних)

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

## Основи Git ##

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

### Знімки, а не відмінності ###

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

Insert 18333fig0104.png

Малюнок 1-4. Ініші системи що зберігають дані як зміни до базової версії кожного файлу.

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

Insert 18333fig0105.png

Малюнок 1-5. Git зберігає дані як знімки проекту в часі.

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

### Майже всі операції локальні ###

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

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

Це також означає, що існує досить мало операцій, які ви не зможете зробити, знаходячись офлайн, або без доступу до VPN. Якщо ви знаходитеся в літаку або в поїзді та бажаєте трохи попрацювати, ви можете комітити до того часу, як у вас з’явиться мережа для завантаження змін. Якщо ви прийшли додому та ваш VPN клієнт не працює, ви все одно можете працювати. В багатьох системах це неможливо або потребує надзвичайних зусиль. В Perforce, наприклад, ви не можете багато зробити без з’єднання з сервером, в Subversion та CVS ви можете редагувати файли, але не можете комітити зміни до вашої бази (оскільки ваша база офлайн). Це може виглядати як не дуже велика перевага, але ви здивуєтеся, наскільки велика різниця.

Git має цілісність

Механізм, який використовує Git для цього контрольного називається SHA-1 хеш. Це 40-символьний рядок складається з шістнадцяткових символів (0-9 і А-F) і розраховується на основі вмісту файлу або каталогу структури в Git. SHA-1 хеш виглядає приблизно так:

24b9da6552252987aa493b52f8696cd6d3b00373

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

Git взагалі тільки додає дані

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

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

Три статуси

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

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

Insert 18333fig0106.png

Робочий каталог, плацдарм, і Git каталог

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