Develop

README.md

@@ -853,7 +853,290 @@ git push origin <гілка>
 </details>
 
 <details>
-<summary>31. ???</summary>
+<summary>31. Що таке розподілена система контролю версій і як Git реалізує цей підхід?</summary>
+
+#### GIT
+
+- Розподілена система контролю версій (DVCS) — це система, де кожен розробник
+  має повну копію репозиторію з історією комітів, а не лише робочі файли.
+
+**Git функціонує як DVCS так:**
+
+- Клонуючи репозиторій, отримуєш усю історію локально.
+
+- Коміти, гілки, теги створюються локально й не потребують підключення до
+  сервера.
+
+- Синхронізація між розробниками відбувається через push/pull у віддалений
+  репозиторій (наприклад, GitHub).
+
+- Це дає швидкість, автономність і можливість працювати офлайн.
+
+</details>
+
+<details>
+<summary>32. Що таке Git Feature Branch Workflow і як він працює?</summary>
+
+#### GIT
+
+- Feature Branch Workflow — підхід, коли для кожної нової задачі чи фічі
+  створюється окрема гілка:
+
+1. Від main або develop відгалужується feature/\*.
+
+2. Розробка й коміти відбуваються тільки там.
+
+3. Коли фіча готова → відкривається Pull Request.
+
+4. Після code review і CI зміни вливаються назад у develop/main.
+
+5. Feature-гілка видаляється.
+
+Перевага: ізоляція змін, паралельна робота без конфліктів, чиста історія.
+
+</details>
+
+<details>
+<summary>33. Що таке Gitflow Workflow і як він працює?</summary>
+
+#### GIT
+
+- **Gitflow** — це модель роботи з Git із чіткими правилами для різних типів
+  гілок:
+
+  - `main` → завжди стабільна продакшн-версія.
+
+  - `develop` → інтеграційна гілка для активної розробки.
+
+  - `feature/` → створюються від develop, після завершення зливаються назад у
+    develop.
+
+  - `release/` → відгалуження від develop для підготовки релізу, після тестів
+    вливається в main і develop.
+
+  - `hotfix/` → відгалуження від main для термінових виправлень, потім
+    зливається і в main, і в develop.
+
+✅ **Плюси:** чітка структура, контрольована розробка і релізи. ❌ **Мінуси:**
+громіздкий процес для маленьких команд або continuous delivery.
+
+</details>
+
+<details>
+<summary>34. Що таке Forking Workflow у Git і як він працює?</summary>
+
+#### GIT
+
+- **Forking Workflow** — це підхід, коли кожен розробник працює не з основним
+  репозиторієм напряму, а зі своєю копією (fork).
+
+#### Процес:
+
+1. Розробник робить fork головного репозиторію у своєму GitHub/GitLab.
+
+2. Клонує свій fork локально й створює гілку для змін.
+
+3. Після завершення роботи пушить у свій fork.
+
+4. Відкриває Pull Request з власного fork у головний репозиторій.
+
+5. Після рев’ю та схвалення зміни зливаються в upstream.
+
+Використовується у великих open-source проєктах, де стороннім контриб’юторам не
+дають прямого доступу до основного репозиторію.
+
+</details>
+
+<details>
+<summary>35. Що таке Centralized Workflow у Git і як він працює?</summary>
+
+#### GIT
+
+- **Centralized Workflow** — це модель, де є одна головна гілка (зазвичай main),
+  і всі розробники працюють прямо в ній або створюють короткоживучі гілки тільки
+  для малих задач.
+
+#### Процес:
+
+1. Усі клонують один remote-репозиторій.
+
+2. Розробники роблять зміни й одразу пушать у main.
+
+3. Якщо є конфлікти — вирішують перед пушем.
+
+📌 Це схоже на старі централізовані системи (SVN), але з перевагами Git
+(локальна історія, робота офлайн).
+
+✅ Простий процес, мінімум гілок. ❌ Важко масштабувати в команді: часто
+виникають конфлікти, немає ізоляції фіч.
+
+</details>
+
+<details>
+<summary>36. Що таке remote repository у Git і для чого він потрібен?</summary>
+
+#### GIT
+
+- Віддалений репозиторій (remote) — це версія Git-репозиторію, що зберігається
+  на сервері (GitHub, GitLab, Bitbucket).
+
+#### Призначення:
+
+- Спільна робота команди (push/pull змін).
+
+- Централізоване зберігання коду та історії.
+
+- Інтеграція з CI/CD.
+
+#### Приклади команд:
+
+```bash
+git remote -v              # переглянути підключені remote
+git remote add origin URL  # додати віддалений репозиторій
+git push origin main       # відправити зміни
+git pull origin main       # отримати зміни
+```
+
+</details>
+
+<details>
+<summary>37. Як змінити URL remote-репозиторію в Git?</summary>
+
+#### GIT
+
+- Для оновлення URL використовують команду:
+
+```bash
+git remote set-url origin <новий_URL>
+```
+
+- Перевірити зміни можна так:
+
+```bash
+git remote -v
+```
+
+- Або замінити remote повністю:
+
+```bash
+git remote remove origin
+git remote add origin <новий_URL>
+```
+
+Використовується, наприклад, при переході з HTTPS на SSH чи зміні репозиторію на
+GitHub/GitLab.
+
+</details>
+
+<details>
+<summary>38. Які команди використовуються, щоб синхронізувати локальний репозиторій з remote у Git?</summary>
+
+#### GIT
+
+1. Отримати останні зміни з remote:
+
+```bash
+git fetch origin
+```
+
+2. Об’єднати з локальною гілкою:
+
+```bash
+git pull origin main
+```
+
+- (еквівалент fetch + merge).
+
+3. Відправити свої зміни на remote:
+
+```bash
+git push origin main
+```
+
+Коротко: pull → підтягнути зміни, push → відправити свої.
+
+</details>
+
+<details>
+<summary>39. Як видалити невикористані (застарілі) гілки локально й на remote у Git?</summary>
+
+#### GIT
+
+- Локально:
+
+```bash
+git branch -d branch_name      # видалити вже злиту гілку
+git branch -D branch_name      # примусово видалити
+```
+
+- Віддалено:
+
+```bash
+git push origin --delete branch_name
+```
+
+- Очистити локальний список remote-гілок (які вже видалені на сервері):
+
+```bash
+git fetch --prune
+```
+
+Практика: після merge у main видаляємо feature-гілки, щоб не захаращувати
+репозиторій.
+
+</details>
+
+<details>
+<summary>40. Які кроки потрібно виконати для вирішення merge conflict у Git?</summary>
+
+#### GIT
+
+1. Спробувати злиття або rebase:
+
+```bash
+git merge feature/my-task
+```
+
+2. Git повідомляє про конфлікти. Перевірити файли:
+
+```bash
+git status
+```
+
+3. Відкрити конфліктні файли, знайти маркери:
+
+```python
+<<<<<<< HEAD
+...
+=======
+...
+> > > > > > > feature/my-task
+```
+
+4. Вирішити конфлікт вручну (залишити потрібні зміни).
+
+5. Позначити файли як вирішені:
+
+```bash
+git add <file>
+```
+
+6. Продовжити merge/rebase:
+
+```bash
+git commit # якщо merge git rebase --continue # якщо rebase
+```
+
+7. Перевірити, що все працює, і пушити зміни:
+
+```bash
+git push origin main
+```
+
+</details>
+
+<details>
+<summary>41. ???</summary>
 
 #### GIT