Merge pull request #5 from DevLoversTeam/develop

Develop

Author: ViktorSvertoka

README.md

@@ -579,7 +579,281 @@ Merge дозволяє безпечно інтегрувати паралель
 </details>
 
 <details>
-<summary>21. ???</summary>
+<summary>21. Який Git workflow ви зазвичай використовуєте в роботі?</summary>
+
+#### GIT
+
+- Найчастіше використовую Git Flow / Feature Branch Workflow:
+
+  - `main` — завжди стабільна продакшн-версія.
+
+  - `develop` — інтеграційна гілка для нових фіч.
+
+  - для задач створюю окрему `feature`.
+
+  - після завершення — `pull request` → `code review` → `merge у develop`.
+
+  - перед релізом створюється `release`, після тестів — `merge у main` + тег.
+
+  - багфікси йдуть у `hotfix` від main.
+
+Цей процес дисциплінує, дає прозорість і контроль над релізами.
+
+</details>
+
+<details>
+<summary>22. Опишіть кроки створення нової гілки та її злиття в main.</summary>
+
+#### GIT
+
+1. Переконуюсь, що локальний main оновлений:
+
+```bash
+git checkout main
+git pull origin main
+```
+
+2. Створюю нову гілку від main:
+
+```bash
+git checkout -b feature/my-task
+```
+
+3. Працюю, комічу зміни:
+
+```bash
+git add .
+git commit -m "Implement feature X"
+```
+
+4. Пушу гілку на remote:
+
+```bash
+git push origin feature/my-task
+```
+
+5. Відкриваю Pull Request → проходить code review → CI.
+
+6. Мерджу в main (звичайно через squash або rebase, щоб історія була чистою).
+
+7. Видаляю feature-гілку локально і на remote.
+
+</details>
+
+<details>
+<summary>23. Що таке merge conflict у Git і як його вирішують?</summary>
+
+#### GIT
+
+- Merge conflict виникає, коли дві гілки змінюють один і той самий рядок коду
+  або файл у несумісний спосіб, і Git не може автоматично об’єднати зміни.
+
+#### Рішення:
+
+1. Виконати merge/rebase → Git покаже конфліктні файли.
+
+2. Відкрити файл, знайти маркери <<<<<<<, =======, >>>>>>>.
+
+3. Вибрати або об’єднати потрібні зміни вручну.
+
+4. Позначити файл як вирішений:
+
+```bash
+git add <file>
+```
+
+5. Завершити merge/rebase комітом:
+
+```bash
+git commit
+```
+
+</details>
+
+<details>
+<summary>24. Що таке fast-forward merge у Git?</summary>
+
+#### GIT
+
+- Fast-forward merge — це злиття, коли гілка-ціль (наприклад main) не має нових
+  комітів після відгалуження feature-гілки. Тоді Git просто пересуває вказівник
+  main на останній коміт feature-гілки без створення додаткового merge-коміту.
+
+#### Приклад:
+
+```bash
+git checkout main
+git merge feature/my-task --ff
+```
+
+Це "чисте" злиття без зайвих комітів.
+
+</details>
+
+<details>
+<summary>25. Що таке three-way merge у Git?</summary>
+
+#### GIT
+
+- Three-way merge — це злиття, коли Git використовує три точки для об’єднання:
+
+1. `common ancestor` (базовий коміт, від якого розійшлися гілки),
+
+2. `HEAD` (останній коміт у цільовій гілці, наприклад main),
+
+3. `branch tip` (останній коміт у зливаній гілці, наприклад feature).
+
+Git порівнює зміни відносно спільного предка й створює новий merge-коміт, що має
+двох батьків.
+
+Цей підхід застосовується, коли fast-forward неможливий (тобто в обох гілках є
+нові коміти).
+
+</details>
+
+<details>
+<summary>26. Які кроки виконати, щоб перебазувати (rebase) гілку в Git?</summary>
+
+#### GIT
+
+1. Перейти в свою гілку:
+
+```bash
+git checkout feature/my-task
+```
+
+2. Виконати rebase на актуальну main:
+
+```bash
+git fetch origin git rebase origin/main
+```
+
+3. Якщо є конфлікти — вирішити їх, додати файли:
+
+```bash
+git add <file> git rebase --continue
+```
+
+4. Коли все готово — оновити remote (з форсом, бо історія переписана):
+
+```bash
+git push origin feature/my-task --force
+```
+
+Rebase робить історію лінійною, на відміну від merge.
+
+</details>
+
+<details>
+<summary>27. Які плюси й мінуси rebase у порівнянні з merge?</summary>
+
+#### GIT
+
+✅ **Переваги rebase**
+
+- Лінійна, чиста історія без merge-комітів.
+
+- Зручніше читати git log, легше дебажити.
+
+- Кожен коміт виглядає так, ніби зроблений поверх останнього main.
+
+❌ **Недоліки rebase**
+
+- Переписує історію (особливо небезпечно для спільних гілок).
+
+- Потрібен --force push, що може зламати історію іншим.
+
+- Вимагає більшої дисципліни в команді.
+
+✅ **Переваги merge**
+
+- Зберігає повну історію розробки, без переписування.
+
+- Безпечний для командної роботи.
+
+- Простий у використанні.
+
+❌ **Недоліки merge**
+
+- Брудніший git log з великою кількістю merge-комітів.
+
+- Історію важче аналізувати.
+
+Загалом: merge — безпечніше для команд, rebase — краще для чистої історії.
+
+</details>
+
+<details>
+<summary>28. Для чого використовуються теги в Git?</summary>
+
+#### GIT
+
+- Теги в Git — це фіксовані маркери на певні коміти, зазвичай для позначення
+  релізів (v1.0, v2.1).
+
+  - `Lightweight tag` — просто вказівка на коміт, без додаткової інформації.
+
+  - `Annotated tag` — зберігає автора, дату, повідомлення і може бути підписаний
+    GPG.
+
+#### Теги зручні для:
+
+- Відстеження версій у продакшн.
+
+- Швидкого переходу на конкретний реліз:
+
+```bash
+git checkout v1.0
+```
+
+- CI/CD для автоматичного деплою.
+
+</details>
+
+<details>
+<summary>29. Як скасувати коміт, який вже запушено на remote?</summary>
+
+#### GIT
+
+1. Якщо потрібно повністю видалити коміт (історія переписується, небезпечно для
+   інших):
+
+```bash
+git reset --hard <коміт_до_потрібного>
+git push origin <гілка> --force
+```
+
+2. Якщо потрібно зберегти історію, створивши "відкат" без перепису:
+
+```bash
+git revert <hash_коміту>
+git push origin <гілка>
+```
+
+- `reset --hard` + `force push` змінює історію (небезпечно для спільних гілок).
+
+- `revert` створює новий коміт, що відміняє зміни — безпечніше для команд.
+
+</details>
+
+<details>
+<summary>30. Яке призначення головної гілки (main/master) у Git?</summary>
+
+#### GIT
+
+Головна гілка (main або раніше master) — це стабільна, завжди робоча версія
+проєкту, на яку орієнтуються всі інші гілки.
+
+- Від неї створюють feature-, release-, hotfix-гілки.
+
+- Вона слугує базою для релізів.
+
+- Зазвичай на ній запускається CI/CD і деплой в продакшн.
+
+</details>
+
+<details>
+<summary>31. ???</summary>
 
 #### GIT