Компоненти потоку GitHub

Завершено

У цій одиниці ми переглядаємо такі компоненти потоку GitHub:

• Відділень
• Здійснює
• Запити на витяг
• Потік GitHub
• Git flow

Компоненти GitHub Flow

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

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

Що таке гілки

В останньому розділі ми створили новий файл і нову гілку у вашому репозиторії.

Гілки є невід'ємною частиною роботи з GitHub. Вони дозволяють вносити зміни, не впливаючи на гілку за замовчуванням.

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

Примітка

Крім того, ви можете створити нову гілку та взяти її на редагування за допомогою git у терміналі. Команда буде git checkout -b newBranchName

Що таке коміти

У попередній одиниці ви додали новий файл до сховища, натиснувши кнопку коміт. Давайте коротко розглянемо, що таке коміти.

зробити – це зміна одного або кількох файлів у гілці. Кожен коміт відстежується за унікальним ID, часовою позначкою та учасником, незалежно від того, чи зроблено це через командний рядок, чи безпосередньо у веб-інтерфейсі GitHub. За допомогою функції "Зобов'язання" можна очистити контрольний слід для всіх користувачів, які переглядають журнал файлу або зв'язаного елемента, наприклад запит на вирішення проблеми або витягнення.

Ви можете створити коміт за допомогою Git у вашому терміналі за допомогою:

git commit -m "Add a helpful commit message"

У репозиторії git файл може існувати в кількох припустимих станах, оскільки він проходить процес керування версіями. Основними станами для файлу в сховищі Git є Untracked і Tracked.

Untracked: Початковий стан файлу, коли він ще не входить до сховища Git. Git не знає про своє існування.

Tracked: Відстежуваний файл – це той, який Git активно відстежує. Це може бути одна з таких підстанцій:

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

Ці стани допомагають вашій команді зрозуміти стан кожного файлу та його місце в процесі контролю версій.

Що таке запити на витяг

Запит на витягнення – це механізм, який використовується для сигналу про те, що коміти з однієї гілки готові до об'єднання в іншу гілку.

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

GitHub також підтримує чернетки запитів на злиття, які дозволяють вам відкривати запити на злиття, які ще не готові до розгляду.

Коли зміни буде схвалено (за потреби), вихідна гілка запиту на витягування (гілка порівняння) об'єднується в базову гілку.

Тепер, коли ви побачили, як працюють гілки, коміти та запити на злиття, давайте розглянемо, як вони поєднуються в GitHub Flow.

Потік GitHub

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

Примітка

GitHub flow — один із кількох популярних бізнес-процесів. Інші включають Git flow та розробку на основі trunk.

Тепер, коли ми знаємо основи GitHub, ми можемо пройти через потік GitHub і його компоненти.

1. Почніть зі створення гілки, щоб ваші зміни, функції або виправлення не вплинули на основну гілку.
2. Далі внесіть свої оновлення у гілку. Якщо ваш робочий процес підтримує це, ви можете розгорнути зміни з цієї гілки, щоб перевірити їх перед об'єднанням.
3. Тепер відкрийте запит на злиття, щоб запросити відгук і почати рецензування.
4. Потім перегляньте коментарі та внесіть необхідні оновлення на основі відгуків вашої команди.
5. Нарешті, як тільки ви будете впевнені у своїх змінах, отримайте схвалення та об'єднайте запит на пул з основною гілкою.
6. Після цього видаліть гілку, щоб підтримувати ваш репозиторій у чистоті та уникати використання застарілих гілок.

Git flow

У той час як GitHub Flow — це легкий робочий процес, призначений для безперервної доставки, Git flow — це більш структурована модель розгалуження, яка часто використовується в середовищах, керованих релізами. Git flow існує довше, ніж GitHub Flow, і ви все ще можете побачити, що цей термін master використовується замість main гілки за замовчуванням.

Зображення Вінсента Дріссена, з «A successful git branching model»

Типи гілок Git flow

Git flow використовує кілька довгоживучих і тимчасових відгалужень:

• master: Завжди відображає готовий до виробництва код.
• develop: містить найновіші роботи з розробки для наступного випуску.
• feature/*: Використовується для створення нових функцій; розгалужується develop і об'єднується назад після завершення.
• release/*: Готує новий продакшн-реліз від develop; дозволяє провести остаточне тестування та виправити незначні помилки.
• hotfix/*: використовується для швидкого виправлення проблем з продакшн; розгалужується від master.

Як працює процес потоку Git

1. Розробники створюють гілки функцій для develop створення нових функціональних можливостей.
2. Коли настає час релізу, гілка релізу створюється з developфайлу . Це ізолює роботу з підготовки релізу, щоб розробка могла тривати безперебійно.
3. Виправлення помилок можна додавати до гілки релізу, але основні функції слід почекати з майбутнім релізом.
4. Після готовності гілка релізу об'єднується з номером master версії та позначається ним. GitHub може використовувати ці теги для створення приміток до випуску.
5. Ту саму гілку релізу слід об'єднати назад, develop щоб підтримувати її синхронізацію.
6. Якщо виникає критична помилка у виробництві, гілка hotfix створюється з master. Після виправлення він об'єднується з обома master та develop.

Коли використовувати Git flow

• Найкраще підходить для проєктів із запланованими або версіями релізів
• Корисно, якщо ви підтримуєте кілька продакшн-версій (наприклад, гілки довготривалої підтримки)
• Ідеально підходить для повільних, більш структурованих циклів розробки (наприклад, корпоративних або регульованих середовищ)
• Вважається більш "важковаговиком", ніж GitHub Flow через додаткове управління гілками

Примітка

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

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

Congratulations! Ви щойно ознайомилися з повним GitHub Flow — і дослідили, як Git flow пропонує структуровану альтернативу для проєктів, орієнтованих на релізи.

Перейдемо до наступного розділу, де ми розглянемо відмінності між питаннями та обговореннями.