Що таке GitHub Flow?

Іспанська версія буде скоро!

Якби GitHub Flow мав логотип, це був би він. Дизайн від мене.

Привіт, давайте поговоримо про те, що, ймовірно, на вашому розумі, якщо ви працюєте в програмному забезпеченні чи даних — швидкість і гнучкість. Ми всі знаємо, що вони необхідні, так? Ось тут і з'являється GitHub Flow.

У цій статті ми розглянемо:

1. Вступ
2. Походження GitHub Flow
3. Основні принципи GitHub Flow
4. Цикл GitHub Flow
5. Основні Git команди для GitHub Flow
6. Застосування GitHub Flow у командах по роботі з даними
7. GitHub Flow vs. Gitflow: Ключові відмінності
8. Поради при роботі з GitHub Flow
9. Кращі практики для GitHub Flow
10. Висновок

Готові? Почнемо!

1. Вступ

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

На відміну від більш складних робочих процесів, GitHub Flow створено для команд, які часто випускають код, навіть кілька разів на день, усуваючи необхідність у формальних "релізах" і сприяючи чіткому, узгодженому процесу управління змінами. І це може бути чудовою зміною після кошмарів, які ми всі переживали через конфлікти злиття.

2. Походження GitHub Flow

Ви знаєте, GitHub Flow не з'явився з нізвідки. Його було представлено GitHub ще в 2011 році. І велике спасибі Скотту Чейкону, одному з засновників GitHub. Він був важливою фігурою в спільноті Git і допоміг зробити цей робочий процес простішим і легким у порівнянні з такими, як Gitflow. Він був створений спеціально для GitHub і для команд, які хочуть бути більш гнучкими. Цей процес відображає мету GitHub зробити контроль версій більш доступним та ефективним для команд будь-якого розміру.

3. Основні принципи GitHub Flow

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

• main завжди готова до розгортання: Уявіть свою основну гілку як єдине джерело правди, яке містить код, готовий до продакшн-розгортання, який або вже розгорнутий, або готовий до розгортання протягом кількох годин. Це ваша стабільна база для всього, і часто вона захищається правилами, які не дозволяють здійснювати прямі пуші.
• Розробка на основі функцій: Усі нові роботи, будь то функція, виправлення помилки або навіть просто експеримент, розробляються у короткоживучих гілках з описовими назвами, створених безпосередньо з main. Це дозволяє ізолювати і організовувати вашу роботу, діючи як незалежне робоче середовище.
• Безперервна інтеграція: Розробники регулярно пушать зміни в свої гілки. Це не лише резервні копії; це дозволяє зробити вашу роботу видимою для команди та дозволяє безперервну інтеграцію та співпрацю.
• Спільний код-рев'ю: Зміни в коді перевіряються та обговорюються через pull request. Це більше ніж просто огляд; це розмова, місце для зворотного зв'язку, співпраці та обміну знаннями. Pull request є основним механізмом для перевірки коду та співпраці в команді.
• Підтвердження перед злиттям: Затверджені pull request зливаються в main лише після підтвердження членом команди. Це гарантує якість коду, консенсус команди і те, що код пройшов всі перевірки.
• Негайне розгортання: Зміни в main негайно розгортаються в продакшн, часто через автоматизований процес. Це забезпечує швидкий зворотний зв'язок, щоб ви могли швидко побачити зміни в дії.

4. Цикл GitHub Flow

Цикл GitHub Flow. Зображення створене автором цієї статті.

Тепер давайте пройдемося по циклу GitHub Flow.
Це простий, повторюваний процес, який допоможе вам у розробці:

• Гілкування: Коли ви починаєте нову роботу, створюйте нову гілку безпосередньо з main з описовою назвою (наприклад, feature/user-auth, fix/login-error, experiment/new-algorithm, docs/update-readme). Використовуйте такі конвенції іменування, як feature/, fix/, hotfix/, і docs/ для збереження ясності та організації. Почніть з того, щоб переконатися, що ви на останньому main:

git checkout main  
git pull origin main  
git checkout -b 

• Розробка: Працюйте над своїми змінами, роблячи атомарні коміти з чіткими, описовими повідомленнями. Добре використовувати консистентний формат, наприклад, fix: handle null values in customerid transformation_. І не забудьте постійно пушити на сервер, щоб забезпечити резервні копії та видимість для команди. Це робить зрозумілим, над чим ви працюєте.
• Pull Request: Коли ваша робота готова до перевірки, відкрийте pull request, щоб з'єднати вашу гілку функцій з main. Обов'язково включіть чіткий заголовок, що описує зміну, детальний опис того, що зміни досягають, посилання на відповідні проблеми/квитки та будь-які відповідні результати тестування чи аналіз впливу.
• Огляд і ітерація: Члени команди перевіряють ваш pull request, надаючи зворотний зв'язок та пропозиції безпосередньо на коді, комітах чи самому pull request. Як автор, враховуйте відгуки, роблячи додаткові коміти в ту саму гілку. CI інструменти автоматично виконують тести для перевірки ваших змін.

git add .  
git commit -m "fix: address PR feedback for null handling"  
git push origin feature/add-new-transformation

• Злиття: Після того, як коментарі будуть затверджені (часто з коментарем “+1” або “:shipit:”), і всі тести пройшли, злийте ваш pull request в main. Зазвичай краще використовувати “Squash and Merge” для підтримки чистої та легко читабельної історії.
• Розгортання: Наприкінці розгорніть зміни з main в продакшн, часто через автоматизований процес. Переконайтеся, що CI/CD проходять і вирішуйте конфлікти перед розгортанням.

5. Основні Git команди для GitHub Flow

Окей, тепер ви знаєте процес, але що щодо команд? Ось основні команди Git, які ви будете використовувати для реалізації GitHub Flow:

• Створити гілку:

git checkout -b  main

• Комітити зміни:

git add .  
git commit -m "Your commit message"

• Пушити зміни:

git push origin 

• Відкрити Pull Request: (Це ви робите через веб-інтерфейс вашої платформи Git хостингу)
• Злити Pull Request: (Також робиться через веб-інтерфейс вашої платформи Git хостингу)
• Розгортати: (Зазвичай це робиться через CI/CD pipeline)

6. Застосування GitHub Flow в Data Teams

GitHub Flow не тільки для традиційної розробки програмного забезпечення; він також дуже корисний у таких сферах, як інженерія даних та наука про дані, де він може використовуватися для керування:

• ETL скриптами та даними pipeline
• Моделями даних та схемами
• Конфігураційними файлами для інфраструктури даних
• Моделями машинного навчання
• Скриптами для дослідження та аналізу даних
• Відслідковуванням експериментів та оцінкою коду

Однак як інженерія даних, так і наука про дані часто стикаються з унікальними викликами, які вимагають адаптації стандартного процесу GitHub Flow:

• Довші гілки для функцій: Скрипти інженерії даних та pipeline, а також експерименти в науці про дані та розробка моделей можуть займати більше часу для розробки та оптимізації, що призводить до того, що гілки функцій можуть існувати більше ніж один чи два дні. Це часто зумовлено необхідністю точного налаштування перетворень даних, перевірки якості даних, інтеграції з різними джерелами даних чи дослідженням різних підходів до моделювання.
• Автоматизоване тестування та GitHub Flow: Автоматизоване тестування є важливим для pipeline даних та розгортання моделей, і це основа успішної реалізації GitHub Flow. Переконайтеся, що у вас є ретельні юніт-тести, інтеграційні тести та тести якості даних, які автоматично виконуються на ваших гілках функцій перед їх злиттям в main.
  Це особливо важливо, якщо ваші гілки функцій стають довговічними, оскільки це допомагає виявляти помилки на ранніх етапах і запобігає тому, щоб нестабільний код потрапляв в основну гілку.
• Валідація даних і GitHub Flow: Не просто тестуйте ваші скрипти; тестуйте самі дані. Впровадьте перевірки валідації даних у ваші гілки функцій, щоб переконатися, що ваші pipeline генерують точні та надійні дані, і що ваші моделі тренуються на валідних даних перед злиттям в main. Це критично важливо, оскільки проблеми з якістю даних можуть викликати тонкі помилки, які важко виявити пізніше, що може підривати стабільність вашої основної гілки і вимагати додаткових "гарячих виправлень". Перевіряючи дані в рамках ваших гілок функцій, ви гарантуєте, що тільки надійні і перевірені зміни інтегруються в основну кодову базу, що відповідає принципу GitHub Flow — наявності гілки, готової до розгортання.
• Співпраця і GitHub Flow: Тісна співпраця між інженерами даних і науковцями про дані є ключовою для успішної реалізації GitHub Flow. У контексті гілок функцій та pull requests, інженери даних можуть допомогти науковцям про дані з найкращими практиками Git, якістю коду та стратегіями розгортання, забезпечуючи, щоб їхні зміни були добре інтегровані та готові до розгортання. У свою чергу, науковці про дані можуть надати цінну інформацію щодо вимог до даних та бізнес-логіки, забезпечуючи, щоб пропоновані зміни відповідали цілям проєкту. Цей колаборативний підхід, який полегшується процесом pull request в GitHub Flow, забезпечує, щоб зміни були добре зрозумілі, ретельно перевірені та сприяли створенню більш надійної основної гілки.
• Управління конфігураціями: Дані pipeline і моделі машинного навчання часто вимагають великої кількості налаштувань. Використовуйте Git для версійного контролю ваших конфігураційних файлів і застосовуйте такі техніки, як змінні середовища або конфігураційні файли для керування різними налаштуваннями для різних середовищ (розробка, тестування, продакшн).
• Ресурсомісткі завдання: Якщо науковець працює над гілкою функцій, яка потребує навчання моделі, ця гілка може залишатися відкритою протягом тривалого часу, що суперечить ідеї короткоживучих гілок.
• Відслідковування експериментів: Для проєктів з науковими дослідженнями даних використовуйте Git для відслідковування ваших експериментів, включаючи код, дані та параметри моделей. Розгляньте використання таких інструментів, як MLflow або DVC, для більш ефективного керування вашими експериментами та моделями.

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

Інженери даних, коли їх називають програмістами, можуть відчувати, що їхній досвід роботи з даними не оцінюють по заслугах.

7. GitHub Flow vs. Gitflow: Ключові відмінності

Давайте швидко порівняємо GitHub Flow і Gitflow, щоб ви могли побачити відмінності:

GitHub Flow vs. Gitflow: Ключові відмінності. Таблиця, підготовлена автором цієї статті.

• Складність: GitHub Flow простіший і легший. Він уникає накладних витрат, пов'язаних з кількома довговічними гілками, що робить його легшим для вивчення та впровадження. Gitflow, з іншого боку, складніший і може бути важче керувати, з більшою кількістю кроків, які потрібно запам'ятати.
• Гілкування: GitHub Flow використовує лише гілки функцій і main, тоді як Gitflow використовує кілька довговічних гілок, таких як develop, release і hotfix, що може призвести до більш складного злиття та інтеграції.
  Ця простота є перевагою GitHub Flow.
• Управління релізами: GitHub Flow не має явних гілок для релізів, оскільки розгортання здійснюється безпосередньо з main, що сприяє безперервному доставлянню. Gitflow, на відміну від цього, розроблений для формальних релізів, що може уповільнити процес розробки.
• Фокус на CI/CD: GitHub Flow більше орієнтований на безперервну інтеграцію та доставку, що робить його ідеальним для команд, які часто розгортають код. Gitflow, хоча і може використовуватися з CI/CD, не такий підходящий для цього підходу через більш складну модель гілкування, яка вимагає формального процесу релізів для інтеграції змін.

8. Поради при роботі з GitHub Flow

З мого досвіду ось кілька практичних порад, щоб GitHub Flow працював ще краще:

• Життєвий цикл гілки: Залишайте гілки короткоживучими (максимум 1–3 дні) і регулярно синхронізуйте з main, щоб уникнути великих конфліктів злиття. Це добра звичка.

git checkout feature/add-new-transformation  
git fetch origin  
git rebase origin/main

• Вирішення конфліктів: Коли виникають конфлікти, не панікуйте! Ось хороший підхід для їх вирішення:

git checkout main  
git pull origin main  
git checkout feature/add-new-transformation  
git rebase main   
# Вирішення конфліктів  
git add .  
git rebase --continue  
git push origin feature/add-new-transformation -f

• Екстрені виправлення: Для тих моментів "ой ні!" у продакшн, використовуйте окрему гілку для виправлень:

git checkout main  
git checkout -b hotfix/fix-data-corruption   
# Внесення виправлень   
git push origin hotfix/fix-data-corruption  
# Створення PR з позначкою термінового

9. Кращі практики для GitHub Flow

• Ніколи не переписуйте публічну історію (уникайте примусових push в main). Це може викликати хаос для інших розробників.
• Пишіть детальні описи до PR (майбутній ви подякуєте собі, і ваші колеги теж!).
• Використовуйте шаблони для PR, щоб стандартизувати процес. Це може зробити ваш робочий процес більш узгодженим і прозорим.
• Налаштуйте автоматизовані тести та linting для раннього виявлення помилок, перш ніж вони стануть серйозними проблемами.
• Налаштуйте правила захисту гілок, щоб уникнути випадкових змін в main гілці. Ви хочете, щоб вона була захищена.
• Використовуйте змістовні повідомлення до комітів, дотримуючись єдиного формату. Це допоможе всім зрозуміти зміни в історії комітів.

10. Висновок

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

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

Дякую за читання.

Хочете більше статей?

[

Що таке Gitflow?

Як почати використовувати

davidregalado255.medium.com

](/what-is-gitflow-b3396770cd42?source=post_page-----49fdda7be1b1--------------------------------)

[

Як почати використовувати Git

Практичний посібник для команд

davidregalado255.medium.com

](/how-to-get-started-with-git-0dd1eeae2ad9?source=post_page-----49fdda7be1b1--------------------------------)

[

Що таке DevOps і чому це важливо?

Знайомтесь з DORA (Дослідження та оцінка DevOps від Google Cloud)

davidregalado255.medium.com

](/what-the-heck-is-devops-and-why-does-it-matters-13d5a0969909?source=post_page-----49fdda7be1b1--------------------------------)

[

Що робить вас чудовим Data Engineer?

Основні аспекти, щоб виділятися

davidregalado255.medium.com

](/what-makes-you-a-great-data-engineer-13d6302dd931?source=post_page-----49fdda7be1b1--------------------------------)

Що? Хочете ще більше?

Авенджери: Фінал. Кредити: Walt Disney Studios Motion Pictures

Натискайте кнопку 👏 50 разів і залиште коментар, якщо ви хочете, щоб я писав більше про стратегії гілкування, git, програмну інженерію або інженерію даних.

• Слідкуйте за David Regalado для отримання додаткового освітнього контенту та іншого!

Перекладено з: What is GitHub Flow?