Git

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

TeamCity

Репозиторій здатна бути: test: add unit tests for payment callback

git push

Для секретів потрібно використовувати захищені сховища.== .gitignore == !Що означає

• GitHub;
• GitLab;
• Bitbucket;
• Azure DevOps Repos;
• Gitea;
• Forgejo. # Запускаються тести. # Інший розробник виконує code review. # Створює commits із зрозумілими повідомленнями.</syntaxhighlight>Краще:

  == Trunk-based development ==
  

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

  == Branch naming ==
  
  '''.gitignore''' — це файл, у якому вказується, які файли Git не повинен відстежувати.<syntaxhighlight lang="bash">
  
  '''Практичне сценарії використання:''' Git дає можливість кожному розробнику працювати у власній гілці, не заважаючи іншим, а потім безпечно об’єднувати зміни після перевірки. Кожна зміна здатна бути зафіксована у вигляді commit. Це оптимізує не закомітити зайві файли, секрети або випадкові зміни. # Створюється артефакт. changes
  
  * можна rebase власну локальну гілку;
  * не варто rebase спільну гілку, яку вже використовують інші розробники. * бачити змінені файли;
  * створювати commits;
  * перемикати гілки;
  * робити push і pull;
  * вирішувати конфлікти;
  * переглядати історію файлу;
  * створювати pull request;
  * порівнювати зміни;
  * бачити blame. Віддалений репозиторій зазвичай знаходиться на сервері або сервісі, як приклад GitHub, GitLab, Bitbucket або Azure DevOps. Типова структура:
  </div>
  
  Приклади повідомлень commit:<syntaxhighlight lang="text">
  

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

build/

Fix duplicate Shopify order import

Repository

task/update-saf-t-export git add . # Розробник створює гілку з ID задачі. # Виконується збірка. Команда показує список гілок. .env.example

Зверніть увагу: Git зберігає історію змін, але сам по собі не гарантує якість коду.

{| class="wikitable"

git switch -c feature/liqpay-callback

git tag v1.8.0

Команда відправляє локальні commits у віддалений репозиторій. # Команда git status показує зміну. # Node
=== git switch ===
=== git pull ===

# IDE
IDE оптимізує працювати з Git візуально, але базові команди Git все одно критично розуміти. git switch -c feature/k2-shopify-order-import
'''Trunk-based development''' — це підхід, у якому команда часто інтегрує невеликі зміни в основну гілку.<syntaxhighlight lang="bash">
git push origin v1.8.0

=== git log ===

* відстежувати commits;
* запускати build після push;
* запускати build для pull request;
* показувати автора змін;
* зберігати changelog;
* прив’язувати build до commit;
* створювати артефакти;
* запускати deployment після успішної збірки.[[K2 Модуль Magento]]
== Git і IDE ==
[[YouTrack]]
Fix duplicate import of Prom orders
git log

Branch

Git застосовується для для керування змінами у файлах проєкту. критично: Git — це не хмарний сервіс і не сайт. * великих зображень;

• відео;
• архівів;
• моделей;
• великих тестових файлів;
• binary assets. Він дає можливість зробити історію більш лінійною, але потребує обережності, особливо в командній роботі. git merge feature/liqpay-callback

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

git switch feature/liqpay-callback

• локальним;
• віддаленим;
• приватним;
• публічним;
• основним;
• форком;
• дзеркалом. # Розробник відправляє зміни в remote. Для K2 ERP Git доцільно використовувати як центральне джерело коду, конфігурацій, міграцій, тестів, DevOps-скриптів і документації. # CI/CD-сервер отримує подію.

git status

update

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

SaaS

</syntaxhighlight>

</syntaxhighlight>

У pull request команда здатна:

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

Типовий бізнес-процес роботи здатна виглядати так:
Можливі варіанти:
== Основні команди Git ==
</div>
=== git revert ===
Для main або production-гілки бажано налаштувати:

Команда об’єднує зміни з іншої гілки. Tags часто використовуються для релізів. Git потрібен для контролю змін у проєкті. Він дає можливість зберігати історію змін, працювати з гілками, об’єднувати код, виконувати code review, пов’язувати зміни із задачами та запускати CI/CD-процеси.<div style="background:#fff3e0; border-left:5px solid #fb8c00; padding:12px; margin:12px 0;">

bugfix/K2-1608-prro-duplicate-check

git checkout feature/liqpay-callback

== Pull request і merge request ==

<div style="background:#fff3e0; border-left:5px solid #fb8c00; padding:12px; margin:12px 0;">

=== git diff ===

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

.idea/

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

[[Gradle]]

git pull

TeamCity здатна підключатися до Git-репозиторію через VCS Root. git reset --soft HEAD~1

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

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

feature/k2-shopify-order-import </syntaxhighlight>Це безпечний спосіб скасувати зміни в спільній історії.== конкурентні переваги Git == git revert <commit_hash> Команда створює новий Git-репозиторій у поточній директорії. Він користувачі можуть координувати зміни, уникати втрати коду, контролювати релізи, вести історію рішень і оперативно знаходити, коли та чому була внесена певна зміна. Це означає, що кожен розробник має локальну копію репозиторію з історією змін. # Logs

• .log

1. Environment

refactor: simplify Magento product mapper

1. Java / Gradle

feat: add Shopify order import Commit — це зафіксований набір змін. це розподілена платформа контролю версій. * тимчасові файли;

• кеш;
• build-артефакти;
• локальні конфігурація IDE;
• файли логів;
• секрети;
• .env;
• node_modules;
• target;
• build;
• dist;
• файли операційної системи. Сучасні IDE мають вбудовану підтримку Git. git reset здатна переписати локальну історію і створити проблеми, якщо зміни вже були відправлені іншим розробникам. Команда перемикає гілку або відновлює файл. # Розробник вносить зміни в код.</syntaxhighlight>

• Git
• Git Documentation
• Pro Git Book
• About Git — GitHub Docs
• Git — GitLab Docs
• Git tutorials — Atlassian

Git LFS

git rebase main

При конфлікті потрібно вручну вибрати правильний варіант, перевірити код і створити commit з вирішенням конфлікту. У K2 ERP це здатна бути пов’язано з TeamCity, Gradle, Docker і DevOps-процесом. Приклад:

=== git push ===

'''Merge conflict''' виникає, коли Git не здатна автоматизовано об’єднати зміни, бо різні гілки змінили одну й ту саму частину файлу.<syntaxhighlight lang="bash">

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

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

=== git reset ===
'''Rebase''' — це перенесення commits однієї гілки поверх іншої. '''Рекомендація:''' щоб зменшити кількість конфліктів, потрібно частіше синхронізувати гілку з основною, робити невеликі commits і не тримати feature-гілки занадто довго без merge. Типовий шлях зміни:
== Робоча область Git ==
bug

Add LiqPay payment callback validation .vscode/

Джерела

Update Shopify inventory synchronization </syntaxhighlight>

git commit -m "Add order import from Shopify" </syntaxhighlight> git init

git reset змінює стан гілки або staging area. Погано:

* потребу в навчанні команди;
* ризик неправильного merge;
* ризик force push;
* ризик потрапляння секретів у історію;
* складність rebase для новачків;
* складність великих monorepo;
* проблеми з великими binary-файлами;
* потребу в правилах branch strategy;
* потребу в code review;
* потребу в CI/CD-перевірках. Його потрібно використовувати обережно, особливо якщо commits уже були відправлені у віддалений репозиторій.== Git і CI/CD ==
== GitHub, GitLab, Bitbucket ==
</div>
Приклад:<syntaxhighlight lang="bash">
.env

== інформаційні дані, які не можна зберігати в Git ==

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

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

* main;
* master;
* develop;
* feature;
* bugfix;
* hotfix;
* release. Бази даних, файли користувачів і важливі середовища потрібно резервувати окремо. * запуску форматування;
* запуску лінтера;
* перевірки commit message;
* запуску тестів;
* перевірки секретів;
* заборони commit у неправильну гілку. '''Для K2 ERP:''' Git має бути єдиним джерелом історії коду, міграцій, конфігурацій збірки та DevOps-скриптів. Git LFS здатна використовуватися для:

[[Е-ТТН]]
'''Не плутати:''' git revert безпечніше для спільної історії, бо створює новий commit. Команда додає зміни до staging area. # TeamCity запускає CI. Усі зміни бажано прив’язувати до задач YouTrack і перевіряти через TeamCity.<syntaxhighlight lang="bash">
'''Не плутати:''' Git зберігає історію файлів, але не виступає як системою резервного копіювання production-даних. Add PRRO shift close validation
<div style="background:#ffebee; border-left:5px solid #e53935; padding:12px; margin:12px 0;">

'''git rebase''' переносить commits поточної гілки поверх іншої гілки.<syntaxhighlight lang="bash">
Добрий commit має бути логічно завершеним і зрозумілим. git branch feature/liqpay-callback

* автоматичні тести;
* feature flags;
* code review;
* швидкий CI;
* дисципліна маленьких змін. У Git не можна зберігати:
Приклади hooks:

== Безпека Git ==
Приклад:<syntaxhighlight lang="bash">

Типові сценарії:
Популярні сервіси:
'''Merge''' — це об’єднання змін з однієї гілки в іншу.=== git clone ===

* розподілену модель;
* швидку локальну роботу;
* потужну роботу з гілками;
* зручне об’єднання змін;
* повну історію змін;
* підтримку командної розробки;
* інтеграцію з CI/CD;
* підтримку code review;
* можливість rollback;
* зв’язок із задачами;
* підтримку open source і enterprise-проєктів;
* широку підтримку IDE та сервісів.<syntaxhighlight lang="bash">
|-
|Working directory
|Поточні файли на комп’ютері розробника
|-
|Staging area
|Підготовлені зміни, які увійдуть у наступний commit
|-
|Local repository
|Локальна історія продукту commits
|-
|Remote repository
|Віддалений репозиторій на сервері
|}
[[K2 Модуль Shopify]]

# Розробник змінює файл. У Git можна зберігати:

Git дає можливість розробникам працювати з гілками, створювати commits, об’єднувати зміни, переглядати історію, повертатися до попередніх версій, виконувати code review і спільно працювати над програмним забезпеченням. # Команда git commit створює commit. Це оптимізує робити commits чистішими і логічнішими.</div>
[[Spring]]

config.sample.json

Див. так само

</syntaxhighlight>

git checkout

feature/K2-1542-liqpay-callback Під час code review перевіряють: Для цього підходу важливі: Основні задачі Git:

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

git add

</syntaxhighlight> TeamCity здатна: Hooks можуть використовуватися для:

Code review

LiqPay release/1.8.0 Rider

Приклад:

=== Remote ===

docs: update LiqPay integration guide

</syntaxhighlight>

</syntaxhighlight>Створити нову гілку:

== Git flow ==
'''Code review''' — це перевірка коду іншими учасниками команди перед об’єднанням у основну гілку.=== git status ===
Локальний репозиторій знаходиться на комп’ютері розробника. Це зменшує ризик випадкового потрапляння помилкового коду в реліз.<syntaxhighlight lang="bash">

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

YouTrack здатна бути пов’язаний із Git-репозиторієм. У контексті '''K2 ERP''' Git здатна використовуватися для контролю версій усіх технічних компонентів системи.=== Commit ===

Інтеграційний акцент: pull request бажано пов’язувати із задачею в YouTrack, а CI/CD у TeamCity має автоматизовано перевіряти збірку і тести перед merge. Гілки виступає як однією з найважливіших можливостей Git. # Команда git add додає зміну в staging area. # Створюється pull request або merge request.</syntaxhighlight>Tags можуть позначати:

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

</syntaxhighlight>Для нової гілки:

</div>
hotfix/prro-shift-close-error

</div>
Git — це основна платформа контролю версій для сучасної розробки програмного забезпечення.== Правила commit messages ==

application.example.yml
Команда отримує зміни з віддаленого репозиторію і застосовує їх до локальної гілки. Розробник здатна створювати commits, переглядати історію, створювати гілки та працювати локально навіть без постійного підключення до центрального сервера. Commit містить інформацію про те, які файли були змінені, хто зробив зміну, коли вона була зроблена і з яким повідомленням. На відміну від централізованих систем контролю версій, Git виступає як розподіленою системою.== Secrets management ==
=== git commit ===
git push -u origin feature/liqpay-callback

== Git і TeamCity ==

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

Git revert і git reset

fix: prevent duplicate PRRO receipt Для розробника: staging area дає можливість вибрати, які саме зміни потраплять у commit.Модуль Prom

• зберігання історії змін;
• робота з гілками;
• спільна розробка програмного забезпечення;
• об’єднання змін різних розробників;
• перегляд різниці між версіями;
• повернення до попереднього стану;
• пошук автора зміни;
• підготовка релізів;
• робота з pull request або merge request;
• технічна підтримка code review;
• зв’язок задач із commit;
• автоматизація процесів CI/CD;
• контроль версій конфігурацій та інфраструктури. # Команда git push відправляє commit у віддалений репозиторій. Команда показує поточний стан робочої директорії: які файли змінені, які готові до commit, які не відстежуються. # CI/CD створює артефакт або виконує deployment у тестове середовище.</syntaxhighlight>

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

• pre-commit;
• commit-msg;
• pre-push;
• post-merge;
• pre-receive;
• update. Команда створює commit із підготовлених змін. Потрібно вважати секрет скомпрометованим, відкликати або змінити його і очистити історію за потреби. git clone https://example.com/project.git

</syntaxhighlight>Додати всі зміни:

Приклад:<syntaxhighlight lang="bash">

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

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

* CI/CD secrets;
* HashiCorp Vault;
* AWS Secrets Manager;
* Azure Key Vault;
* Google Secret Manager;
* Kubernetes Secrets;
* змінні середовища;
* захищені конфігурації deployment. '''Remote''' — це віддалений репозиторій, з яким синхронізується локальна копія. * переглянути код;
* залишити коментарі;
* запустити CI/CD;
* перевірити тести;
* перевірити зміни в документації;
* погодити або відхилити зміни;
* об’єднати гілку після перевірки. Добрі commit messages мають бути короткими, зрозумілими і конкретними. Commit має унікальний ідентифікатор, автора, дату, повідомлення та список змінених файлів. Типовий бізнес-процес:
'''Protected branches''' — це захищені гілки, у які не можна напряму відправляти зміни без перевірок.<syntaxhighlight lang="bash">

• менше довгих feature-гілок;
• менше великих конфліктів;
• швидший feedback;
• краще підходить для CI/CD;
• простіша історія продукту;
• частіші релізи. git revert створює новий commit, який скасовує зміни попереднього commit. git stash дає можливість тимчасово зберегти незавершені локальні зміни і очистити робочу директорію. # Відправляє гілку в remote. Гілки дозволяють працювати над новими функціями, виправленнями або експериментами без зміни основної стабільної версії. fix

Git LFS або Large File Storage застосовують, коли потрібно для роботи з великими файлами, які небажано зберігати напряму в Git-історії. через Git особливо важливий для командної розробки, де над одним продуктом функціонує багато людей.== Конфлікти Git == git add file.txt

конкурентні переваги:

1. Розробник робить commit. Найкращий результат Git дає разом із YouTrack, TeamCity, IDE, Gradle, Docker, тестами, protected branches, code review і правилами безпечної роботи з секретами.

   Improve LiqPay callback error handling
   
   == Типовий Git-процес для K2 ERP ==
   [[ПРРО]]
   node_modules/
   '''Безпека:''' якщо секрет випадково потрапив у Git, недостатньо без зусиль видалити його новим commit. !Область
   Окремо варто відзначити яка застосовується для; так само реалізовано документації, конфігураціях, скриптах, інфраструктурі і інших файлах проєкту виступає ключовою рисою зберігання історії змін у коді забезпечується через '''Git'''. # Після успішних перевірок зміни об’єднуються в основну гілку. GitHub, GitLab, Bitbucket або Azure DevOps — це сервіси, які можуть зберігати Git-репозиторії та додавати інструменти для командної роботи.== Git rebase ==
   == Git tags ==
   У .gitignore зазвичай додають:
   

   Rebase здатна зробити історію чистішою, але його потрібно використовувати обережно. # Запускається pipeline. Для звичайного коду Git LFS не потрібен.</syntaxhighlight>Повернути зміни:

   У репозиторії можна зберігати лише шаблони:<syntaxhighlight lang="text">
   
   Через IDE можна:
   == Git і YouTrack ==
   
   == Обмеження та ризики ==
   
   * коректність логіки;
   * читабельність коду;
   * відповідність архітектурі;
   * безпеку;
   * тести;
   * обробку помилок;
   * роботу з даними;
   * продуктивність;
   * сумісність із наявним кодом;
   * документацію.[[ДПС]]
   '''Git hooks''' — це скрипти, які виконуються при певних Git-подіях. # Розробник запускає локальні тести.<div style="background:#f3e5f5; border-left:5px solid #8e24aa; padding:12px; margin:12px 0;">
   

Update PRRO fiscalization error handling

origin Команда показує історію commits. Назви гілок бажано стандартизувати.K2 Модуль Wix

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

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

</syntaxhighlight>

dist/ bugfix/duplicate-prom-orders

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

Git flow здатна бути корисним для продуктів із плановими релізами, але для деяких команд він здатна бути занадто складним. Branch або гілка — це окрема лінія розробки.== Загальний SEO-опис == У Git виступає як кілька важливих станів файлів. Вони дозволяють вести паралельну розробку. Tag — це позначка конкретного commit. Git — це платформа контролю версій.== Git hooks == </syntaxhighlight>

• commit зроблено не в тій гілці;
• забули git pull перед роботою;
• конфлікт під час merge;
• випадково закомічено секрет;
• випадково закомічено build-артефакти;
• занадто великий commit;
• незрозуміле повідомлення commit;
• force push у спільну гілку;
• довга feature-гілка без оновлень;
• видалено важливу гілку;
• зміни не потрапили в staging area;
• неправильно вирішений conflict;
• переплутано reset і revert. * pull request або merge request;
• code review;
• issue tracking;
• wiki;
• CI/CD;
• protected branches;
• access control;
• webhooks;
• releases;
• package registry.

  як приклад, після завершення роботи над feature-гілкою її можна об’єднати з develop або main. # За потреби виконується deployment. Приклад створення гілки для задачі:<syntaxhighlight lang="bash">
  
  git stash pop
  == Гілки в Git ==
  
  === git merge ===
  === git init ===
  Git виступає як основою CI/CD.[[SAF-T UA]]
  === Merge ===
  Для безпечної роботи з Git потрібно контролювати:
  
  <div style="background:#fff3e0; border-left:5px solid #fb8c00; padding:12px; margin:12px 0;">
  

1. Створюється задача в YouTrack.=== Rebase ===

IDE

Приклад commit message:

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

[[DevOps]]
'''Git flow''' — це підхід до організації гілок, у якому використовуються main, develop, feature, release і hotfix-гілки. git branch
Приклади:<syntaxhighlight lang="text">
K2-1542 Fix LiqPay callback signature validation
'''Pull request''' або '''merge request''' — це запит на об’єднання змін з однієї гілки в іншу.== Git stash ==

Команда показує різницю між файлами або версіями. '''Repository''' або '''репозиторій''' — це сховище проєкту, яке містить файли та історію змін.<syntaxhighlight lang="bash">

Створити і одразу перейти на гілку:<syntaxhighlight lang="bash">

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

• заборону direct push;
• обов’язковий pull request;
• обов’язковий code review;
• обов’язковий успішний CI build;
• обов’язкові тести;
• обмеження на force push;
• обмеження прав merge. Команда копіює віддалений репозиторій на локальний комп’ютер. <syntaxhighlight lang="bash">