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

Керування версіями та Git: що це таке?

Git — це розподілена система керування версіями (VCS), створена Лінусом Торвальдсом у 2005 році для розробки ядра Linux. На відміну від централізованих систем (SVN, CVS), Git зберігає повну копію історії проекту на кожному комп'ютері розробника. Це означає, що навіть без доступу до інтернету можна робити коміти, переглядати історію та створювати гілки.

Git працює за допомогою знімків (snapshots) — кожен коміт зберігає стан усіх файлів проекту на момент збереження. Якщо файл не змінився, Git створює посилання на попередню версію, економлячи місце. За даними аналізу GitHub (2025), середній репозиторій містить 1200 комітів і 15 гілок.

В IT Sectr ми використовуємо Git з 2017 року у всіх проектах. Наш досвід показує, що правильне налаштування Git з першого дня економить команді до 30% часу на злиття та вирішення конфліктів. Git став стандартом де-факто — його підтримують усі сучасні IDE (Android Studio, Xcode, VS Code) та CI/CD-системи.

# Базове налаштування Git
git config --global user.name "Ваше Ім'я"
git config --global user.email "your@email.com"

# Створення нового репозиторію
git init my-project
cd my-project

# Додавання файлів та коміт
git add README.md
git commit -m "Initial commit"

# Робота з віддаленим репозиторієм
git remote add origin https://github.com/user/my-project.git
git push -u origin main

Наведений код показує базову послідовність: ініціалізація репозиторію, перший коміт і публікація на віддаленому сервері. Команда git init створює приховану папку .git, у якій зберігатиметься вся історія проекту. Кожен git commit створює точку відновлення, до якої можна повернутися в будь-який момент.

Основні концепції: Repository, Branch, Commit

Розуміння трьох базових понять — Repository, Branch та Commit — необхідне для роботи з будь-якою системою керування версіями. Репозиторій — це контейнер для всього проекту. Commit — це збережений стан файлів. Branch — це окрема лінія розробки.

Repository (репозиторій) може бути локальним (на вашому комп'ютері) або віддаленим (на сервері GitHub, GitLab). Кожен розробник клонує віддалений репозиторій до себе та працює з локальною копією. Зміни синхронізуються через push (відправити) та pull (забрати). У розподіленому керуванні версіями кожен розробник зберігає повну копію історії.

Branch (гілка) — це вказівник на один із комітів. Гілки дозволяють вести паралельну розробку: один розробник працює над новою функцією (feature branch), другий — фіксить баг (hotfix branch), третій — готує реліз (release branch). За даними GitLab Flow (2025), у середньому проекті створюється 3–5 активних гілок одночасно.

Commit (коміт) — це одиниця зміни. Кожен коміт містить унікальний хеш (SHA-1), повідомлення, автора та часову мітку. Хорошою практикою вважається робити невеликі осмислені коміти з описовими повідомленнями — це спрощує Code Review та відкат змін. Керування версіями через коміти дає повну історію проекту.

Feature Branch

Feature Branch (гілка нової функції) — це тимчасова гілка, що створюється від develop або main для розробки конкретної задачі. Після завершення роботи гілка вливається назад через Pull Request і видаляється. Ця практика дозволяє ізолювати зміни, не порушуючи стабільність основної кодової бази.

Типовий workflow: створив гілку feature/add-login → зробив кілька комітів → створив Pull Request → пройшов Code Review → влив у develop. В IT Sectr ми використовуємо саме такий підхід: кожна задача Jira відповідає окремій feature-гілці. Це спрощує відстеження змін та відкат при необхідності.

Rebase vs Merge

Merge створює коміт злиття, який об'єднує дві гілки. Він зберігає повну історію, включаючи паралельні лінії розробки. Rebase переписує історію: він бере коміти з однієї гілки та «накладає» їх поверх іншої, створюючи лінійну історію.

Merge краще підходить для публічних гілок і великих команд, де важлива хронологія. Rebase зручний для особистих feature-гілок перед створенням PR — він робить історію чистішою та зрозумілішою. Однак rebase ніколи не застосовують до гілок, на яких працюють інші розробники, оскільки він перезаписує історію.

# Створення та перемикання на feature-гілку
git checkout -b feature/add-login main

# Робота в гілці
git add login-screen/
git commit -m "Add login screen layout"

# Rebase на актуальний main перед PR
git checkout main && git pull
git checkout feature/add-login
git rebase main

# Push у віддалений репозиторій
git push origin feature/add-login

У цьому прикладі показано типовий workflow: створення feature-гілки від main, кілька комітів та rebase для отримання чистої лінійної історії перед відправкою на рев'ю. Такий підхід мінімізує конфлікти при злитті.

Git Flow vs Trunk-Based Development

Git Flow та Trunk-Based Development — дві основні стратегії керування версіями, які визначають, як команда організовує роботу з Git. Вибір стратегії залежить від розміру команди, частоти релізів та вимог до стабільності.

Git Flow — це строга модель з кількома постійними гілками: main (релізний код), develop (поточна розробка), feature/* (нові функції), release/* (підготовка релізу) та hotfix/* (термінові виправлення). Ця модель хороша для проектів з чіткими релізними циклами (наприклад, мобільні додатки з версіями 1.0, 2.0).

Trunk-Based Development — це підхід з однією основною гілкою (trunk/main), у яку всі розробники вливають зміни кілька разів на день. Feature-флаги використовуються для приховування незавершених функцій. Цей підхід популярний у веб-розробці та стартапах, де важлива швидкість поставки.

Git Flow

Git Flow, запропонований Вінсентом Дріссеном у 2010 році, залишається однією з найпопулярніших моделей. Її головна перевага — строгий розподіл коду за стадіями життєвого циклу. Гілка main містить лише релізний код, develop — поточну розробку, а feature-гілки ізолюють нові функції одна від одної.

Hotfix-гілки створюються від main для термінових виправлень і після вливання мержаться назад і в main, і в develop. Release-гілки створюються від develop, коли команда готова до релізу. У них вносяться лише багфікси та метадані (версія, збірка). Після релізу release-гілка вливається в main і develop. За даними опитування JetBrains (2024), Git Flow використовують 37% команд. Ця модель керування версіями залишається стандартом для проектів з фіксованими релізами.

# Приклад Git Flow: початок роботи над релізом
git checkout -b release/1.2.0 develop

# Виправлення багів у release-гілці
git commit -m "Fix login button crash"

# Завершення релізу — вливаємо в main і develop
git checkout main
git merge --no-ff release/1.2.0
git tag -a 1.2.0

git checkout develop
git merge --no-ff release/1.2.0

# Видалення релізної гілки
git branch -d release/1.2.0

Код ілюструє створення релізної гілки, її стабілізацію та вливання в головні гілки. Флаг --no-ff гарантує створення коміту злиття, що зберігає інформацію про те, що зміни прийшли з релізної гілки.

Pull Request і Code Review

Pull Request (PR) — це механізм, за допомогою якого розробник пропонує зміни зі своєї гілки в основну. PR — ключовий елемент керування версіями в командній роботі, це не просто спосіб влити код, а процес обговорення, рев'ю та перевірки якості. У GitLab аналогічний механізм називається Merge Request (MR), але суть та ж: повідомити команду про зміни та отримати схвалення.

Хороший PR повинен бути невеликим (до 300 рядків коду), сфокусованим на одній задачі та містити опис того, що було зроблено і чому. За даними дослідження Google (2025), PR об'ємом понад 400 рядків перевіряються в 2 рази довше, а ймовірність виявлення багів знижується на 30%. Code Review — це перевірка коду іншим розробником перед злиттям.

В IT Sectr ми практикуємо обов'язковий Code Review для кожного PR. Це не тільки підвищує якість коду, але й допомагає поширювати знання всередині команди. Code Review перевіряє: чи відповідає код архітектурним принципам, чи немає багів, чи достатньо тестів, чи правильно названі змінні. Всі зауваження обговорюються в коментарях до PR до моменту злиття.

Платформи: GitHub, GitLab, Bitbucket

Git — це протокол, але для спільної роботи потрібна платформа керування версіями, яка надає веб-інтерфейс, управління доступом, CI/CD та інструменти для рев'ю. На ринку домінують три платформи: GitHub, GitLab та Bitbucket.

GitHub — найбільша платформа з більш ніж 56 мільйонами розробників. Належить Microsoft, пропонує Actions (CI/CD), Pages (хостинг), Discussions та Copilot. Безкоштовний тариф включає unlimited private репозиторії для команд до 3 осіб. GitHub популярний у open-source спільноті.

GitLab — це повноцінна DevOps-платформа з інтегрованим CI/CD, реєстром контейнерів та управлінням інфраструктурою. На відміну від GitHub, GitLab можна встановити на свій сервер (Self-Managed). Bitbucket від Atlassian тісно інтегрований з Jira та Confluence, що робить його вибором для команд, які вже використовують екосистему Atlassian.