From e676f67aa11e6737e3a7c09ac80c532e9407c046 Mon Sep 17 00:00:00 2001 From: ViktorSvertoka Date: Fri, 1 Aug 2025 20:43:22 +0300 Subject: [PATCH 01/18] Docs(MD): Added interview questions and answers --- README.md | 205 +++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 204 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 1af862b..902d37f 100644 --- a/README.md +++ b/README.md @@ -2438,7 +2438,210 @@ Sourcetree/IntelliJ для візуального вирішення конфл
-81. ??? +81. Які підходи використовують для роботи з великими файлами в Git? + +#### 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-артефактів. + +
+ +
+82. ??? + +#### GIT + +- Coming Soon... 😎 + +
+ +
+83. ??? + +#### GIT + +- Coming Soon... 😎 + +
+ +
+84. ??? + +#### GIT + +- Coming Soon... 😎 + +
+ +
+85. ??? + +#### GIT + +- Coming Soon... 😎 + +
+ +
+86. ??? + +#### GIT + +- Coming Soon... 😎 + +
+ +
+87. ??? + +#### GIT + +- Coming Soon... 😎 + +
+ +
+88. ??? + +#### GIT + +- Coming Soon... 😎 + +
+ +
+89. ??? + +#### GIT + +- Coming Soon... 😎 + +
+ +
+90. ??? + +#### GIT + +- Coming Soon... 😎 + +
+ +
+91. ??? + +#### GIT + +- Coming Soon... 😎 + +
+ +
+92. ??? + +#### GIT + +- Coming Soon... 😎 + +
+ +
+93. ??? + +#### GIT + +- Coming Soon... 😎 + +
+ +
+94. ??? + +#### GIT + +- Coming Soon... 😎 + +
+ +
+95. ??? + +#### GIT + +- Coming Soon... 😎 + +
+ +
+96. ??? + +#### GIT + +- Coming Soon... 😎 + +
+ +
+97. ??? + +#### GIT + +- Coming Soon... 😎 + +
+ +
+98. ??? + +#### GIT + +- Coming Soon... 😎 + +
+ +
+99. ??? + +#### GIT + +- Coming Soon... 😎 + +
+ +
+100. ??? + +#### GIT + +- Coming Soon... 😎 + +
+ +
+101. ??? #### GIT From f18f82db1b89a9d23a5f7f9a3f488a03312c9861 Mon Sep 17 00:00:00 2001 From: ViktorSvertoka Date: Fri, 1 Aug 2025 20:48:07 +0300 Subject: [PATCH 02/18] Docs(MD): Added interview questions and answers --- README.md | 38 ++++++++++++++++++++++++++++++++++++-- 1 file changed, 36 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 902d37f..9007000 100644 --- a/README.md +++ b/README.md @@ -2470,11 +2470,45 @@ build-артефактів.
-82. ??? +82. Які техніки можна застосувати для підвищення продуктивності при роботі з великим репозиторієм Git? #### GIT -- Coming Soon... 😎 +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-білдів.
From d91165ff89f44436cab1c5b754e1a46b70bb420b Mon Sep 17 00:00:00 2001 From: ViktorSvertoka Date: Fri, 1 Aug 2025 20:50:18 +0300 Subject: [PATCH 03/18] Docs(MD): Added interview questions and answers --- README.md | 28 ++++++++++++++++++++++++++-- 1 file changed, 26 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 9007000..eced048 100644 --- a/README.md +++ b/README.md @@ -2513,11 +2513,35 @@ git gc --aggressive --prune=now
-83. ??? +83. Що таке shallow clone у Git і коли доцільно його застосовувати? #### GIT -- Coming Soon... 😎 +**Shallow clone** — це клон репозиторію з обмеженою історією комітів. +Виконується командою: + +```bash +git clone --depth +``` + +де `` — кількість останніх комітів, які потрібно завантажити. + +#### Переваги: + +- значно швидше клонування; + +- менший розмір репозиторію; + +- корисно для CI/CD, де потрібен лише останній стан коду. + +#### Недоліки: + +- обмежена історія (неможливо повноцінно досліджувати старі коміти); + +- складніше працювати з перебазуванням і пошуком у глибокій історії. + +Використовують, коли потрібен лише актуальний стан проєкту без повної історії +(наприклад, білд на CI).
From dc942ba4401db59068ac592afa572828acf3b994 Mon Sep 17 00:00:00 2001 From: ViktorSvertoka Date: Fri, 1 Aug 2025 20:53:28 +0300 Subject: [PATCH 04/18] Docs(MD): Added interview questions and answers --- README.md | 44 ++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 42 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index eced048..9600c43 100644 --- a/README.md +++ b/README.md @@ -2546,11 +2546,51 @@ git clone --depth
-84. ??? +84. Які підходи можна застосувати для зменшення розміру репозиторію Git? #### GIT -- Coming Soon... 😎 +1. Прибрати непотрібні файли з історії + +- Використати git filter-repo (сучасний варіант git filter-branch): + +```bash +git filter-repo --path --invert-paths +``` + +- (видалить файл з усієї історії). + +2. Очистити великі файли у репозиторії + +- Інтегрувати Git LFS для зберігання бінарників/медіа окремо. + +3. Запустити прибирання + +```bash +git gc --aggressive --prune=now +``` + +- (стисне об’єкти й прибере сміття). + +4. Видалити старі гілки та теги + +- Локально: + +```bash +git branch -D +``` + +- Віддалено: + +```bash +git push origin --delete +``` + +5. Використовувати shallow clone (--depth 1) на CI/CD для швидших зборок, + замість повного репо. + +У реальних командах основний варіант — перенесення великих файлів у Git LFS + +чистка історії filter-repo.
From b7d56d1ae997487d960d664491680fe517709e6a Mon Sep 17 00:00:00 2001 From: ViktorSvertoka Date: Fri, 1 Aug 2025 20:56:43 +0300 Subject: [PATCH 05/18] Docs(MD): Added interview questions and answers --- README.md | 49 +++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 47 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 9600c43..b42ecdb 100644 --- a/README.md +++ b/README.md @@ -2595,11 +2595,56 @@ git push origin --delete
-85. ??? +85. Що таке Git LFS і як ним користуватись? #### GIT -- Coming Soon... 😎 +**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 підтримують, але є ліміти); + +- обмеження за розміром файлів/трафіку (особливо у безкоштовних планах). + +Використовують тоді, коли в проєкті є важкі бінарні чи медіафайли, які часто +оновлюються.
From 316bfdb29db4486cb287c2af3437ce45a504683f Mon Sep 17 00:00:00 2001 From: ViktorSvertoka Date: Fri, 1 Aug 2025 20:59:04 +0300 Subject: [PATCH 06/18] Docs(MD): Added interview questions and answers --- README.md | 35 +++++++++++++++++++++++++++++++++-- 1 file changed, 33 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index b42ecdb..bed8668 100644 --- a/README.md +++ b/README.md @@ -2649,11 +2649,42 @@ git push origin main
-86. ??? +86. Як Git інтегрується в CI/CD-процеси? #### GIT -- Coming Soon... 😎 +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 — автоматизація всіх подальших +процесів.
From 40db409a2c7648d5332e8577feb47e08f8618596 Mon Sep 17 00:00:00 2001 From: ViktorSvertoka Date: Fri, 1 Aug 2025 21:02:40 +0300 Subject: [PATCH 07/18] Docs(MD): Added interview questions and answers --- README.md | 40 ++++++++++++++++++++++++++++++++++++++-- 1 file changed, 38 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index bed8668..adfdebc 100644 --- a/README.md +++ b/README.md @@ -2689,11 +2689,47 @@ Jenkins, Azure DevOps тощо) інтегруються з ним через п
-87. ??? +87. Як налаштовується автоматизоване розгортання (deployment) з використанням Git? #### GIT -- Coming Soon... 😎 +Автоматизоване розгортання з 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 — це тригер і контроль версій, а автоматизація виконується +пайплайнами, що читають код і конфіг з репозиторію.
From 5d3dda761284edf6fb2b6fbbcbbe28ab449f0f49 Mon Sep 17 00:00:00 2001 From: ViktorSvertoka Date: Fri, 1 Aug 2025 21:05:59 +0300 Subject: [PATCH 08/18] Docs(MD): Added interview questions and answers --- README.md | 45 +++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 43 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index adfdebc..5b19584 100644 --- a/README.md +++ b/README.md @@ -2734,11 +2734,52 @@ Jenkins, Azure DevOps тощо) інтегруються з ним через п
-88. ??? +88. Як налаштувати правила захисту гілок у Git, щоб інтегрувати їх із CI/CD? #### GIT -- Coming Soon... 😎 +**Призначення** — захищені гілки (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, а у +продакшен не потрапить "сирий" код.
From e1dac1162a501461738976969c59ca4b63828cc7 Mon Sep 17 00:00:00 2001 From: ViktorSvertoka Date: Fri, 1 Aug 2025 21:08:56 +0300 Subject: [PATCH 09/18] Docs(MD): Added interview questions and answers --- README.md | 38 ++++++++++++++++++++++++++++++++++++-- 1 file changed, 36 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 5b19584..a3ec8db 100644 --- a/README.md +++ b/README.md @@ -2784,11 +2784,45 @@ Jenkins, Azure DevOps тощо) інтегруються з ним через п
-89. ??? +89. Яку роль відіграють Git hooks (гачки) в автоматизації процесів? #### GIT -- Coming Soon... 😎 +- **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.
From a5d5ce8f9f4916f37e50c83c8c44beb09e439c32 Mon Sep 17 00:00:00 2001 From: ViktorSvertoka Date: Fri, 1 Aug 2025 22:29:26 +0300 Subject: [PATCH 10/18] Docs(MD): Added interview questions and answers --- README.md | 35 +++++++++++++++++++++++++++++++++-- 1 file changed, 33 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index a3ec8db..ccb33a8 100644 --- a/README.md +++ b/README.md @@ -2827,11 +2827,42 @@ Jenkins, Azure DevOps тощо) інтегруються з ним через п
-90. ??? +90. Як Git використовується для відкату змін у разі невдалого деплою? #### GIT -- Coming Soon... 😎 +- Git робить відкат безпечним, оскільки кожен реліз — це фіксований коміт або + тег. У випадку невдалого розгортання: + +1. **Повернення до стабільної версії** + +- checkout на попередній тег/коміт: + +```bash +git checkout v1.2.3 +``` + +- деплой цього стану коду. + +2. **Використання git revert** + +- створює новий коміт, що відміняє зміни проблемного: + +```bash +git revert +``` + +3. **CI/CD інтеграція** + +- у пайплайні зазвичай деплої відбуваються з тегів або main/master. + +- можна швидко redeploy попереднього тегу без ручного втручання. + +4. **Blue-Green / Canary деплоймент** (залежить від інфраструктури, але Git + виступає як джерело істини для коду). + +Головна ідея: Git дозволяє миттєво відтворити будь-який попередній стан коду, що +робить rollback контрольованим і передбачуваним.
From a0a66f19ecc898794cf6c45b389227d12aef2315 Mon Sep 17 00:00:00 2001 From: ViktorSvertoka Date: Sat, 2 Aug 2025 22:34:43 +0300 Subject: [PATCH 11/18] Docs(MD): Added interview questions and answers --- README.md | 43 +++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 41 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index ccb33a8..50b0731 100644 --- a/README.md +++ b/README.md @@ -2867,11 +2867,50 @@ git revert
-91. ??? +91. Як налаштувати та інтегрувати Git у сучасне IDE для зручної роботи? #### GIT -- Coming Soon... 😎 +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 скорочує контекстні переключення і робить робочий +процес швидшим, особливо для фронтенд-команд.
From 9ebb9ee3571c6b2db8431fc9a3d5ba7196d2d72f Mon Sep 17 00:00:00 2001 From: ViktorSvertoka Date: Sat, 2 Aug 2025 22:38:44 +0300 Subject: [PATCH 12/18] Docs(MD): Added interview questions and answers --- README.md | 47 +++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 45 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 50b0731..b72deb7 100644 --- a/README.md +++ b/README.md @@ -2915,11 +2915,54 @@ git revert
-92. ??? +92. Які плюси та мінуси використання GUI для Git у порівнянні з командним рядком? #### GIT -- Coming Soon... 😎 +**Переваги 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 для щоденної роботи.
From 3c93fca7d40035b964ed503e348fd13bd0104622 Mon Sep 17 00:00:00 2001 From: ViktorSvertoka Date: Sat, 2 Aug 2025 22:41:14 +0300 Subject: [PATCH 13/18] Docs(MD): Added interview questions and answers --- README.md | 39 +++++++++++++++++++++++++++++++++++++-- 1 file changed, 37 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index b72deb7..e825620 100644 --- a/README.md +++ b/README.md @@ -2967,11 +2967,46 @@ git revert
-93. ??? +93. Які популярні плагіни та розширення використовують для інтеграції Git у IDE та редакторах коду? #### GIT -- Coming Soon... 😎 +**Для 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.
From 40bafe5f46acf21df906ea86ce924df7452449bb Mon Sep 17 00:00:00 2001 From: ViktorSvertoka Date: Sat, 2 Aug 2025 22:45:08 +0300 Subject: [PATCH 14/18] Docs(MD): Added interview questions and answers --- README.md | 47 +++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 45 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index e825620..e5fc8cb 100644 --- a/README.md +++ b/README.md @@ -3011,11 +3011,54 @@ GitHub PR у VS Code для швидкої та наочної роботи з G
-94. ??? +94. Як вирішувати Git merge конфлікти за допомогою візуальних інструментів? #### GIT -- Coming Soon... 😎 +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 +git commit # закомітити результат злиття +``` + +#### Порада: + +- Візуальні інструменти особливо зручні для фронтенду, де конфлікти часто + виникають у JSX, CSS, JSON. + +- Для складних сценаріїв (великий обсяг коду) IDE + GUI клієнт дають максимум + наочності.
From 27f268f642af7780d7bd6fdd19b67a9079ed251e Mon Sep 17 00:00:00 2001 From: ViktorSvertoka Date: Sat, 2 Aug 2025 22:46:52 +0300 Subject: [PATCH 15/18] Docs(MD): Added interview questions and answers --- README.md | 26 ++++++++++++++++++++++++-- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index e5fc8cb..40efcb1 100644 --- a/README.md +++ b/README.md @@ -3063,11 +3063,33 @@ git commit # закомітити результат злиття
-95. ??? +95. Що таке Git bridge і яку роль він відіграє у взаємодії з іншими системами контролю версій? #### GIT -- Coming Soon... 😎 +- 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.
From c765205950fb2d8e2372c66d3c1eb879ff2d3db1 Mon Sep 17 00:00:00 2001 From: ViktorSvertoka Date: Sat, 2 Aug 2025 22:53:42 +0300 Subject: [PATCH 16/18] Docs(MD): Added interview questions and answers --- README.md | 45 +++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 43 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 40efcb1..bda2bd8 100644 --- a/README.md +++ b/README.md @@ -3094,11 +3094,52 @@ git commit # закомітити результат злиття
-96. ??? +96. Як керувати великими бінарними файлами в Git, якщо не використовувати Git LFS? #### GIT -- Coming Soon... 😎 +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 +git sparse-checkout init --cone +git sparse-checkout set src/ +``` + +Висновок: без Git LFS великі файли краще зберігати зовні, а в Git тримати лише +код і lightweight метадані.
From d5ebaf3a44451f6dc255e01c844e6d44a57b85f5 Mon Sep 17 00:00:00 2001 From: ViktorSvertoka Date: Sat, 2 Aug 2025 23:07:27 +0300 Subject: [PATCH 17/18] Docs(MD): Added interview questions and answers --- README.md | 122 +++++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 116 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index bda2bd8..4b501c5 100644 --- a/README.md +++ b/README.md @@ -3144,29 +3144,139 @@ git sparse-checkout set src/
-97. ??? +97. Для чого використовується git rebase -i (інтерактивний rebase)? #### GIT -- Coming Soon... 😎 +- `git rebase -i` дозволяє інтерактивно змінювати історію комітів у локальній + гілці. + +- Основні сценарії використання: + +1. Squash комітів – об’єднати кілька маленьких комітів в один. + +2. Редагування повідомлень комітів – змінити commit message. + +3. Видалення непотрібних комітів – drop комітів із історії. + +4. Перестановка комітів – змінити порядок комітів для чистішої історії. + +#### Приклад: + +```bash +git rebase -i HEAD~3 +``` + +- Відкриває останні 3 коміти в текстовому редакторі для редагування. + +- Кожен коміт можна позначити як pick, squash, edit, drop. + +Порада: використовувати тільки для локальної гілки, яка ще не пушилась у +віддалений репозиторій, щоб не порушити історію інших розробників.
-98. ??? +98. Як організувати безперервне резервне копіювання репозиторіїв Git? #### GIT -- Coming Soon... 😎 +1. Віддалені репозиторії (Remote Backup) + +- Основний метод — регулярний пуш у віддалений репозиторій (GitHub, GitLab, + Bitbucket, приватний сервер). + +- Приклад автоматичного резервного копіювання локального репо: + +```bash +git remote add backup +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 +``` + +4. Хмарне сховище + +- Регулярний бекап .git директорії у S3, Google Drive, Azure Blob. + +#### Порада: + +- Комбінувати віддалений mirror + архіви для критичних проєктів. + +- Перевіряти бекапи, щоб уникнути "битих" репозиторіїв.
-99. ??? +99. Як чутливість до регістру впливає на Git і як її контролювати на різних ОС? #### GIT -- Coming Soon... 😎 +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-платформи.
From 53cf37a29d5a6fed4eafc65be3fbdafa67b88e53 Mon Sep 17 00:00:00 2001 From: ViktorSvertoka Date: Sat, 2 Aug 2025 23:12:19 +0300 Subject: [PATCH 18/18] Docs(MD): Added interview questions and answers --- README.md | 48 ++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 46 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 4b501c5..a6c82c5 100644 --- a/README.md +++ b/README.md @@ -3281,11 +3281,55 @@ case"
-100. ??? +100. Як організувати підтримку кількох версій продукту за допомогою Git-гілок? #### GIT -- Coming Soon... 😎 +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 +``` + +5. **Тегування версій** + +- Кожен стабільний реліз позначати тегом для швидкого rollback або деплою: + +```bash +git tag -a v1.0.0 -m "Release 1.0.0" +git push origin v1.0.0 +``` + +#### Порада: + +- Використовувати стратегію Gitflow або спрощений Release Branch Workflow. + +- Кожна версія продукту підтримується окремою гілкою, що дозволяє паралельно + виправляти баги у старих релізах, не блокуючи нову розробку.