5.1 Розподілений Git – Розподілені процеси роботи

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

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

Розподілені процеси роботи

На відміну від Централізованих Систем Керування Версіями (ЦСКВ), розподілена сутність Git дозволяє вам бути набагато більш гнучким щодо того, як розробники співпрацюють над проектами. У централізованих системах кожен розробник є одним з вузлів, які працюють більш менш на рівних над централізованим розподілювачем (hub). У Git, втім, кожен розробник є потенційно і вузлом, і сервером — тобто, кожен розробник може як надсилати код до інших репозиторіїв, як і супроводжувати публічний репозиторій, на якому інші можуть базувати свою роботу, та до якого вони можуть надсилати зміни. Це відкриває безмежні можливості процесу роботи для вашого проекту та/або вашої команди, отже розглянемо декілька поширених парадигм, щоб скористатись цією гнучкістю. Ми дізнаємось про переваги та можливі недоліки кожного методу; ви можете вибрати якийсь один, або змішати та сумістити елементи кожного.

Централізований процес роботи

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

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

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

Вона також може використовуватись не лише маленькими командами. За допомогою моделі галуження Git, сотні розробників одночасно можуть її використовувати успішно для роботи над одним проектом за допомогою десятків гілок.

Процес роботи з менеджером інтеграції

Оскільки Git дозволяє вам мати декілька віддалених сховищ, можливо мати процес роботи, в якому кожен розробник має право на запис до власного публічного репозиторія та доступ на читання до репозиторіїв інших розробників. Цей сценарій зазвичай включає канонічне сховище, яке представляє “офіційний” проект. Щоб зробити внесок до такого проекту, треба створити власний публічний клон проекту та надіслати зміни до нього. Потім, ви можете надіслати запит до супроводжувача головного проекту, щоб він злив ваші зміни. Супроводжувач тоді може додати ваше сховище як віддалене, перевірити ваші зміни локально, злити їх до своєї гілки, та надіслати до свого репозиторія. Процес працює наступним чином (дивіться Процес роботи з менеджером інтеграції.):

1. Супроводжувач проекту надсилає зміни до свого власного репозиторія.
2. Розробник клонує цей репозиторій та робить зміни.
3. Розробник надсилає зміни до своєї власної публічної копії.
4. Розробник надсилає супроводжувачу листа, в якому просить злити його зміни.
5. Супроводжувач додає сховище розробника як віддалене та зливає зміни локально.
6. Супроводжувач надсилає злиті зміни до головного репозиторія.

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

Процес роботи з диктатором та лейтенантами

Це варіація процесу роботи з багатьма репозиторіями. Зазвичай він використовується у величезних проектах з сотнями учасників: одним славетним прикладом є ядро Linux. Різноманітні менеджери інтеграції відповідають за окремі частини репозиторія; їх називають лейтенантами. Всі лейтенанти мають одного менеджера інтеграції, відомого як доброзичливий диктатор. Доброзичливий диктатор надсилає зміни зі свого сховища до зразкового сховища, з якого всі розробники мають отримувати зміни. Процес працює наступним чином (дивіться Процес роботи з доброзичливим диктатором.):

1. Звичайні розробники працюють у власній тематичній гілці та перебазовують свою роботу поверх master . Тієї взірцевої гілки master , до якої диктатор надсилає зміни.
2. Лейтенанти зливають тематичні гілки розробників до власних гілок master .
3. Диктатор зливає гілки лейтенантів master до гілки диктатора master .
4. Нарешті, диктатор надсилає цю гілку master до зразкового репозиторія, щоб інші розробники могли перебазуватись поверху неї.

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

Підсумок щодо процесів роботи

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

1.3 Вступ – Основи Git

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

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

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

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

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

Майже кожна операція локальна

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

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

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

Git цілісний

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

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

24b9da6552252987aa493b52f8696cd6d3b00373

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

1.8 Вступ – Початкове налаштування Git

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

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

1. Файл /etc/gitconfig містить значення для кожного користувача в системі і всіх їхніх репозиторіїв. Якщо ви передаєте опцію –system при виконанні git config , параметри читаються та пишуться з цього файлу. (Це системний файл конфігурації, відповідно, вам потрібен був доступ адміністратора чи суперкористувача, щоб змінювати його.)
2. Файл ~/.gitconfig або ~/.config/git/config зберігає значення саме для вас — користувача. Ви можете налаштувати Git читати і писати в цей файл, вказуючи опцію –global.
3. Файл config у каталозі Git (тобто .git/config ) у тому репозиторії, який ви використовуєте в даний момент, зберігає налаштування конкретного репозиторія.

Кожен рівень має пріоритет над налаштуваннями в попередньому рівні, тобто параметри в .git/config перевизначають параметри в /etc/gitconfig .

У системах Windows, Git шукає файл .gitconfig в каталозі $HOME ( C:\Users\$USER для більшості користувачів). Він також все одно шукає файл /etc/gitconfig , хоча відносно кореня MSys, котрий знаходиться там, де ви вирішили встановити Git у вашій Windows системі, коли ви запускали інсталяцію. Якщо ви використовуєте Git для Windows версії 2.x або новішу, то є також системний конфігураційний файл C:\Documents and Settings\All Users\Application Data\Git\config під Windows XP, і C:\ProgramData\Git\config під Windows Vista й новіші. Цей файл може бути зміненим лише за допомогою git config -f адміністратором.

Ім’я користувача

Перше, що ви повинні зробити, коли ви інсталюєте Git – це встановити ім’я користувача та адресу електронної пошти. Це важливо, тому що кожен коміт в Git використовує цю інформацію, і вона незмінно включена у комміти, які ви робите:

$ git config --global user.name "John Doe" $ git config --global user.email [email protected]

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

Багато з графічних інструментів допомагають зробити це при першому запуску.

Редактор

Зараз, коли ваше ім’я вже вказано, ви можете налаштувати текстовий редактор за замовчуванням, який буде використовуватися Git при необхідності ввести повідомлення. Якщо це не налаштовано, Git використовує типовий системний редактор.

Якщо ви бажаєте використовувати інший текстовий редактор, наприклад Emacs, необхідно зробити наступне:

$ git config --global core.editor emacs

Під Windows, якщо ви бажаєте використати інший текстовий редактор, то маєте вказати повний шлях до відповідної програми. Це залежить від того, як ваш редактор поставляється.

У випадку Notepad++ — популярного редактору коду — ви напевно надасте перевагу 32-бітовій версії, адже на час написання цього тексу 64-бітова версія не підтримувала всіх додатків. Якщо у вас 32-бітова система, чи у вас 64-бітова система і ви хочете використовувати 64-бітовий редактор, варто спробувати щось таке:

$ git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -nosession"

Якщо у вас 32-бітовий редактор під 64-бітовою системою, програму буде встановлено до C:\Program Files (x86) :

$ git config --global core.editor "'C:/Program Files (x86)/Notepad++/notepad++.exe' -multiInst -nosession"

Vim, Emacs і Notepad++ — це популярні текстові редактори, що їх часто використовують розробники на Unix-похідних системах (на кшталт Linux та macOS) та на Windows. Якщо ви не знайомі з цими редакторами, можливо, вам потрібно буде знайти інструкції з налаштуванню вашого улюбленого редактора з Git.

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

Перевірка налаштувань

Якщо ви хочете подивитися на свої налаштування, можете скористатися командою git config –list , щоб переглянути всі налаштування, які Git може знайти:

$ git config --list user.name=John Doe [email protected] color.status=auto color.branch=auto color.interactive=auto color.diff=auto . 

Ви можете побачити ключі більш ніж один раз, тому що Git читає однакові ключі з різних файлів (наприклад /etc/gitconfig або ~/.gitconfig ). У цьому випадку, Git використовує останнє значення для кожного ключа.

Ви також можете перевірити значення конкретного ключа виконавши git config :

$ git config user.name John Doe

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

$ git config --show-origin rerere.autoUpdate file:/home/johndoe/.gitconfig false