Git

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

Git дозволяє розробникам працювати з гілками, створювати commits, об’єднувати зміни, переглядати історію, повертатися до попередніх версій, виконувати code review і спільно працювати над програмним забезпеченням.

Важливо: Git — це не хмарний сервіс і не сайт. Git — це система контролю версій. GitHub, GitLab, Bitbucket або Azure DevOps — це сервіси, які можуть зберігати Git-репозиторії та додавати інструменти для командної роботи.

Загальний опис

Git використовується для керування змінами у файлах проєкту. Кожна зміна може бути зафіксована у вигляді commit. Commit містить інформацію про те, які файли були змінені, хто зробив зміну, коли вона була зроблена і з яким повідомленням.

На відміну від централізованих систем контролю версій, Git є розподіленою системою. Це означає, що кожен розробник має локальну копію репозиторію з історією змін. Розробник може створювати commits, переглядати історію, створювати гілки та працювати локально навіть без постійного підключення до центрального сервера.

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

Зверніть увагу: Git зберігає історію змін, але сам по собі не гарантує якість коду. Для цього потрібні code review, тести, CI/CD, правила роботи з гілками та дисципліна команди.

Для чого потрібен Git

Git потрібен для контролю змін у проєкті.

Основні задачі Git:

зберігання історії змін;
робота з гілками;
спільна розробка;
об’єднання змін різних розробників;
перегляд різниці між версіями;
повернення до попереднього стану;
пошук автора зміни;
підготовка релізів;
робота з pull request або merge request;
підтримка code review;
зв’язок задач із commit;
автоматизація CI/CD;
контроль версій конфігурацій та інфраструктури.

Основні поняття Git

Repository

Repository або репозиторій — це сховище проєкту, яке містить файли та історію змін.

Репозиторій може бути:

локальним;
віддаленим;
приватним;
публічним;
основним;
форком;
дзеркалом.

Локальний репозиторій знаходиться на комп’ютері розробника. Віддалений репозиторій зазвичай знаходиться на сервері або сервісі, наприклад GitHub, GitLab, Bitbucket або Azure DevOps.

Commit

Commit — це зафіксований набір змін. Commit має унікальний ідентифікатор, автора, дату, повідомлення та список змінених файлів.

Добрий commit має бути логічно завершеним і зрозумілим.

Приклади повідомлень commit:

Add LiqPay payment callback validation
Fix duplicate Shopify order import
Update PRRO fiscalization error handling

Branch

Branch або гілка — це окрема лінія розробки. Гілки дозволяють працювати над новими функціями, виправленнями або експериментами без зміни основної стабільної версії.

Типові гілки:

main;
master;
develop;
feature;
bugfix;
hotfix;
release.

Merge

Merge — це об’єднання змін з однієї гілки в іншу.

Наприклад, після завершення роботи над feature-гілкою її можна об’єднати з develop або main.

Rebase

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

Remote

Remote — це віддалений репозиторій, з яким синхронізується локальна копія.

Найчастіше основний remote називається:

origin

Практичне застосування: Git дозволяє кожному розробнику працювати у власній гілці, не заважаючи іншим, а потім безпечно об’єднувати зміни після перевірки.

Основні команди Git

git init

Команда створює новий Git-репозиторій у поточній директорії.

git init

git clone

Команда копіює віддалений репозиторій на локальний комп’ютер.

git clone https://example.com/project.git

git status

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

git status

git add

Команда додає зміни до staging area.

git add file.txt

Додати всі зміни:

git add .

git commit

Команда створює commit із підготовлених змін.

git commit -m "Add order import from Shopify"

git log

Команда показує історію commits.

git log

Скорочений вигляд:

git log --oneline

git diff

Команда показує різницю між файлами або версіями.

git diff

git branch

Команда показує список гілок.

git branch

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

git branch feature/liqpay-callback

git checkout

Команда перемикає гілку або відновлює файл.

git checkout feature/liqpay-callback

git switch

Сучасніша команда для перемикання гілок.

git switch feature/liqpay-callback

Створити і одразу перейти на гілку:

git switch -c feature/liqpay-callback

git merge

Команда об’єднує зміни з іншої гілки.

git merge feature/liqpay-callback

git pull

Команда отримує зміни з віддаленого репозиторію і застосовує їх до локальної гілки.

git pull

git push

Команда відправляє локальні commits у віддалений репозиторій.

git push

Для нової гілки:

git push -u origin feature/liqpay-callback

Робоча область Git

У Git є кілька важливих станів файлів.

Область	Що означає
Working directory	Поточні файли на комп’ютері розробника
Staging area	Підготовлені зміни, які увійдуть у наступний commit
Local repository	Локальна історія commits
Remote repository	Віддалений репозиторій на сервері

Типовий шлях зміни:

Розробник змінює файл.
Команда git status показує зміну.
Команда git add додає зміну в staging area.
Команда git commit створює commit.
Команда git push відправляє commit у віддалений репозиторій.

Для розробника: staging area дозволяє вибрати, які саме зміни потраплять у commit. Це допомагає робити commits чистішими і логічнішими.

Гілки в Git

Гілки є однією з найважливіших можливостей Git. Вони дозволяють вести паралельну розробку.

Типові сценарії:

розробка нової функції;
виправлення помилки;
підготовка релізу;
терміновий hotfix;
експеримент;
оновлення залежностей;
розробка інтеграції;
рефакторинг.

Приклад створення гілки для задачі:

git switch -c feature/k2-shopify-order-import

Branch naming

Назви гілок бажано стандартизувати.

Приклади:

feature/k2-shopify-order-import
bugfix/duplicate-prom-orders
hotfix/prro-shift-close-error
release/1.8.0
task/update-saf-t-export

У командній роботі можна додавати ID задачі:

feature/K2-1542-liqpay-callback
bugfix/K2-1608-prro-duplicate-check

Pull request і merge request

Pull request або merge request — це запит на об’єднання змін з однієї гілки в іншу.

У pull request команда може:

переглянути код;
залишити коментарі;
запустити CI/CD;
перевірити тести;
перевірити зміни в документації;
погодити або відхилити зміни;
об’єднати гілку після перевірки.

Інтеграційний акцент: pull request бажано пов’язувати із задачею в YouTrack, а CI/CD у TeamCity має автоматично перевіряти збірку і тести перед merge.

Code review

Code review — це перевірка коду іншими учасниками команди перед об’єднанням у основну гілку.

Під час code review перевіряють:

коректність логіки;
читабельність коду;
відповідність архітектурі;
безпеку;
тести;
обробку помилок;
роботу з даними;
продуктивність;
сумісність із наявним кодом;
документацію.

Конфлікти Git

Merge conflict виникає, коли Git не може автоматично об’єднати зміни, бо різні гілки змінили одну й ту саму частину файлу.

Типові причини конфліктів:

два розробники змінили один файл;
змінена одна й та сама функція;
файл був перейменований в одній гілці й змінений в іншій;
застаріла feature-гілка;
великі рідкісні merge замість частого оновлення гілки.

При конфлікті потрібно вручну вибрати правильний варіант, перевірити код і створити commit з вирішенням конфлікту.

Рекомендація: щоб зменшити кількість конфліктів, потрібно частіше синхронізувати гілку з основною, робити невеликі commits і не тримати feature-гілки занадто довго без merge.

.gitignore

.gitignore — це файл, у якому вказується, які файли Git не повинен відстежувати.

У .gitignore зазвичай додають:

тимчасові файли;
кеш;
build-артефакти;
локальні налаштування IDE;
файли логів;
секрети;
.env;
node_modules;
target;
build;
dist;
файли операційної системи.

Приклад:

# Logs
*.log

# Environment
.env

# Java / Gradle
build/
.gradle/

# Node
node_modules/
dist/

# IDE
.idea/
.vscode/

Git tags

Tag — це позначка конкретного commit. Tags часто використовуються для релізів.

Приклад:

git tag v1.8.0
git push origin v1.8.0

Tags можуть позначати:

реліз;
production-версію;
hotfix;
важливу контрольну точку;
версію бібліотеки;
версію Docker image.

Git stash

git stash дозволяє тимчасово зберегти незавершені локальні зміни і очистити робочу директорію.

Приклад:

git stash

Повернути зміни:

git stash pop

Це корисно, коли потрібно швидко переключитися на іншу гілку, але поточна робота ще не готова до commit.

Git revert і git reset

git revert

git revert створює новий commit, який скасовує зміни попереднього commit.

git revert <commit_hash>

Це безпечний спосіб скасувати зміни в спільній історії.

git reset

git reset змінює стан гілки або staging area. Його потрібно використовувати обережно, особливо якщо commits уже були відправлені у віддалений репозиторій.

Приклад:

git reset --soft HEAD~1

Не плутати: git revert безпечніше для спільної історії, бо створює новий commit. git reset може переписати локальну історію і створити проблеми, якщо зміни вже були відправлені іншим розробникам.

Git rebase

git rebase переносить commits поточної гілки поверх іншої гілки.

Приклад:

git rebase main

Rebase може зробити історію чистішою, але його потрібно використовувати обережно.

Загальне правило:

можна rebase власну локальну гілку;
не варто rebase спільну гілку, яку вже використовують інші розробники.

Git flow

Git flow — це підхід до організації гілок, у якому використовуються main, develop, feature, release і hotfix-гілки.

Типова структура:

main — стабільна production-версія;
develop — основна гілка розробки;
feature/* — нові функції;
release/* — підготовка релізу;
hotfix/* — термінові виправлення production.

Git flow може бути корисним для продуктів із плановими релізами, але для деяких команд він може бути занадто складним.

Trunk-based development

Trunk-based development — це підхід, у якому команда часто інтегрує невеликі зміни в основну гілку.

Переваги:

менше довгих feature-гілок;
менше великих конфліктів;
швидший feedback;
краще підходить для CI/CD;
простіша історія;
частіші релізи.

Для цього підходу важливі:

автоматичні тести;
feature flags;
code review;
швидкий CI;
дисципліна маленьких змін.

GitHub, GitLab, Bitbucket

Git можна використовувати локально, але в командах зазвичай застосовують сервіси для віддалених репозиторіїв.

Популярні сервіси:

GitHub;
GitLab;
Bitbucket;
Azure DevOps Repos;
Gitea;
Forgejo.

Такі сервіси додають:

pull request або merge request;
code review;
issue tracking;
wiki;
CI/CD;
protected branches;
access control;
webhooks;
releases;
package registry.

Git і CI/CD

Git є основою CI/CD.

Типовий процес:

Розробник робить commit.
Розробник відправляє зміни в remote.
CI/CD-сервер отримує подію.
Запускається pipeline.
Виконується збірка.
Запускаються тести.
Створюється артефакт.
За потреби виконується deployment.

У K2 ERP це може бути пов’язано з TeamCity, Gradle, Docker і DevOps-процесом.

Git і TeamCity

TeamCity може підключатися до Git-репозиторію через VCS Root.

TeamCity може:

відстежувати commits;
запускати build після push;
запускати build для pull request;
показувати автора змін;
зберігати changelog;
прив’язувати build до commit;
створювати артефакти;
запускати deployment після успішної збірки.

Git і YouTrack

YouTrack може бути пов’язаний із Git-репозиторієм.

Типові сценарії:

ID задачі в назві гілки;
ID задачі в commit message;
зв’язок commit із задачею;
автоматичне оновлення статусу задачі;
перегляд commits у задачі;
контроль, які задачі потрапили в реліз.

Приклад commit message:

K2-1542 Fix LiqPay callback signature validation

Git і IDE

Сучасні IDE мають вбудовану підтримку Git.

Через IDE можна:

бачити змінені файли;
створювати commits;
перемикати гілки;
робити push і pull;
вирішувати конфлікти;
переглядати історію файлу;
створювати pull request;
порівнювати зміни;
бачити blame.

IDE допомагає працювати з Git візуально, але базові команди Git все одно важливо розуміти.

Git у K2 ERP

У контексті K2 ERP Git може використовуватися для контролю версій усіх технічних компонентів системи.

У Git можна зберігати:

backend-код;
frontend-код;
інтеграційні модулі;
API;
тести;
SQL-міграції;
Dockerfile;
docker-compose.yml;
Helm charts;
Terraform-код;
CI/CD-конфігурації;
документацію;
скрипти;
шаблони налаштувань;
модулі Shopify, Magento, Wix, Prom;
модулі LiqPay;
модулі ПРРО;
модулі ДПС і ЕДО;
SAF-T UA;
е-ТТН.

Для K2 ERP: Git має бути єдиним джерелом історії коду, міграцій, конфігурацій збірки та DevOps-скриптів. Усі зміни бажано прив’язувати до задач YouTrack і перевіряти через TeamCity.

Типовий Git-процес для K2 ERP

Типовий процес роботи може виглядати так:

Створюється задача в YouTrack.
Розробник створює гілку з ID задачі.
Розробник вносить зміни в код.
Розробник запускає локальні тести.
Створює commits із зрозумілими повідомленнями.
Відправляє гілку в remote.
Створюється pull request або merge request.
TeamCity запускає CI.
Інший розробник виконує code review.
Після успішних перевірок зміни об’єднуються в основну гілку.
CI/CD створює артефакт або виконує deployment у тестове середовище.

Правила commit messages

Добрі commit messages мають бути короткими, зрозумілими і конкретними.

Погано:

fix
changes
update
bug

Краще:

Fix duplicate import of Prom orders
Add PRRO shift close validation
Update Shopify inventory synchronization
Improve LiqPay callback error handling

Для командної роботи можна використовувати Conventional Commits:

feat: add Shopify order import
fix: prevent duplicate PRRO receipt
docs: update LiqPay integration guide
refactor: simplify Magento product mapper
test: add unit tests for payment callback

Protected branches

Protected branches — це захищені гілки, у які не можна напряму відправляти зміни без перевірок.

Для main або production-гілки бажано налаштувати:

заборону direct push;
обов’язковий pull request;
обов’язковий code review;
обов’язковий успішний CI build;
обов’язкові тести;
обмеження на force push;
обмеження прав merge.

Рекомендація: production-гілки не повинні оновлюватися напряму без review і CI/CD. Це зменшує ризик випадкового потрапляння помилкового коду в реліз.

Дані, які не можна зберігати в Git

У Git не можна зберігати:

паролі;
токени API;
private keys;
ключі електронного підпису;
production connection strings;
сертифікати;
повні дампи production-бази;
повні дані платіжних карток;
приватні ключі SSH;
secrets CI/CD;
доступи до LiqPay;
access tokens Shopify, Magento або Wix;
ключі ПРРО;
зайві персональні дані клієнтів.

Безпека: якщо секрет випадково потрапив у Git, недостатньо просто видалити його новим commit. Потрібно вважати секрет скомпрометованим, відкликати або змінити його і очистити історію за потреби.

Secrets management

Для секретів потрібно використовувати захищені сховища.

Можливі варіанти:

CI/CD secrets;
HashiCorp Vault;
AWS Secrets Manager;
Azure Key Vault;
Google Secret Manager;
Kubernetes Secrets;
змінні середовища;
захищені конфігурації deployment.

У репозиторії можна зберігати лише шаблони:

.env.example
application.example.yml
config.sample.json

Git hooks

Git hooks — це скрипти, які виконуються при певних Git-подіях.

Приклади hooks:

pre-commit;
commit-msg;
pre-push;
post-merge;
pre-receive;
update.

Hooks можуть використовуватися для:

запуску форматування;
запуску лінтера;
перевірки commit message;
запуску тестів;
перевірки секретів;
заборони commit у неправильну гілку.

Git LFS

Git LFS або Large File Storage використовується для роботи з великими файлами, які небажано зберігати напряму в Git-історії.

Git LFS може використовуватися для:

великих зображень;
відео;
архівів;
моделей;
великих тестових файлів;
binary assets.

Для звичайного коду Git LFS не потрібен.

Можливі помилки під час роботи з Git

Під час роботи з Git можуть виникати такі помилки:

commit зроблено не в тій гілці;
забули git pull перед роботою;
конфлікт під час merge;
випадково закомічено секрет;
випадково закомічено build-артефакти;
занадто великий commit;
незрозуміле повідомлення commit;
force push у спільну гілку;
довга feature-гілка без оновлень;
видалено важливу гілку;
зміни не потрапили в staging area;
неправильно вирішений conflict;
переплутано reset і revert.

Рекомендація: перед commit завжди варто перевіряти git status і git diff. Це допомагає не закомітити зайві файли, секрети або випадкові зміни.

Безпека Git

Для безпечної роботи з Git потрібно контролювати:

права доступу до репозиторію;
MFA для акаунтів;
SSH-ключі;
access tokens;
protected branches;
code review;
secret scanning;
dependency scanning;
audit log;
права на merge;
права на release;
права на CI/CD;
підписування commits за потреби.

Переваги Git

До основних переваг Git можна віднести:

розподілену модель;
швидку локальну роботу;
потужну роботу з гілками;
зручне об’єднання змін;
повну історію змін;
підтримку командної розробки;
інтеграцію з CI/CD;
підтримку code review;
можливість rollback;
зв’язок із задачами;
підтримку open source і enterprise-проєктів;
широку підтримку IDE та сервісів.

Обмеження та ризики

Під час використання Git потрібно враховувати:

потребу в навчанні команди;
ризик неправильного merge;
ризик force push;
ризик потрапляння секретів у історію;
складність rebase для новачків;
складність великих monorepo;
проблеми з великими binary-файлами;
потребу в правилах branch strategy;
потребу в code review;
потребу в CI/CD-перевірках.

Не плутати: Git зберігає історію файлів, але не є системою резервного копіювання production-даних. Бази даних, файли користувачів і важливі середовища потрібно резервувати окремо.

Висновок

Git — це основна система контролю версій для сучасної розробки програмного забезпечення. Він дозволяє зберігати історію змін, працювати з гілками, об’єднувати код, виконувати code review, пов’язувати зміни із задачами та запускати CI/CD-процеси.

Для K2 ERP Git доцільно використовувати як центральне джерело коду, конфігурацій, міграцій, тестів, DevOps-скриптів і документації. Найкращий результат Git дає разом із YouTrack, TeamCity, IDE, Gradle, Docker, тестами, protected branches, code review і правилами безпечної роботи з секретами.