Merge pull request #8 from DevLoversTeam/develop

Develop

Author: ViktorSvertoka

README.md

@@ -1405,7 +1405,342 @@ git blame -L 10,20 app.js   # лише рядки з 10 по 20
 </details>
 
 <details>
-<summary>51. ???</summary>
+<summary>51. Що таке теги в Git і чим вони відрізняються від гілок?</summary>
+
+#### GIT
+
+- Тег — це фіксована позначка на конкретному коміті, зазвичай для релізів (v1.0,
+  v2.1).
+
+- Гілка — це рухомий вказівник на останній коміт у лінії розробки, куди
+  додаються нові коміти.
+
+#### Основні відмінності:
+
+| Характеристика | Тег                | Гілка                  |
+| -------------- | ------------------ | ---------------------- |
+| Рухливість     | Нерухомий          | Рухливий               |
+| Використання   | Позначення релізів | Розробка нових функцій |
+| Коміти         | Не додаються нові  | Додаються нові коміти  |
+
+#### Приклад створення тега:
+
+```bash
+git tag v1.0 git push origin v1.0
+```
+
+</details>
+
+<details>
+<summary>52. Як у Git створювати, видаляти та пушити теги?</summary>
+
+#### GIT
+
+**Створення тегів:**
+
+- Lightweight тег:
+
+```bash
+git tag v1.0
+```
+
+- Annotated тег (з повідомленням):
+
+```bash
+git tag -a v1.0 -m "Release version 1.0"
+```
+
+**Видалення тегів:**
+
+- Локально:
+
+```bash
+git tag -d v1.0
+```
+
+- Віддалено:
+
+```bash
+git push origin --delete tag v1.0
+```
+
+**Надсилання тегів на remote:**
+
+- Один тег:
+
+```bash
+git push origin v1.0
+```
+
+- Всі теги:
+
+```bash
+git push origin --tags
+```
+
+</details>
+
+<details>
+<summary>53. Що таке семантичне версіонування і як його використовують у Git-тегах?</summary>
+
+#### GIT
+
+- Семантичне версіонування (SemVer) — це система нумерації версій у форматі
+  MAJOR.MINOR.PATCH, яка відображає характер змін у релізі:
+
+  - `MAJOR` — несумісні зміни API.
+
+  - `MINOR` — додані нові функції, сумісні з попередньою версією.
+
+  - `PATCH` — виправлення багів без зміни функціоналу.
+
+- У Git-тегах використовують SemVer, щоб:
+
+  - Позначати релізи (v1.2.3).
+
+  - Легко відстежувати стабільність та сумісність версій.
+
+  - Інтегруватися з CI/CD для автоматичного деплою конкретних версій.
+
+</details>
+
+<details>
+<summary>54. Як у Git перейти на конкретний тег?</summary>
+
+#### GIT
+
+- Теги самі по собі не є гілками, тому перехід на них робить репозиторій у
+  detached HEAD стані:
+
+```bash
+git checkout v1.0
+```
+
+- Або з новішим синтаксисом:
+
+```bash
+git switch --detach v1.0
+```
+
+📌 У цьому режимі можна переглядати код, збирати чи тестувати, але нові коміти
+не будуть прив’язані до жодної гілки.
+
+- Щоб працювати далі з тегу як із гілки:
+
+```bash
+git checkout -b release-1.0 v1.0
+```
+
+</details>
+
+<details>
+<summary>55. Як у Git створити реліз на основі тегу?</summary>
+
+#### GIT
+
+1. Створити тег на потрібному коміті:
+
+```bash
+git tag -a v1.0.0 -m "Release 1.0.0"
+```
+
+2. Надіслати тег у віддалений репозиторій:
+
+```bash
+git push origin v1.0.0
+```
+
+(або всі теги: git push origin --tags)
+
+3. У системі керування кодом (GitHub/GitLab/Bitbucket) на основі цього тега
+   можна створити реліз:
+
+   - GitHub: вкладка Releases → Draft a new release → вибрати тег.
+
+   - Додати опис змін (changelog).
+
+   - Опублікувати реліз.
+
+📌 Реліз із тегу зручний для CI/CD — можна налаштувати автоматичне збирання та
+деплой за певними тегами.
+
+</details>
+
+<details>
+<summary>56. Що таке Git submodule і в яких випадках його доцільно використовувати?</summary>
+
+#### GIT
+
+**Git submodule** — це механізм, що дозволяє вбудовувати один репозиторій у
+інший як залежність. Він зберігає посилання на конкретний коміт іншого
+репозиторію.
+
+#### Використовують, коли:
+
+- Є спільна бібліотека/модуль, який використовується в кількох проєктах.
+
+- Потрібно зафіксувати залежність на певному коміті, а не останню версію.
+
+- Хочеться уникнути копіювання коду між репозиторіями.
+
+#### Приклад додавання підмодуля:
+
+```bash
+git submodule add https://github.com/example/lib.git libs/lib
+git submodule update --init --recursive
+```
+
+❌ Мінуси: складніший workflow (оновлення вручну), можуть виникати проблеми при
+клонуванні без --recursive.
+
+</details>
+
+<details>
+<summary>57. Що таке Git hooks і для чого вони потрібні?</summary>
+
+#### GIT
+
+**Git hooks** — це скрипти, які автоматично виконуються при певних подіях у
+репозиторії (наприклад, перед комітом, після злиття, перед пушем). Вони
+зберігаються у .git/hooks.
+
+#### Використання:
+
+- Перевірка стилю коду / запуск linter перед git commit (pre-commit).
+
+- Заборона пушу у main напряму (pre-push).
+
+- Автоматичне оновлення залежностей або документації після злиття (post-merge).
+
+- Генерація changelog з повідомлень комітів.
+
+#### Приклад: pre-commit для перевірки ESLint:
+
+```bash
+#!/bin/sh
+npm run lint
+if [ $? -ne 0 ]; then
+  echo "Lint errors found. Commit aborted."
+  exit 1
+fi
+```
+
+</details>
+
+<details>
+<summary>58. Як у Git об’єднати кілька комітів у один (squash)?</summary>
+
+#### GIT
+
+- **Squash** роблять через інтерактивне перебазування:
+
+```bash
+git rebase -i HEAD~N
+```
+
+- де N — кількість останніх комітів, які треба переглянути.
+
+#### Далі в редакторі:
+
+- залишаєш перший коміт як pick,
+
+- для наступних змінюєш pick на squash (або s).
+
+Після збереження — Git об’єднає коміти, запропонує відредагувати повідомлення.
+
+#### Використання:
+
+- очистка історії перед злиттям у main,
+
+- зручний changelog,
+
+- уникнення зайвих "дрібних" комітів.
+
+</details>
+
+<details>
+<summary>59. Що таке git bisect і як із ним працювати?</summary>
+
+#### GIT
+
+- `git bisect` — це інструмент Git для бінарного пошуку коміту, який ввів баг.
+  Він автоматично звужує діапазон між `“good”` і `“bad”` комітами.
+
+#### Використання:
+
+1. Запустити:
+
+```bash
+git bisect start
+git bisect bad                # вказати коміт з багом
+git bisect good <commit_hash> # вказати коміт, де все працювало
+```
+
+2. Git переключається на середній коміт. Ви тестуєте і кажете Git:
+
+```bash
+git bisect good   # якщо багу немає
+git bisect bad    # якщо баг є
+```
+
+3. Повторює, доки не знайде проблемний коміт.
+
+4. Завершення:
+
+```bash
+git bisect reset
+```
+
+Використовується для швидкого знаходження помилок у великих історіях проєкту.
+
+</details>
+
+<details>
+<summary>60. Як вручну вирішити конфлікт при злитті в Git?</summary>
+
+#### GIT
+
+1. Виконати злиття:
+
+```bash
+git merge feature-branch
+```
+
+- Git зупиниться на конфліктах.
+
+2. Відкрити файли з конфліктами — вони містять маркери:
+
+```bash
+<<<<<<< HEAD
+код з поточної гілки
+=======
+код з feature-branch
+>>>>>>> feature-branch
+```
+
+3. Вручну вибрати або об’єднати потрібні зміни, видалити маркери.
+
+4. Позначити файл як вирішений:
+
+```bash
+git add <file>
+```
+
+5. Завершити злиття:
+
+```bash
+git commit
+```
+
+(якщо Git не зробив commit автоматично).
+
+Порада: можна використовувати інструменти для merge (наприклад, VS Code,
+IntelliJ, Meld).
+
+</details>
+
+<details>
+<summary>61. ???</summary>
 
 #### GIT