В цьому розділі йдеться про початок роботи з Git.
Знайомство відбувається поступово: пояснення основних принципів роботи систем контролю версій, потім інструкція з запуску Git у вашій системі та врешті-решт опис його налаштування для початку роботи.
Наприкінці розділу ви вже розумітимете передумови виникнення Git, причини та способи його використання саме у ваших проектах та будете готові до практичних дій у цьому напрямі.
Що таке контроль версій і навіщо він вам?
Контроль версій здійснює система, що записує та «запам’ятовує» усі зміни одного чи сукупності файлів, завдяки чому ви можете відновити будь-яку версію пізніше.
Не варто надавати багато значення тому, що у прикладах цієї книги в якості файлів для контролю версій використовуються початкові коди програм. Насправді, для контролю версій можуть використовуватись будь-які файли
Якщо ви графічний чи вебовий дизайнер та бажаєте зберігати кожну копію зображення чи шару, то використання системи контролю версій (СКВ) стане навпрочуд мудрим рішенням.
СКВ дозволяє: повертати до попереднього стану будь-які файли чи увесь проект цілком; переглядати зміни зроблені протягом усього часу; бачити хто вносив правки у щось, що могло викликати проблему; хто і коли додав зауваження та багато інших рречей.
Використання СКВ також передбачає можливість легкого відновлення файлів у разі їх втрати чи пошкодження. На додачу, все це ви отримуєте за досить невеликих витрат часу та ресурсів системи
Багато людей здійснюють контроль версій шляхом простого копіювання файлів до іншої директорії (особливо охайні навіть іменують директорії у хронологічному порядку). Завдяки своїй простоті такий підхід дуже розповсюджений, втім він також неймовірно ненадійний. Адже дуже легко переплутати в якій саме директорії ви зараз знаходитесь і випадково перезаписати не ті файли
Для вирішення цієї проблеми були створені локальні СКВ, що мали просту базу даних для зберігання усіх змін необхідних файлів. (див. Ілюстрацію 1-1).
Insert 18333fig0101.png Ілюстрація 1-1. Схема локальної системи контролю версій.
Однією з найпопулярніших систем цього типу була rcs, що й досі розповсюджується разом з багатьма комп’ютерами. Навіть операційна система Mac OS X отримує команду rcs після встановлення Developer Tools (Інструменти Розробника). Робота цієї програми заснована на зберіганні сукупності патчів (так називаються відмінності між файлами) між версіями у спеціальному форматі на диску. Вона може відновити стан будь якого файлу у будь-який час шляхом застосування усіх патчів.
Наступною великою проблемою, з якою зіткнулись люди, стала необхідність співпраці з іншими розробниками. В результаті, справу було вирішено завдяки централізованим системам контролю версій (ЦСКВ). Такі системи, як CVS, Subversion та Perforce, складаються з одного сервера, що зберігає усі контрольовані файли, та деякої кількості клієнтів, які отримують файли з цього «центру». Протягом багатьох років це залишалось стандартом у контролі версій (див. Ілюстрацію 1-2).
Insert 18333fig0102.png Ілюстрація 1-2. Схема централізованої системи контролю версій.
Така конфігурація має багато переваг, особливо у порівнянні з локальними СКВ. Наприклад, кожен може дізнатись чим займається інший учасник проекту на будь-якому етапі. У адміністраторів є чіткий контроль над тим, хто і що може робити. До того ж, значно простіше адмініструвати централізовану систему, аніж мати справу з локальними базами даних кожного клієнта.
Втім, і цей підхід має деякі серйозні вади. Найбільш очевидною є безумовна залежність від одного елементу мережі, що являє собою централізований сервер. Якщо на годину вимкнути сервер, то протягом цієї години стає неможливою взаємодія між учасниками системи та збереження версійних змін до об’єктів, над якими ведеться робота. При пошкодженні жорсткого диску з центральною базою даних та відсутності її резервних копій ви втрачаєте абсолютно все — всю історію проекту, за виключенням хіба що поодиноких знімків, які клієнтам пощастило мати на локальних машинах.
Локальні СКВ страждають від тієї ж проблеми — ризик повної втрати проекту у результаті зберігання усієї історії в одному місці.
Ось тут в гру вступають розподілені системи контролю версій (РСКВ). У цих системах (наприклад: Git, Mercurial, Bazaar чи Darcs) клієнти мають не лише останній знімок файлів, вони отримують повне дзеркало репозиторію. Тож, за втрати одного з серверів, за допомогою якого відбувається співпраця, будь-який з клієнтських репозиторіїв може бути скопійований назад на сервер для відновлення. Кожне стягування файлів, по суті є повною резервною копією усіх даних (див. Ілюстрацію 1-3).
Insert 18333fig0103.png Ілюстрація 1-3. Розподілена система контролю версій.
Крім того, багато з цих систем чудово працюють з декількома віддаленими репозиторіями. Таким чином, у межах одного проекту ви можете співпрацювати з різними групами людей і різними шляхами одночасно. Це дозволяє налаштувати декілька типів робочих процесів, на відміну від централізованих систем.
Як і багато інших видатних речей, Git почався з творчого непорозуміння та гарячих протиріч. Ядро Linux це проект з відкритим програмним кодом достатньо великих розмірів. Протягом більшої частини існування ядра (1991-2002 рр.) зміни у коді передавались у вигляді патчів та архівів. У 2002 році у проекті почала використовуватись пропрієтарна РСКВ під назвою BitKeeper.
У 2005 році взаємовідносини між спільнотою розробників ядра та комерційною компанією, що займалась розробкою BitKeeper, погіршились і право безкоштовного користування продуктом було скасовано. Це спонукало спільноту Linux (і особливо Лінуса Торвальдса, засновника Linux) до створення власного інструменту. У пригоді став досвід використання BitKeeper з усіма його перевагами і недоліками. Головні вимоги до нової системи були такі:
- швидкість;
- простий дизайн;
- підтримка нелінійної розробки (тисячі паралельних гілок);
- повна розподільність;
- можливість ефективного управління великими проектами на зразок ядра Linux (швидкість та розмір даних).
Від свого створення у 2005 Git розвивався зберігаючи простоту використання, але не втрачаючи цих початкових орієнтирів. Він неймовірно швидкий, ефективний на великих проектах і має вражаючу систему розгалужування для нелінійної розробки (див. Розділ 3).
Отже, що таке Git у двох словах?
Це дуже важливо засвоїти, оскільки, зрозумівши основи та принципи функціонування Git, ви зможете використовувати його більш ефективно і з меншими зусиллями.
На час знайомства з Git спробуйте забути все що ви знаєте про інші СКВ. Це дозволить уникнути деяких непорозумінь.
Git зберігає інформацію та оперує нею дещо по-іншому, ніж інші системи, навіть попри схожий користувацький інтерфейс. Розуміння цих відмінностей допоможе уникнути плутанини у подальшому.
Однією з головних відмінностей від інших систем (таких як Subversion та подібних їй) є те, як Git сприймає дані.
Більшість СКВ зберігають інформацію як список файлових редагувань. Ці системи (CVS, Subversion, Perforce, Bazaar) розглядають інформацію як список файлів та їх змін, що показано на Ілюстрації 1-4.
Insert 18333fig0104.png Ілюстрація 1-4. Інші системи зберігають дані як список змін до початкової версії кожного файлу.
Git сприймає та зберігає інформацію по-іншому. Git розглядає свої дані ніби сукупність знімків невеликої файлової системи. Щоразу, при збереженні поточного стану проекту, Git робить знімок (копію) того, як виглядають ваші файли саме у цей момент і зберігає посилання на цей знімок. Для ефективності, якщо файл не змінився, Git не збергіє його знову, а просто робить посилання на ідентичний файл з попередньої фіксації змін. Схематичне зображення такого підходу показано нижче.
Insert 18333fig0105.png Ілюстрація 1-5. Git зберігає дані як знімки проекту за хронологією.
Це дуже важлива різниця між Git та іншими СКВ. З цієї причини у Git було заново переосмислено майже кожен аспект контролю версій, що зробило його схожим на мініатюрну файлову систему з деякими неймовірно потужними вбудованими інструментами. Ми познайомимось з деякими перевагами, які ви отримаєте при сприйнятті інформації подібним чином, у третьому розділі, де йдеться про гілки.
Більшість операцій в Git потребують лише локальних файлів та ресурсів для здійснення операцій — немає небхідності у інформації з інших комп’ютерів вашої мережі. Якщо ви працюєте з ЦСКВ, де більшість операцій обтяжені такими мережевими запитами, то цей аспект може привести вас до думки, що боги швидкості наділили Git неземною силою. Через те, що повна історія проекту знаходиться на вашому локльному диску, більшість операцій здійснюються майже миттєво.
Наприклад, для перегляду історії, Git не має потреби брати її з серверу, він просто зчитує її прямо з локальної бази даних. Це означає, що ви отримуєте історію проекту не встигнувши кліпнути оком. Якщо ви бажаєте переглянути відмінності між поточною версією файлу та його редакцією місячної давності, Git знайде копію збережену місяць тому і проведе локальний розрахунок замість того, щоб звертатись за цим до віддаленого серверу чи спочатку робити запит на отримання старішої версії файлу.
Також це значить, що за відсутності мережевого з’єднання ви не будете мати особливих обмежень. Перебуваючи у літаку чи потязі можна цілком комфортно фіксувати зміни поки не відновите з’єднання з мережею для їх завантаження. Дорогою додому, не маючи змоги належним чином використовувати свій VPN-клієнт, все одно можна продовжувати роботу. В багатьох інших системах подібні дії або неможливі, або пов’язані з безліччю труднощів. Наприклад, в Perforce, без з’єднання з мережею вам не вдасться зробити багато; у Subversion та CVS ви можете редагувати файли, але не можете фіксувати внесені зміни (оскільки немає зв’язку з базою даних). На перший погляд такі речі здаються незначним, але ви будете вражені наскільки велике значення вони можуть мати.
Будь-що у Git, перед збереженням, отримує контрольну суму, за якою потім і перевіряється. Таким чином, неможливо змінити файл чи директорію так, щоб Git про це не дізнався. Цей функціонал вбудовано у систему на найнижчих рівнях і є складовою частиною її філософії. Ви не можете втратити інформацію при передачі чи отримати пошкоджений файл без відома Git.
Механізм, який використовується для цього контролю, називається хеш SHA-1. Він являє собою 40-символьну послідовність цифр та перших літер латинського алфавіту (a-f) і вираховується на основі вмісту файлу чи структури директорії. Виглядає це приблизно так:
24b9da6552252987aa493b52f8696cd6d3b00373
При роботі з Git ви постійно зустрічатимете такі хеші. Фактично, Git зберігає все не за назвою файлу, а саме за такими адресами.
Коли ви виконуєте певні дії в Git, при цьому, майже завжди відбувається додавання інформації до її бази даних. Дуже складно змусити систему зробити щось невиправне чи повністю видалити дані. Як і в будь-якій СКВ, ви можете втратити чи зіпсувати лише незафіксовані зміни. Але це майже неможливо, коли вже зроблено знімок, особливо, якщо ви регулярно надсилаєте свою базу до іншого репозиторію.
Це робить використання Git приємним, оскільки можна експериментувати без загрози щось зіпсувати.
Про те, як Git зберігає інформацію та як можна відновити втрачені дані, детальніше розповідається у Розділі 9.
А зараз, будьте уважні. Це найважливіша річ, яку потрібно запам’ятати, якщо ви хочете щоб подальше вивчення Git пройшло гладко.
Git має три основних стани, у яких можуть перебувати ваші файли: зафіксований, змінений та доданий.
Зафіксований — значить, дані безпечно збережено в локальній базі даних.
Змінений означає, що у файл внесено редагування, які ще не зафіксовано у базі даних.
Доданий стан виникає тоді, коли ви позначаєте змінений файл у поточній версії, готуючи його таким чином до фіксації.
Це приводить нас до трьох головних відділів проекту під управлінням Git: директорія Git, робоча директорія та область додавання.
Insert 18333fig0106.png Ілюстрація 1-6. Робоча директорія, область додавання та директорія Git.
У директорії Git система зберігає метадані та базу даних об’єктів вашого проекту. Це найважливіша частина проекту. Саме вона копіюється при клонуванні проекту з іншого комп’ютеру.
Робоча директорія являє собою файли і директорії проекту у поточному стані. Ці об’єкти видобуваються з бази даних (яка, пригадаємо, зберігається у директорії Git) і розміщуються на диску для подальшого використання та редагування.
Область додавання це простий файл, що зазвичай знаходиться у директорії Git і містить інформацію про об’єкти, стан яких буде враховано під час наступної фіксації змін.
Найпростіший процес взаємодії з Git виглядає приблизно так:
- Ви редагуєте файли у своїй робочій директорії.
- Надсилаєте файли в область додавання, шляхом створення знімків їх поточного стану.
- Робите фіксацію, яка бере файли в області додавання і остаточно зберігає цей знімок у директорії Git.
У випадку, якщо окрема версія файлу вже є у директорії Git, цей файл вважається зафіксованим. Якщо він зазнав змін і перебуває в області додавання, то він доданий. Якщо ж його стан відрізняється від того, який було зафіксовано, і файл не знаходиться в області додавання, то він називається зміненим.
У наступному розділі ви дізнаєтесь більше про ці стани, а також про те, як використовувати їхні переваги або взагалі пропускати етап області додавання.
Перш за все, для використання Git, ви маєте його встановити. Для цього існує декілька способів; два найбільш вживаних це встановлення з сирців та встановлення існуючого пакунку для вашої платформи.
Встановлення Git з джерельного коду є дуже корисним, оскільки ви отримуєте найсвіжішу версію. У кожній новій версії системи зберігається тенденція до покращення елементів користувацького інтерфейсу, тож встановлення останньої версії це найкращий шлях, якщо ви володієте навиками компіляції програм з сирців. Крім того, багато дистрибутивів Лінукс містять досить застарілі пакунки, що може слугувати одним з приводів до цього способу встановлення.
Для встановлення Git вам знадобляться бібліотеки, від яких залежить система: curl, zlib, openssl, expat та libiconv. Якщо ви користуєтесь системою, в якій є утиліта yum (наприклад, Fedora) чи apt-get (будь-яка система на основі Debian — Ubuntu, Mint тощо), для встановлення цих залежностей в нагоді вам може стати одна з таких команд:
$ yum install curl-devel expat-devel gettext-devel \
openssl-devel zlib-devel
$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
libz-dev libssl-dev
Після отримання необхідних компонентів, можна рухатись далі і стягнути останній знімок системи Git з офіційного сайту:
http://git-scm.com/download
Потім компіляція і встановлення:
$ tar -zxf git-1.7.2.2.tar.gz
$ cd git-1.7.2.2
$ make prefix=/usr/local all
$ sudo make prefix=/usr/local install
Коли все вишевказане виконано, ви можете завершити процес оновленням Git його власними засобами:
$ git clone git://git.kernel.org/pub/scm/git/git.git
Якщо бажаєте встановити Git у системі Linux, можете скористатись вбудованим менеджером пакунків. Наприклад, у Fedora це робиться так:
$ yum install git-core
Якщо ж ви користувач дистрибутиву базованого на Debian чи його нащадках (як Ubuntu, Mint чи elementary), спробуйте apt-get:
$ apt-get install git
Крім того, багато сучасних дистрибутивів мають графічний інтерфейс управління програмним оточенням — це найпростіший шлях встановлення, а всі залежності підтягнуться автоматично.
Існує два простих шляхи встановлення Git на Mac.
Найпростішим є використання графічного інсталятору, який можна звантажити з його сторінки на сервісі Google Code:
http://code.google.com/p/git-osx-installer
Insert 18333fig0107.png Ілюстрація 1-7. Програма встановлення Git в OS X.
Іншим розповсюдженим способом є встановлення за допомогою MacPorts (http://www.macports.org). Якщо маєте цей пакет, встановіть Git командою:
$ sudo port install git-core +svn +doc +bash_completion +gitweb
Вам не обов’язково мати всі розширення. Але якщо коли-небудь ви будете використовувати Git з репозиторіями Subversion, вам знадобиться +svn (детальніше у Розділі 8).
Встановлення Git на комп’ютері під управлінням операційної системи Windows не повинно викликати проблем.
Одну з найпростіших процедур встановлення пропонує проект msysGit. Просто звантажте встановлювач зі сторінки на GitHub і запустіть процес встановлення:
http://msysgit.github.com/
Після встановлення, ви отримаєте і командний рядок (що включає також SSH клієнт), і стандартний графічний інтерфейс.
Примітка: ви можете використовувати Git з командним рядком msysGit, він допускає набори команд, що наводяться в цій книзі. Якщо ж, з якихось причин, вам потрібно використовувати вбудований у Windows командний рядок, то замість простих одинарних лапок потрібно використовувати подвійні (наприклад, для параметрів, що містять пробіли чи закінчуються символом "^", оскільки це символ продовження).
Тепер, маючи у своїй системі Git, варто зробити деякі налаштування його середовища. Це потрібно зробити лише один раз, оновлення не перезаписуватимуть їх. Втім, ви завжди можете внести зміни, повторно виконавши потрібні команди.
Git містить інструмент під назвою "git config", що дозволяє переглядати та встановлювати налаштування, від яких залежить вигляд та функціонал Git. Ці налаштування можуть зберігатись у трьох різних місцях:
- файл
/etc/gitconfig: містить значення змінних усіх користувачів системи та їхніх репозиторіїв. Для звернення до цього файлу потрібно в командуgit configпередати параметр--system.
- файл
~/.gitconfigмістить налаштування лише для вашого користувача. Працювати з цим файлом можна за допомогою опції--global.
- конфігураційний файл у директорії Git (
.git/config) стосується лише цього окремого репозиторію. Значення кожного наступного равня мають пріоритет перед попереднім, тож значення з.git/configбільш важливі, ніж з/etc/gitconfig.
У системі Windows Git шукатиме файл .gitconfig у директорії $HOME (%USERPROFILE% у системному середовищі), що зазвичай вказує на C:\Documents and Settings\$USER або C:\Users\$USER, в залежності від версії операційної системи. Крім того, шукатиметься також файл /etc/gitconfig, що пов’язаний з кореневою директорією MSys, яка знаходиться там, де ви вирішили встановити Git.
Перша річ, про яку варто подбати після встановлення Git, вказати ваше ім’я та адресу електронної пошти. Це важливо, оскільки кожна фіксація змін використовує цю інформацію і записує її у дані про знімки:
$ git config --global user.name "Ivan Franko"
$ git config --global user.email [email protected]
Знову ж таки, за умови використання параметру --global, вам знадобиться виконати цю дію лише одного разу. Git постійно використовуватиме вказану інформацію для кожної з ваших дій у цій системі. Змінити введені ім’я чи адресу пошти для окремих проектів можна, знаходячись у директорії проекту, тими ж командами, але вже без використання параметру --global.
Тепер, коли особисті налаштування у порядку, ви можете вказати який текстовий редактор бажаєте використовувати у випадках, коли знадобиться вводити текстову інформацію. Типово Git використовує редактор, що є стандартним у системі (зазвичай це Vi чи Vim). Для того щоб змінити його на інший (наприклад, Emacs), потрібно виконати таку команду:
$ git config --global core.editor emacs
Іншою корисною опцією може бути використання певної утиліти порівняння, що буде використовуватись для розв’язання конфліктів при об’єднанні знімків. Припустімо, це має бути vimdiff:
$ git config --global merge.tool vimdiff
Git сприймає kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, та opendiff у якості коректних значень. Також ви можете вказати інший інструмент, про що більш детальніше розповідається у Розділі 7.
Для перегляду своїх налаштувань використовуйте команду git config --list:
$ git config --list
user.name=Taras Shevchenko
[email protected]
color.status=auto
color.branch=auto
color.interactive=auto
color.diff=auto
...
Деякі ключі можуть зустрічатись декілька разів. Це може статись через те, що Git шукає значення у різних місцях (наприклад, /etc/gitconfig та ~/.gitconfg). В такому випадку, Git використовує останнє знайдене значення для кожного з ключів.
Також, за допомогою конструкції git config {key} можна перевірити значення певного ключа:
$ git config user.name
Taras Shevchenko
У випадку, якщо вам знадобиться допомога, існує три шляхи доступу до керівництва з використання для будь-якої команди Git:
$ git help <verb>
$ git <verb> --help
$ man git-<verb>
Наприклад, так ви можете переглянути допоміжну інформацію щодо використання команди config:
$ git help config
Особлива зручність цих команд у том, що вони доступні навіть без підключення до мережі.
Якщо ж офіційного керівництва і цієї книжки буде недостатньо, і вам знадобиться персональна допомога, спробуйте під’єднатись до каналу #git або #github на IRC сервері Freenode. Там постійно перебувають сотні людей, що добре розуміються на роботі з Git і готові допомогти.
Тепер ви знаєте що таке Git і в чому його відмінність від централізованих систем контролю версій, з якими ви, можливо, вже знайомі. Також ви отримали у своїй системі робочу версію Git з персональними налаштуваннями.
Настав час дізнатись про Git більше.