diff --git a/README.md b/README.md
index 1af862b..a6c82c5 100644
--- a/README.md
+++ b/README.md
@@ -2438,7 +2438,903 @@ Sourcetree/IntelliJ для візуального вирішення конфл
 </details>
 
 <details>
-<summary>81. ???</summary>
+<summary>81. Які підходи використовують для роботи з великими файлами в Git?</summary>
+
+#### GIT
+
+1. **Git LFS (Large File Storage)**
+
+- Зберігає великі файли (зображення, відео, бінарники) поза основним
+  репозиторієм.
+
+- У Git зберігаються тільки посилання, а самі файли лежать у спеціальному
+  сховищі.
+
+2. **.gitignore**
+
+- Ігнорувати великі тимчасові чи згенеровані файли, які не потрібні в історії
+  (наприклад, node_modules, build-артефакти).
+
+3. **Артефакти CI/CD**
+
+- Замість зберігання бінарних файлів у репозиторії використовувати системи
+  зберігання (S3, Nexus, Artifactory).
+
+4. **Розбивка проєкту**
+
+- Виносити великі ресурси в окремі репозиторії чи підмодулі.
+
+Для фронтенду найчастіше: Git LFS для картинок/відео або S3 bucket для
+build-артефактів.
+
+</details>
+
+<details>
+<summary>82. Які техніки можна застосувати для підвищення продуктивності при роботі з великим репозиторієм Git?</summary>
+
+#### GIT
+
+1. **Shallow clone** (--depth)
+
+- Завантажувати тільки останні коміти, щоб зменшити обсяг історії.
+
+2. **Sparse checkout / partial clone**
+
+- Клонувати тільки потрібні директорії або файли (git sparse-checkout).
+
+3. **Git gc (garbage collection)**
+
+- Виконувати прибирання і оптимізацію об’єктів:
+
+```bash
+git gc --aggressive --prune=now
+```
+
+4. **Розбиття монорепозиторію**
+
+- Використання submodules чи subtree для ізоляції великих компонентів.
+
+5. **Ігнорування непотрібних файлів**
+
+- Налаштувати .gitignore, щоб зменшити кількість відстежуваних файлів.
+
+6. **Git LFS**
+
+- Використовувати для важких медіа- або бінарних файлів.
+
+7. **CI/CD кешування**
+
+- Використовувати кеш (npm/yarn cache, Docker layers) замість зберігання
+  артефактів у Git.
+
+У реальних фронтенд-проєктах часто комбінують shallow clone + sparse checkout
+для швидких CI-білдів.
+
+</details>
+
+<details>
+<summary>83. Що таке shallow clone у Git і коли доцільно його застосовувати?</summary>
+
+#### GIT
+
+**Shallow clone** — це клон репозиторію з обмеженою історією комітів.
+Виконується командою:
+
+```bash
+git clone --depth <N> <repo-url>
+```
+
+де `<N>` — кількість останніх комітів, які потрібно завантажити.
+
+#### Переваги:
+
+- значно швидше клонування;
+
+- менший розмір репозиторію;
+
+- корисно для CI/CD, де потрібен лише останній стан коду.
+
+#### Недоліки:
+
+- обмежена історія (неможливо повноцінно досліджувати старі коміти);
+
+- складніше працювати з перебазуванням і пошуком у глибокій історії.
+
+Використовують, коли потрібен лише актуальний стан проєкту без повної історії
+(наприклад, білд на CI).
+
+</details>
+
+<details>
+<summary>84. Які підходи можна застосувати для зменшення розміру репозиторію Git?</summary>
+
+#### GIT
+
+1. Прибрати непотрібні файли з історії
+
+- Використати git filter-repo (сучасний варіант git filter-branch):
+
+```bash
+git filter-repo --path <file> --invert-paths
+```
+
+- (видалить файл з усієї історії).
+
+2. Очистити великі файли у репозиторії
+
+- Інтегрувати Git LFS для зберігання бінарників/медіа окремо.
+
+3. Запустити прибирання
+
+```bash
+git gc --aggressive --prune=now
+```
+
+- (стисне об’єкти й прибере сміття).
+
+4. Видалити старі гілки та теги
+
+- Локально:
+
+```bash
+git branch -D <branch>
+```
+
+- Віддалено:
+
+```bash
+git push origin --delete <branch>
+```
+
+5. Використовувати shallow clone (--depth 1) на CI/CD для швидших зборок,
+   замість повного репо.
+
+У реальних командах основний варіант — перенесення великих файлів у Git LFS +
+чистка історії filter-repo.
+
+</details>
+
+<details>
+<summary>85. Що таке Git LFS і як ним користуватись?</summary>
+
+#### GIT
+
+**Git LFS (Large File Storage)** — це розширення Git для зберігання великих
+файлів (зображення, відео, бінарники) поза основною історією репозиторію. У Git
+зберігаються лише посилання (пойнтери) на ці файли, а самі дані лежать у
+спеціальному сховищі.
+
+#### Як працює:
+
+1. Установлюємо:
+
+```bash
+git lfs install
+```
+
+2. Відзначаємо типи файлів, які треба винести в LFS:
+
+```bash
+git lfs track "_.png" git lfs track "_.mp4"
+```
+
+- (створюється/оновлюється .gitattributes).
+
+3. Додаємо та комітимо як звичайні файли:
+
+```bash
+git add .gitattributes image.png
+git commit -m "Add image with LFS"
+git push origin main
+```
+
+#### Переваги:
+
+- репозиторій не роздувається;
+
+- швидше клонування й робота з історією;
+
+- зручно для мультимедіа або артефактів білду.
+
+#### Недоліки:
+
+- потрібна підтримка на стороні віддаленого репозиторію (GitHub, GitLab,
+  Bitbucket підтримують, але є ліміти);
+
+- обмеження за розміром файлів/трафіку (особливо у безкоштовних планах).
+
+Використовують тоді, коли в проєкті є важкі бінарні чи медіафайли, які часто
+оновлюються.
+
+</details>
+
+<details>
+<summary>86. Як Git інтегрується в CI/CD-процеси?</summary>
+
+#### GIT
+
+Git є джерелом правди для коду, а CI/CD-системи (GitHub Actions, GitLab CI,
+Jenkins, Azure DevOps тощо) інтегруються з ним через події (hooks/webhooks).
+
+#### Як це працює:
+
+1. Push / Pull Request / Merge → тригер для пайплайну.
+
+2. CI/CD-система клонує або фетчить репозиторій.
+
+3. Виконує кроки (білд, тести, лінтинг, деплой).
+
+4. Зберігає артефакти, публікує результати, може створювати релізи з тегів.
+
+#### Приклади інтеграції:
+
+- GitHub Actions автоматично запускає воркфлоу при push чи pull_request.
+
+- GitLab CI використовує .gitlab-ci.yml, який описує пайплайни.
+
+- Jenkins може слухати webhooks від GitHub/GitLab і виконувати джоби.
+
+#### Ключові моменти:
+
+- Git дозволяє відслідковувати зміни й запускати пайплайни тільки для змінених
+  частин коду.
+
+- Теги часто використовують для тригера релізних збірок.
+
+- Branching strategy (Gitflow, trunk-based) напряму впливає на структуру CI/CD.
+
+Тобто Git — це тригер і джерело коду, а CI/CD — автоматизація всіх подальших
+процесів.
+
+</details>
+
+<details>
+<summary>87. Як налаштовується автоматизоване розгортання (deployment) з використанням Git?</summary>
+
+#### GIT
+
+Автоматизоване розгортання з Git базується на інтеграції з CI/CD і подіях у
+репозиторії.
+
+#### Ключові кроки:
+
+1. Push / merge у гілку (наприклад, main або release) → тригер для пайплайну.
+
+2. CI/CD-система (GitHub Actions, GitLab CI, Jenkins, Azure DevOps):
+
+- клонує репозиторій (git clone або git fetch),
+
+- виконує білд (наприклад, npm install && npm run build для React),
+
+- запускає тести та лінтери,
+
+- створює артефакти (docker-образ, bundle).
+
+3. Деплой:
+
+- пуш Docker-образу в реєстр (ECR, Docker Hub);
+
+- деплой на сервер через SSH або оркестратор (Kubernetes, ECS, Heroku, Vercel,
+  Netlify).
+
+4. Моніторинг та rollback: відслідковування успішності, можливість відкату на
+   попередній тег/реліз.
+
+#### Приклади:
+
+- `git push origin main` → GitHub Actions запускає воркфлоу, який деплоїть
+  додаток на AWS S3 + CloudFront.
+
+- `git tag v1.0.0 && git push origin v1.0.0` → CI/CD запускає релізний пайплайн
+  (білд Docker + деплой у Kubernetes).
+
+Головна ідея: Git — це тригер і контроль версій, а автоматизація виконується
+пайплайнами, що читають код і конфіг з репозиторію.
+
+</details>
+
+<details>
+<summary>88. Як налаштувати правила захисту гілок у Git, щоб інтегрувати їх із CI/CD?</summary>
+
+#### GIT
+
+**Призначення** — захищені гілки (main, release) гарантують, що в продакшен не
+потраплять неякісні зміни.
+
+#### Ключові правила захисту:
+
+1. Заборонити прямі пуші → зміни тільки через Pull Request.
+
+2. Обов’язкові перевірки CI/CD перед злиттям:
+
+- білд має пройти успішно,
+
+- тести мають бути "green",
+
+- лінтери / форматтери виконані. (На GitHub це → Require status checks to pass
+  before merging).
+
+3. Обов’язковий code review: мінімум 1–2 схвалення перед merge.
+
+4. Синхронізація з останнім main: PR має бути актуальним (без конфліктів).
+
+5. Обов’язковий підпис комітів (GPG/SSO) — для безпеки.
+
+6. Автоматичне тегування / реліз після злиття (наприклад, через GitHub Actions).
+
+#### Приклад у контексті CI/CD:
+
+- На GitHub:
+
+  - Settings → Branches → Branch protection rules
+
+  - Додати правило для main:
+
+    - ✅ Require pull request reviews
+
+    - ✅ Require status checks (CI pipeline)
+
+    - ✅ Require signed commits
+
+    - ✅ Require linear history (без merge-комітів, тільки squash/rebase)
+
+Результат: розгортання тригериться лише після успішного проходження CI/CD, а у
+продакшен не потрапить "сирий" код.
+
+</details>
+
+<details>
+<summary>89. Яку роль відіграють Git hooks (гачки) в автоматизації процесів?</summary>
+
+#### GIT
+
+- **Git hooks** — це скрипти, які автоматично запускаються на певні події Git
+  (commit, push, merge тощо). Вони дозволяють автоматизувати дії прямо в
+  робочому циклі розробки.
+
+#### Основні ролі в автоматизації:
+
+1. Перевірка якості коду перед комітом
+
+- запуск лінтерів (ESLint, Prettier),
+
+- перевірка форматування,
+
+- блокування коміту з помилками.
+
+2. Автоматизація тестів
+
+- pre-push може запускати unit / integration тести, щоб у віддалений репозиторій
+  не потрапив "зламаний" код.
+
+3. Безпека
+
+- перевірка, чи немає у коміті секретів (ключів, паролів),
+
+- обов’язкове підписання комітів.
+
+4. Уніфікація процесів
+
+- автогенерація changelog,
+
+- оновлення документації,
+
+- форматування commit message за convention (наприклад, Conventional Commits).
+
+На практиці часто використовують Husky (JavaScript) або lefthook
+(language-agnostic) для зручного менеджменту Git hooks.
+
+</details>
+
+<details>
+<summary>90. Як Git використовується для відкату змін у разі невдалого деплою?</summary>
+
+#### GIT
+
+- Git робить відкат безпечним, оскільки кожен реліз — це фіксований коміт або
+  тег. У випадку невдалого розгортання:
+
+1. **Повернення до стабільної версії**
+
+- checkout на попередній тег/коміт:
+
+```bash
+git checkout v1.2.3
+```
+
+- деплой цього стану коду.
+
+2. **Використання git revert**
+
+- створює новий коміт, що відміняє зміни проблемного:
+
+```bash
+git revert <commit_hash>
+```
+
+3. **CI/CD інтеграція**
+
+- у пайплайні зазвичай деплої відбуваються з тегів або main/master.
+
+- можна швидко redeploy попереднього тегу без ручного втручання.
+
+4. **Blue-Green / Canary деплоймент** (залежить від інфраструктури, але Git
+   виступає як джерело істини для коду).
+
+Головна ідея: Git дозволяє миттєво відтворити будь-який попередній стан коду, що
+робить rollback контрольованим і передбачуваним.
+
+</details>
+
+<details>
+<summary>91. Як налаштувати та інтегрувати Git у сучасне IDE для зручної роботи?</summary>
+
+#### GIT
+
+1. **Підтримка Git у IDE**
+
+- Більшість IDE мають вбудовану підтримку Git:
+
+  - `VS Code` → вбудований Source Control + розширення GitLens, Git Graph
+
+  - `IntelliJ/WebStorm` → інтегрований VCS
+
+  - `Visual Studio` → Team Explorer / Git Tools
+
+2. **Налаштування репозиторію**
+
+- Відкрити проєкт у IDE
+
+- Вказати шлях до локального репозиторію або клонувати з remote
+
+- Налаштувати глобальні параметри Git (ім’я, email)
+
+3. **Основні інтегровані функції**
+
+- Візуальна історія комітів, diff файлів
+
+- Створення, перемикання та видалення гілок
+
+- Commit / Stage / Push / Pull прямо з IDE
+
+- Можливість вирішення конфліктів merge через GUI
+
+- Підпис комітів GPG (якщо підтримується)
+
+4. **Розширення та плагіни**
+
+- GitLens (VS Code) – показ авторства рядків, історія змін
+
+- Git Graph – графічне відображення гілок
+
+- GitHub / GitLab плагіни для PR, Issues, CI/CD
+
+Порада: інтеграція Git у IDE скорочує контекстні переключення і робить робочий
+процес швидшим, особливо для фронтенд-команд.
+
+</details>
+
+<details>
+<summary>92. Які плюси та мінуси використання GUI для Git у порівнянні з командним рядком?</summary>
+
+#### GIT
+
+**Переваги GUI для Git:**
+
+1. Візуалізація історії та гілок
+
+- Зручно бачити дерево комітів, злиття, конфлікти.
+
+2. Менше помилок у синтаксисі
+
+- Не треба пам’ятати точні команди (merge, rebase, cherry-pick).
+
+3. Швидкий доступ до повторюваних дій
+
+- Stage/unstage файли, створення гілок, PR, revert через кнопки.
+
+4. Інтеграція з IDE / CI/CD
+
+- Відображення статусу тестів, PR, pipeline прямо в IDE.
+
+**Недоліки GUI:**
+
+1. Обмежений контроль
+
+- Деякі складні операції (rebase -i, filter-repo) зручні тільки в CLI.
+
+2. Може вводити в оману
+
+- Не завжди видно, що реально відбувається під капотом (наприклад, fast-forward
+  merge).
+
+3. Продуктивність
+
+- Великі репозиторії можуть гальмувати в GUI.
+
+4. Залежність від інструменту
+
+- Навчання нових інструментів + несумісність між різними GUI.
+
+#### Висновок:
+
+- `CLI` – повний контроль, необхідний для складних сценаріїв і скриптів.
+
+- `GUI` – зручність для швидкого перегляду історії, PR, простих merge/commit.
+
+- Часто практикують комбінацію: CLI для критичних дій, GUI для щоденної роботи.
+
+</details>
+
+<details>
+<summary>93. Які популярні плагіни та розширення використовують для інтеграції Git у IDE та редакторах коду?</summary>
+
+#### GIT
+
+**Для VS Code:**
+
+- GitLens – показ авторства рядків, історії комітів, гілок, інтеграція з PR.
+
+- Git Graph – графічне дерево гілок та комітів.
+
+- GitHub Pull Requests and Issues – управління PR та Issue прямо з редактора.
+
+- Git History – швидкий перегляд історії комітів.
+
+- Project Manager + Git Integration – зручна робота з кількома репозиторіями.
+
+**Для JetBrains IDE (WebStorm, IntelliJ, PhpStorm):**
+
+- Вбудований VCS/Git – коміти, merge, rebase, stash, історія.
+
+- GitToolBox – розширена інформація про віддалені гілки, статус, auto-fetch.
+
+- Git Flow Integration – підтримка Gitflow без CLI.
+
+**Для Visual Studio:**
+
+- Git Tools / Team Explorer – коміти, гілки, merge, stash.
+
+- GitHub Extension for Visual Studio – інтеграція з GitHub, PR, issues.
+
+**Для інших редакторів:**
+
+- Sourcetree – окремий GUI для Git (розробка Atlassian).
+
+- Fork – легкий GUI-клієнт для Mac/Windows.
+
+- Tower – комерційний GUI для macOS/Windows.
+
+Порада: у фронтенд-проєктах найчастіше використовують GitLens + Git Graph +
+GitHub PR у VS Code для швидкої та наочної роботи з Git.
+
+</details>
+
+<details>
+<summary>94. Як вирішувати Git merge конфлікти за допомогою візуальних інструментів?</summary>
+
+#### GIT
+
+1. Використання IDE (VS Code, WebStorm, IntelliJ)
+
+- **Відкриваєте файли з конфліктами → IDE підсвічує зміни:**
+
+  - <<<<<<< HEAD – ваші зміни
+
+  - ======= – роздільник
+
+  - > > > > > > > feature-branch – зміни іншої гілки
+
+- **Візуальні кнопки:**
+
+  - Accept Current Change – залишити вашу версію
+
+  - Accept Incoming Change – взяти версію з іншої гілки
+
+  - Accept Both Changes – об’єднати зміни
+
+  - Compare Changes – переглянути різницю у зручному режимі side-by-side
+
+2. Використання спеціальних GUI-клієнтів
+
+- **Sourcetree, Fork, GitKraken**
+
+  - Автоматично показують дерево конфліктів
+
+  - Дозволяють drag-and-drop об’єднання змін
+
+  - Після вирішення – кнопка Mark as Resolved
+
+3. Після вирішення
+
+```bash
+git add <resolved_file>
+git commit           # закомітити результат злиття
+```
+
+#### Порада:
+
+- Візуальні інструменти особливо зручні для фронтенду, де конфлікти часто
+  виникають у JSX, CSS, JSON.
+
+- Для складних сценаріїв (великий обсяг коду) IDE + GUI клієнт дають максимум
+  наочності.
+
+</details>
+
+<details>
+<summary>95. Що таке Git bridge і яку роль він відіграє у взаємодії з іншими системами контролю версій?</summary>
+
+#### GIT
+
+- Git bridge — це механізм або набір інструментів, що дозволяє інтегрувати Git з
+  іншими системами контролю версій (SVN, Perforce, Mercurial).
+
+- Він забезпечує двосторонню синхронізацію: можна працювати у Git, а зміни
+  автоматично відображаються у старій VCS, або навпаки.
+
+#### Приклади використання:
+
+1. git-svn – для роботи з SVN через Git:
+
+- Клонування SVN репозиторію у Git
+
+- Push/Pull змін між Git та SVN
+
+2. Perforce Git Fusion – дозволяє користувачам Git працювати з Perforce як з
+   віддаленим репозиторієм.
+
+3. Mercurial → Git – інструменти для міграції або двосторонньої синхронізації.
+
+#### Перевага:
+
+Дозволяє командам поступово переходити на Git без порушення існуючих процесів у
+старих VCS.
+
+</details>
+
+<details>
+<summary>96. Як керувати великими бінарними файлами в Git, якщо не використовувати Git LFS?</summary>
+
+#### GIT
+
+1. **Ігнорування великих файлів**
+
+- Додати їх у .gitignore, щоб не відстежувати у Git:
+
+```gitignore
+*.mp4
+*.zip
+node_modules/
+dist/
+```
+
+2. **Зберігання поза репозиторієм**
+
+- Використовувати зовнішні сховища:
+
+  - AWS S3, Google Cloud Storage, Azure Blob
+
+  - CDN або внутрішні файлові сервери
+
+- В Git зберігати лише посилання (URL, шлях) на файл.
+
+3. **Артефактні репозиторії**
+
+- Для build-артефактів або бінарників застосовувати Nexus, Artifactory,
+  Verdaccio.
+
+4. **Розбиття на менші пакети**
+
+- Якщо можливо, ділити великі файли на менші частини для зручнішої доставки.
+
+5. **Shallow clone / sparse checkout**
+
+- Не завантажувати всю історію репозиторію або непотрібні директорії:
+
+```bash
+git clone --depth 1 <repo>
+git sparse-checkout init --cone
+git sparse-checkout set src/
+```
+
+Висновок: без Git LFS великі файли краще зберігати зовні, а в Git тримати лише
+код і lightweight метадані.
+
+</details>
+
+<details>
+<summary>97. Для чого використовується git rebase -i (інтерактивний rebase)?</summary>
+
+#### GIT
+
+- `git rebase -i` дозволяє інтерактивно змінювати історію комітів у локальній
+  гілці.
+
+- Основні сценарії використання:
+
+1. Squash комітів – об’єднати кілька маленьких комітів в один.
+
+2. Редагування повідомлень комітів – змінити commit message.
+
+3. Видалення непотрібних комітів – drop комітів із історії.
+
+4. Перестановка комітів – змінити порядок комітів для чистішої історії.
+
+#### Приклад:
+
+```bash
+git rebase -i HEAD~3
+```
+
+- Відкриває останні 3 коміти в текстовому редакторі для редагування.
+
+- Кожен коміт можна позначити як pick, squash, edit, drop.
+
+Порада: використовувати тільки для локальної гілки, яка ще не пушилась у
+віддалений репозиторій, щоб не порушити історію інших розробників.
+
+</details>
+
+<details>
+<summary>98. Як організувати безперервне резервне копіювання репозиторіїв Git?</summary>
+
+#### GIT
+
+1. Віддалені репозиторії (Remote Backup)
+
+- Основний метод — регулярний пуш у віддалений репозиторій (GitHub, GitLab,
+  Bitbucket, приватний сервер).
+
+- Приклад автоматичного резервного копіювання локального репо:
+
+```bash
+git remote add backup <backup-repo-url>
+git push --mirror backup
+```
+
+- `--mirror` зберігає всі гілки, теги та refs.
+
+2. Автоматизація через CI/CD або cron
+
+- Використати cron на сервері або workflow у CI/CD для періодичного пушу:
+
+```bash
+0 2 * * * cd /path/to/repo && git fetch origin && git push --mirror backup
+```
+
+3. Бекап з архівуванням
+
+- Створювати архіви (tar/zip) репозиторію:
+
+```bash
+git bundle create repo.bundle --all
+```
+
+- Архів можна зберігати на іншому сервері або S3.
+
+- Відновлення:
+
+```bash
+git clone repo.bundle -b main <new-dir>
+```
+
+4. Хмарне сховище
+
+- Регулярний бекап .git директорії у S3, Google Drive, Azure Blob.
+
+#### Порада:
+
+- Комбінувати віддалений mirror + архіви для критичних проєктів.
+
+- Перевіряти бекапи, щоб уникнути "битих" репозиторіїв.
+
+</details>
+
+<details>
+<summary>99. Як чутливість до регістру впливає на Git і як її контролювати на різних ОС?</summary>
+
+#### GIT
+
+1. **Чутливість Git до регістру**
+
+- Git регістрочутливий щодо імен файлів за замовчуванням.
+
+- file.txt і File.txt сприймаються як різні файли.
+
+- Це може спричиняти проблеми при роботі в командах на різних ОС.
+
+2. **Поведінка на різних ОС**
+
+| ОС      | За замовчуванням        | Проблеми                                                          |
+| ------- | ----------------------- | ----------------------------------------------------------------- |
+| Linux   | case-sensitive          | все працює як очікується                                          |
+| macOS   | case-insensitive (HFS+) | може ігнорувати зміни регістру, конфлікти при колаборації з Linux |
+| Windows | case-insensitive        | теж може створювати конфлікти при мережевій роботі з Linux/macOS  |
+
+3. **Як керувати чутливістю**
+
+- core.ignorecase – налаштування Git:
+
+```bash
+git config core.ignorecase true # ігнорувати регістр (Windows/macOS) git config
+core.ignorecase false # враховувати регістр (Linux)
+```
+
+- Рекомендація: у командах, де є Linux-сервери, тримати false, щоб уникнути
+  несподіванок.
+
+- Для зміни імен файлів регістром:
+
+```bash
+git mv File.txt temp.txt git mv temp.txt file.txt git commit -m "Fix filename
+case"
+```
+
+#### Висновок:
+
+- Регістрочутливість важлива для кросплатформових проєктів.
+
+- Краще дотримуватись уніфікованого стилю іменування файлів і налаштувати
+  core.ignorecase відповідно до основної CI/CD-платформи.
+
+</details>
+
+<details>
+<summary>100. Як організувати підтримку кількох версій продукту за допомогою Git-гілок?</summary>
+
+#### GIT
+
+1. **Гілка для основної версії (main/master)**
+
+- Використовується для стабільного коду, який завжди готовий до деплою.
+
+2. **Гілки для релізів (release branches)**
+
+- Кожна підтримувана версія продукту має свою гілку, напр.:
+
+```arduino
+release/1.0
+release/1.1
+release/2.0
+```
+
+- На цих гілках виправляються баги, без нових функцій.
+
+3. **Гілки для розробки (feature branches)**
+
+- Створюються від main або від конкретної release/\* для нових функцій або
+  критичних патчів.
+
+3. **Злиття та backport**
+
+- Багфікси з нових релізів можна переносити (backport) у старі версії:
+
+```bash
+git checkout release/1.0
+git cherry-pick <bugfix_commit_hash>
+```
+
+5. **Тегування версій**
+
+- Кожен стабільний реліз позначати тегом для швидкого rollback або деплою:
+
+```bash
+git tag -a v1.0.0 -m "Release 1.0.0"
+git push origin v1.0.0
+```
+
+#### Порада:
+
+- Використовувати стратегію Gitflow або спрощений Release Branch Workflow.
+
+- Кожна версія продукту підтримується окремою гілкою, що дозволяє паралельно
+  виправляти баги у старих релізах, не блокуючи нову розробку.
+
+</details>
+
+<details>
+<summary>101. ???</summary>
 
 #### GIT