diff --git a/README.md b/README.md index d4ea752..c5b5bf6 100644 --- a/README.md +++ b/README.md @@ -853,7 +853,290 @@ git push origin <гілка>
-31. ??? +31. Що таке розподілена система контролю версій і як Git реалізує цей підхід? + +#### GIT + +- Розподілена система контролю версій (DVCS) — це система, де кожен розробник + має повну копію репозиторію з історією комітів, а не лише робочі файли. + +**Git функціонує як DVCS так:** + +- Клонуючи репозиторій, отримуєш усю історію локально. + +- Коміти, гілки, теги створюються локально й не потребують підключення до + сервера. + +- Синхронізація між розробниками відбувається через push/pull у віддалений + репозиторій (наприклад, GitHub). + +- Це дає швидкість, автономність і можливість працювати офлайн. + +
+ +
+32. Що таке Git Feature Branch Workflow і як він працює? + +#### GIT + +- Feature Branch Workflow — підхід, коли для кожної нової задачі чи фічі + створюється окрема гілка: + +1. Від main або develop відгалужується feature/\*. + +2. Розробка й коміти відбуваються тільки там. + +3. Коли фіча готова → відкривається Pull Request. + +4. Після code review і CI зміни вливаються назад у develop/main. + +5. Feature-гілка видаляється. + +Перевага: ізоляція змін, паралельна робота без конфліктів, чиста історія. + +
+ +
+33. Що таке Gitflow Workflow і як він працює? + +#### GIT + +- **Gitflow** — це модель роботи з Git із чіткими правилами для різних типів + гілок: + + - `main` → завжди стабільна продакшн-версія. + + - `develop` → інтеграційна гілка для активної розробки. + + - `feature/` → створюються від develop, після завершення зливаються назад у + develop. + + - `release/` → відгалуження від develop для підготовки релізу, після тестів + вливається в main і develop. + + - `hotfix/` → відгалуження від main для термінових виправлень, потім + зливається і в main, і в develop. + +✅ **Плюси:** чітка структура, контрольована розробка і релізи. ❌ **Мінуси:** +громіздкий процес для маленьких команд або continuous delivery. + +
+ +
+34. Що таке Forking Workflow у Git і як він працює? + +#### GIT + +- **Forking Workflow** — це підхід, коли кожен розробник працює не з основним + репозиторієм напряму, а зі своєю копією (fork). + +#### Процес: + +1. Розробник робить fork головного репозиторію у своєму GitHub/GitLab. + +2. Клонує свій fork локально й створює гілку для змін. + +3. Після завершення роботи пушить у свій fork. + +4. Відкриває Pull Request з власного fork у головний репозиторій. + +5. Після рев’ю та схвалення зміни зливаються в upstream. + +Використовується у великих open-source проєктах, де стороннім контриб’юторам не +дають прямого доступу до основного репозиторію. + +
+ +
+35. Що таке Centralized Workflow у Git і як він працює? + +#### GIT + +- **Centralized Workflow** — це модель, де є одна головна гілка (зазвичай main), + і всі розробники працюють прямо в ній або створюють короткоживучі гілки тільки + для малих задач. + +#### Процес: + +1. Усі клонують один remote-репозиторій. + +2. Розробники роблять зміни й одразу пушать у main. + +3. Якщо є конфлікти — вирішують перед пушем. + +📌 Це схоже на старі централізовані системи (SVN), але з перевагами Git +(локальна історія, робота офлайн). + +✅ Простий процес, мінімум гілок. ❌ Важко масштабувати в команді: часто +виникають конфлікти, немає ізоляції фіч. + +
+ +
+36. Що таке remote repository у Git і для чого він потрібен? + +#### 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 # отримати зміни +``` + +
+ +
+37. Як змінити URL remote-репозиторію в Git? + +#### 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. + +
+ +
+38. Які команди використовуються, щоб синхронізувати локальний репозиторій з remote у Git? + +#### GIT + +1. Отримати останні зміни з remote: + +```bash +git fetch origin +``` + +2. Об’єднати з локальною гілкою: + +```bash +git pull origin main +``` + +- (еквівалент fetch + merge). + +3. Відправити свої зміни на remote: + +```bash +git push origin main +``` + +Коротко: pull → підтягнути зміни, push → відправити свої. + +
+ +
+39. Як видалити невикористані (застарілі) гілки локально й на remote у Git? + +#### 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-гілки, щоб не захаращувати +репозиторій. + +
+ +
+40. Які кроки потрібно виконати для вирішення merge conflict у Git? + +#### 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 +``` + +6. Продовжити merge/rebase: + +```bash +git commit # якщо merge git rebase --continue # якщо rebase +``` + +7. Перевірити, що все працює, і пушити зміни: + +```bash +git push origin main +``` + +
+ +
+41. ??? #### GIT