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

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

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

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

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

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

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

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

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

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