-
1. Вступ
- 1.1 Про систему контролю версій
- 1.2 Коротка історія Git
- 1.3 Основи Git
- 1.4 Git, зазвичай, тільки додає дані
- 1.5 Три стани
- 1.6 Командний рядок
- 1.7 Інсталяція Git
- 1.8 Початкове налаштування Git
- 1.9 Отримання допомоги
- 1.10 Підсумок
-
2. Основи Git
- 2.1 Створення Git-репозиторія
- 2.2 Запис змін до репозиторія
- 2.3 Перегляд історії комітів
- 2.4 Скасування речей
- 2.5 Взаємодія з віддаленими сховищами
- 2.6 Теґування
- 2.7 Псевдоніми Git
- 2.8 Підсумок
-
3. Галуження в git
- 3.1 Гілки у кількох словах
- 3.2 Основи галуження та зливання
- 3.3 Управління гілками
- 3.4 Процеси роботи з гілками
- 3.5 Віддалені гілки
- 3.6 Перебазовування
- 3.7 Підсумок
-
4. Git на сервері
- 4.1 Протоколи
- 4.2 Отримання Git на сервері
- 4.3 Генерація вашого публічного ключа SSH
- 4.4 Налаштування Серверу
- 4.5 Демон Git
- 4.6 Розумний HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Варіанти стороннього хостингу
- 4.10 Підсумок
-
5. Розподілений Git
-
6. GitHub
-
7. Інструменти Git
- 7.1 Вибір ревізій
- 7.2 Інтерактивне індексування
- 7.3 Ховання та чищення
- 7.4 Підписання праці
- 7.5 Пошук
- 7.6 Переписування історії
- 7.7 Усвідомлення скидання (reset)
- 7.8 Складне злиття
- 7.9 Rerere
- 7.10 Зневадження з Git
- 7.11 Підмодулі
- 7.12 Пакування
- 7.13 Заміна
- 7.14 Збереження посвідчення (credential)
- 7.15 Підсумок
-
8. Налаштування Git
-
9. Git and Other Systems
- 9.1 Git як клієнт
- 9.2 Міграція на Git
- 9.3 Підсумок
-
10. Git зсередини
- 10.1 Кухонні та парадні команди
- 10.2 Об’єкти Git
- 10.3 Посилання Git
- 10.4 Файли пакунки
- 10.5 Специфікація посилань (refspec)
- 10.6 Протоколи передачі
- 10.7 Супроводження та відновлення даних
- 10.8 Змінні середовища
- 10.9 Підсумок
-
A1. Додаток A: Git в інших середовищах
- A1.1 Графічні інтерфейси
- A1.2 Git у Visual Studio
- A1.3 Git в Eclipse
- A1.4 Git у Bash
- A1.5 Git у Zsh
- A1.6 Git у Powershell
- A1.7 Підсумок
-
A2. Додаток B: Вбудовування Git у ваші застосунки
- A2.1 Git з командного рядка
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
-
A3. Додаток C: Команди Git
- A3.1 Налаштування та конфігурація
- A3.2 Отримання та створення проектів
- A3.3 Базове збереження відбитків
- A3.4 Галуження та зливання
- A3.5 Поширення й оновлення проектів
- A3.6 Огляд та порівняння
- A3.7 Зневаджування
- A3.8 Латання (patching)
- A3.9 Електронна пошта
- A3.10 Зовнішні системи
- A3.11 Адміністрування
- A3.12 Кухонні команди
5.1 Розподілений Git - Розподілені процеси роботи
Тепер, коли ви маєте віддалений Git репозиторій, налаштований як центральне місце, де всі розробники можуть ділитись своїм кодом, та знайомі з базовими командами Git в локальному процесі роботи, ви дізнаєтесь як використовувати деякі розподілені робочі процеси, що Git надає вам.
В цьому розділі, ви побачите, як працювати з Git в розподіленому середовищі як учасник та інтегратор. Таким чином, ви дізнаєтесь, як успішно вносити код до проекту та зробити це якомога простішим для вас та супроводжувача, а також, як успішно супроводжувати проект з великою кількістю розробників.
Розподілені процеси роботи
На відміну від Централізованих Систем Керування Версіями (ЦСКВ), розподілена сутність Git дозволяє вам бути набагато більш гнучким щодо того, як розробники співпрацюють над проектами. У централізованих системах кожен розробник є одним з вузлів, які працюють більш менш на рівних над централізованим розподілювачем (hub). У Git, втім, кожен розробник є потенційно і вузлом, і сервером — тобто, кожен розробник може як надсилати код до інших репозиторіїв, як і супроводжувати публічний репозиторій, на якому інші можуть базувати свою роботу, та до якого вони можуть надсилати зміни. Це відкриває безмежні можливості процесу роботи для вашого проекту та/або вашої команди, отже розглянемо декілька поширених парадигм, щоб скористатись цією гнучкістю. Ми дізнаємось про переваги та можливі недоліки кожного методу; ви можете вибрати якийсь один, або змішати та сумістити елементи кожного.
Централізований процес роботи
У централізованих системах, взагалі існує єдина модель співпраці — централізований процес роботи. Один центральний розподілювач, або репозиторій, може приймати код, і всі синхронізують свою роботу з ним. Усі розробники є вузлами — споживачами цього розподілювача — та синхронізуються виключно з ним.
![Централізований порядок роботи.](png/centralized_workflow.png)
Це означає, що, якщо два розробники зроблять клон з розподілювача та обидвоє щось змінять, перший, хто надішле свої зміни назад, зможе це зробити без проблем. Другий розробник змушений зливати роботу першого до надсилання змін, щоб не переписати зміни першого розробника. Ця концепція працює в Git так само, як і в Subversion (чи будь-якій ЦСКВ), і ця модель чудово працює в Git.
Якщо ви вже звикли до централізованого процесу роботи в компанії чи команді, то можете безклопітно продовжувати його використовувати з Git. Просто налаштуйте окреме сховище, та надайте всім у вашій команді доступ на запис; Git не дозволить користувачам переписувати один одного. Припустимо, Джон та Джесіка обидвоє починають працювати одночасно. Джон завершує свою зміну та надсилає її до сервера. Потім Джесіка намагається надіслати свої зміни, проте сервер відхиляє їх. Їй повідомляють, що вона намагається надіслати зміни, що не є перемотуванням вперед, та їх не можна надсилати, доки вона не отримає та не зіллє зміни. Цей процес роботи є принадним для багатьох, адже ж ця парадигма багато кому знайома та зручна.
Вона також може використовуватись не лише маленькими командами. За допомогою моделі галуження Git, сотні розробників одночасно можуть її використовувати успішно для роботи над одним проектом за допомогою десятків гілок.
Процес роботи з менеджером інтеграції
Оскільки Git дозволяє вам мати декілька віддалених сховищ, можливо мати процес роботи, в якому кожен розробник має право на запис до власного публічного репозиторія та доступ на читання до репозиторіїв інших розробників. Цей сценарій зазвичай включає канонічне сховище, яке представляє “офіційний” проект. Щоб зробити внесок до такого проекту, треба створити власний публічний клон проекту та надіслати зміни до нього. Потім, ви можете надіслати запит до супроводжувача головного проекту, щоб він злив ваші зміни. Супроводжувач тоді може додати ваше сховище як віддалене, перевірити ваші зміни локально, злити їх до своєї гілки, та надіслати до свого репозиторія. Процес працює наступним чином (дивіться Процес роботи з менеджером інтеграції.):
-
Супроводжувач проекту надсилає зміни до свого власного репозиторія.
-
Розробник клонує цей репозиторій та робить зміни.
-
Розробник надсилає зміни до своєї власної публічної копії.
-
Розробник надсилає супроводжувачу листа, в якому просить злити його зміни.
-
Супроводжувач додає сховище розробника як віддалене та зливає зміни локально.
-
Супроводжувач надсилає злиті зміни до головного репозиторія.
![Процес роботи з менеджером інтеграції.](png/integration-manager.png)
Це дуже поширений процес роботи для інструментів, що базуються на розподілювачах, таких як GitHub та GitLab, в яких дуже легко створити форк проекту та надсилати до нього зміни, які всі можуть бачити. Однією з головних переваг цього підходу є те, що ви можете продовжувати працювати, а супроводжувач головного репозиторія може злити ваші зміни будь-коли. Розробники не змушені чекати на проект, щоб вбудувати свої зміни — кожна сторона може працювати у своєму власному темпі.
Процес роботи з диктатором та лейтенантами
Це варіація процесу роботи з багатьма репозиторіями. Зазвичай він використовується у величезних проектах з сотнями учасників: одним славетним прикладом є ядро Linux. Різноманітні менеджери інтеграції відповідають за окремі частини репозиторія; їх називають лейтенантами. Всі лейтенанти мають одного менеджера інтеграції, відомого як доброзичливий диктатор. Доброзичливий диктатор надсилає зміни зі свого сховища до зразкового сховища, з якого всі розробники мають отримувати зміни. Процес працює наступним чином (дивіться Процес роботи з доброзичливим диктатором.):
-
Звичайні розробники працюють у власній тематичній гілці та перебазовують свою роботу поверх
master
. Тієї взірцевої гілкиmaster
, до якої диктатор надсилає зміни. -
Лейтенанти зливають тематичні гілки розробників до власних гілок
master
. -
Диктатор зливає гілки лейтенантів
master
до гілки диктатораmaster
. -
Нарешті, диктатор надсилає цю гілку
master
до зразкового репозиторія, щоб інші розробники могли перебазуватись поверху неї.
![.Процес роботи з доброзичливим диктатором.](png/benevolent-dictator.png)
Такий процес роботи не є поширеним, проте може бути корисним у дуже великих проектах, або в дуже ієрархічних середовищах. Він дозволяє керівнику проекту (диктатору) делегувати чимало праці та збирати великі частини коду з декількох місць перед тим, як інтегрувати їх.
Підсумок щодо процесів роботи
Це деякі широковживані процеси роботи, які можливі в розподілених системах, таких як Git, проте, як ви бачите, існує багато можливостей, щоб влаштувати реальний процес роботи саме для вас. Тепер, коли ви (сподіваємось) можете визначити, яка комбінація процесів роботи спрацює для вас, ми розглянемо більш конкретні приклади того, як досягнути головних ролей, необхідних для різноманітних процесів. У наступній секції ви дізнаєтесь про декілька поширених шаблонів внесення змін до проекту.