GIT

Найпопулярніші запитання та відповіді на співбесіді з GIT

Основи Git та управління версіями

1. Що таке Git і яка його роль у розробці програмного забезпечення?

GIT

• Git — розподілена система контролю версій (VCS) для відстеження змін у коді.

Використання:

• Зберігання історії змін у проєкті.

• Паралельна розробка в гілках (branches).

• Об’єднання змін через merge або rebase.

• Відновлення попередніх версій файлів.

• Спільна робота команд над кодом через сервіси (GitHub, GitLab, Bitbucket).

Git дозволяє безпечно керувати кодом, відстежувати зміни та ефективно співпрацювати.

2. Чим Git відрізняється від інших систем контролю версій, наприклад, SVN або Mercurial?

GIT

• Розподіленість: у Git кожен клон репозиторію містить повну історію, на відміну від централізованих VCS (SVN).

• Швидкість: локальні операції (commit, diff, log) виконуються дуже швидко.

• Гнучке керування гілками: lightweight branches і швидке злиття (merge/rebase).

• Зберігання змін: Git зберігає снімки (snapshots) файлів, а не тільки дельти, як у SVN.

• Широка інтеграція: популярність Git забезпечує підтримку в CI/CD, GitHub, GitLab, IDE.

• Безпека: SHA-1 хешування гарантує цілісність історії.

Git ідеально підходить для сучасних командних workflow та open-source проєктів завдяки швидкості, гнучкості та надійності.

3. У чому відмінність між Git і GitHub?

GIT

• Git — система контролю версій (VCS) для відстеження змін у коді локально або на будь-якому сервері.

• GitHub — онлайн-сервіс для зберігання Git-репозиторіїв з веб-інтерфейсом, спільною роботою та додатковими функціями: pull requests, issues, CI/CD інтеграції.

• Коротко: Git — інструмент для роботи з версіями коду, GitHub — платформа для хостингу та командної роботи з Git.

Можна використовувати Git без GitHub (локально) або GitHub безпосередньо для колаборації через веб.

4. Що таке репозиторій у Git і яка його роль?

GIT

• Репозиторій (repository, repo) — це місце зберігання всього коду проєкту та історії змін.

• Містить:

  • Файли проєкту (код, документацію, конфігурації).

  • Історію комітів (зміни з авторами та повідомленнями).

  • Гілки (branches) для паралельної розробки.

• Може бути локальний (на вашому комп’ютері) або віддалений (GitHub, GitLab, Bitbucket).

Репозиторій дозволяє відстежувати зміни, працювати командою та повертатися до попередніх версій коду.

5. Що таке коміт (commit) у Git і для чого він використовується?

GIT

• Коміт (commit) — це збереження знімка змін у репозиторії разом із повідомленням.

• Містить:

  • Історію змін файлів (added, modified, deleted).

  • Авторство та дату зміни.

  • Унікальний SHA-1 хеш для ідентифікації.

• Використовується для:

  • Відстеження прогресу проєкту.

  • Повернення до попередніх станів (git checkout, git revert).

  • Координації роботи в команді через pull/merge.

Приклад коміту:

git add index.html

git commit -m "feat(html): Додаю базову структуру сторінки"

Коміти формують історію проєкту, яку можна аналізувати, відновлювати і об’єднувати.

6. Яка різниця між робочим каталогом (working directory), стейджингом (staging area/index) і репозиторієм (repository) у Git?

GIT

1. Робочий каталог (Working Directory)

• Це ваші файли на диску, які ви редагуєте.

• Містить останню версію коду з Git + незбережені зміни.

2. Проміжна область (Staging Area / Index)

• Тимчасове місце для підготовки змін до коміту.

• Ви обираєте, які файли/зміни будуть включені у наступний коміт.

• Команди: git add <file> додає зміни до стейджу.

3. Локальний репозиторій (Repository)

• Збережена історія комітів у .git папці.

• Містить всі коміти, гілки, теги, SHA-1 хеші.

• Команди: git commit переносить зміни зі стейджу у репозиторій.

Схематично:

Working Directory -> git add -> Staging Area -> git commit -> Repository

Ця модель дозволяє гнучко контролювати, які зміни зберігати, і робити чисту історію комітів.

7. Що таке розгалуження (branching) у Git і чому воно важливе?

GIT

• Розгалуження (branch) — це окрема лінія розробки в репозиторії, яка дозволяє працювати над новими функціями, виправленнями або експериментами, не зачіпаючи основну гілку (main/master).

• Важливість:

  • Паралельна робота кількох розробників.

  • Безпечне тестування нових фіч.

  • Легка інтеграція через merge або rebase.

  • Чистіша історія комітів і контроль над змінами.

Приклад створення і перемикання гілки:

git branch feature-login

git checkout feature-login

Branching — основа сучасних workflow (Git Flow, GitHub Flow) для командної розробки.

8. Що таке HEAD у Git і яка його роль?

GIT

• HEAD — це поточний вказівник на коміт, з яким ви зараз працюєте.

• Зазвичай HEAD показує на гілку, а гілка — на останній коміт.

• Використовується для:

  • Відстеження, де ви зараз перебуваєте в історії комітів.

  • Перемикання гілок (git checkout <branch>) або комітів (git checkout <commit>).

• Можливі стани HEAD:

  • Normal — вказує на гілку.

  • Detached HEAD — тимчасово вказує на конкретний коміт, не на гілку.

Приклад:

git checkout feature-login

# HEAD тепер вказує на гілку feature-login

HEAD — ключовий концепт для навігації по історії Git і управління комітами.

9. Що таке операція clone у Git і для чого вона використовується?

GIT

• git clone — створює повну копію віддаленого репозиторію на вашому локальному комп’ютері.

• Копія містить:

  • Усі файли проєкту.

  • Історію комітів.

  • Всі гілки та теги.

• Використовується для:

  • Початку роботи над існуючим проєктом.

  • Спільної роботи команди через GitHub, GitLab або інші сервери.

Приклад:

git clone https://github.com/user/repo.git

Результат: локальний репозиторій, готовий для комітів, гілок і синхронізації з віддаленим сервером.

10. Як Git зберігає дані про проєкт і його історію змін?

GIT

• Git зберігає снімки (snapshots), а не просто дельти файлів.

• Кожен коміт — це SHA-1 хеш з:

  • Посиланням на попередній коміт.

  • Змінами файлів (знімком дерева).

  • Автором і повідомленням коміту.

• Структура зберігання:

  • Blob — вміст файлів.

  • Tree — каталог файлів та папок.

  • Commit — вказує на tree і попередній коміт.

• Папка .git містить всі об’єкти і метадані, що дозволяє повністю відтворити історію проєкту.

👉 Така модель робить Git швидким, надійним і дозволяє ефективно працювати з гілками та злиттями.

Основні команди для роботи з Git

11. Як ініціалізувати новий репозиторій Git?

GIT

• Використати команду:

git init

• Вона створює приховану папку .git у поточному каталозі, де зберігатиметься історія комітів, гілки та конфігурація.

• Далі треба додати файли й зробити перший коміт:

git add .

git commit -m "Initial commit"

Після git init каталог стає повноцінним Git-репозиторієм.

12. Для чого використовується команда git status?

GIT

• Показує поточний стан робочого каталогу та індексу (staging area).

• Інформує про:

  • Які файли змінені, але ще не додані.

  • Які файли вже в індексі та підуть у наступний коміт.

  • Які файли не відслідковуються.

  • Поточну гілку та її відставання/випередження відносно remote.

Приклад:

git status

Дає зрозуміти, що саме буде закомічено, а що ще потребує git add.

13. Яке призначення команди git add?

GIT

• git add додає зміни з робочого каталогу у staging area (індекс).

• Це підготовчий етап перед комітом.

• Можна додавати окремі файли або всі зміни.

Приклади:

git add file.txt     # додає конкретний файл
git add .            # додає всі зміни в поточному каталозі
git add -p           # додає зміни частинами (interactive)

Сам git add ще не зберігає зміни в історії — тільки позначає їх для наступного git commit.

14. Яким чином створюється новий коміт у Git?

GIT

1. Спочатку додати зміни у staging area:

git add .

2. Потім створити коміт:

git commit -m "Опис змін"

• Ключ -m додає повідомлення коміту.

• Якщо його не вказати — відкриється редактор для введення повідомлення.

• Коміт зберігає знімок (snapshot) поточного стану індексу в історії репозиторію.

Рекомендується писати короткі й зрозумілі повідомлення, щоб легко відстежувати зміни.

15. Які дані зберігає об’єкт коміту в Git?

GIT

• Об’єкт коміту містить:

  • Хеш (SHA-1/SHA-256) — унікальний ідентифікатор.

  • Посилання на tree-об’єкт (структура файлів і папок на момент коміту).

  • Посилання на parent-коміти (зв’язок в історії, може бути кілька у merge).

  • Автор (ім’я, email, час створення).

  • Комітер (той, хто зафіксував, може відрізнятися від автора).

  • Commit message (опис змін).

Таким чином Git зберігає не файли, а знімки стану + метадані, що дозволяє легко відновлювати і порівнювати історію.

16. Яка різниця між командами git push і git fetch?

GIT

• git push — відправляє локальні коміти у віддалений репозиторій (оновлює remote-branch).

• git fetch — отримує нові дані з віддаленого репозиторію, але не зливає їх у локальну гілку (оновлює тільки refs/remotes).

Тобто:

• push = викласти свої зміни.

• fetch = завантажити чужі зміни для перегляду/злиття.

17. Яке призначення команди git pull?

GIT

• git pull = git fetch + git merge (або rebase, якщо вказано опцію).

• Вона завантажує останні зміни з віддаленого репозиторію і одразу інтегрує їх у поточну гілку.

• Використовується для синхронізації локальної гілки з remote.

Приклад:

git pull origin main

• Отримає оновлення з origin/main і зіллє їх у вашу локальну main.

Якщо потрібен лише перегляд змін без злиття — краще використовувати git fetch.

18. Яке призначення та варіанти використання команди git branch?

GIT

• git branch керує гілками в репозиторії. Основні сценарії:

1. Перегляд усіх гілок:

git branch

2. Створення нової гілки:

git branch feature/login

3. Видалення гілки (локально):

git branch -d feature/login # безпечне (якщо змерджено) git branch -D
feature/login # примусове

4. Перейменування гілки:

git branch -m old-name new-name

5. Перегляд віддалених гілок:

git branch -r

Важливо: git branch не перемикає гілки, а тільки створює/керує. Для перемикання використовується git checkout або git switch.

19. Як використовувати git checkout для перемикання між гілками?

GIT

• Команда git checkout <branch> змінює поточну гілку на вказану, оновлюючи робочий каталог до стану цієї гілки.

Приклад:

git checkout feature/login

• Тепер HEAD вказує на feature/login, і всі файли відображають її стан.

Створення нової гілки та одночасне перемикання:

git checkout -b feature/signup

• Перевага: швидко працювати з різними гілками без втрати змін (якщо вони закомічені або у стейджі).

В сучасних workflow рекомендують git switch для перемикання гілок (git switch feature/login) — більш інтуїтивно.

20. Для чого використовується команда git merge?

GIT

• git merge <branch> об’єднує зміни з іншої гілки у поточну.

• Застосовується для інтеграції роботи над фічами або виправленнями в основну гілку (main/develop).

Типи злиття:

• Fast-forward — просто переміщує вказівник гілки, якщо історія лінійна.

• Three-way merge — створює новий коміт злиття, якщо гілки розходяться.

Приклад:

git checkout main git merge feature/login

• Після цього всі зміни з feature/login будуть в main.

Merge дозволяє безпечно інтегрувати паралельні гілки без втрати історії.

Управління гілками та інтеграція змін у Git

21. Який Git workflow ви зазвичай використовуєте в роботі?

GIT

• Найчастіше використовую Git Flow / Feature Branch Workflow:

  • main — завжди стабільна продакшн-версія.

  • develop — інтеграційна гілка для нових фіч.

  • для задач створюю окрему feature.

  • після завершення — pull request → code review → merge у develop.

  • перед релізом створюється release, після тестів — merge у main + тег.

  • багфікси йдуть у hotfix від main.

Цей процес дисциплінує, дає прозорість і контроль над релізами.

22. Опишіть кроки створення нової гілки та її злиття в main.

GIT

1. Переконуюсь, що локальний main оновлений:

git checkout main
git pull origin main

2. Створюю нову гілку від main:

git checkout -b feature/my-task

3. Працюю, комічу зміни:

git add .
git commit -m "Implement feature X"

4. Пушу гілку на remote:

git push origin feature/my-task

5. Відкриваю Pull Request → проходить code review → CI.

6. Мерджу в main (звичайно через squash або rebase, щоб історія була чистою).

7. Видаляю feature-гілку локально і на remote.

23. Що таке merge conflict у Git і як його вирішують?

GIT

• Merge conflict виникає, коли дві гілки змінюють один і той самий рядок коду або файл у несумісний спосіб, і Git не може автоматично об’єднати зміни.

Рішення:

1. Виконати merge/rebase → Git покаже конфліктні файли.

2. Відкрити файл, знайти маркери <<<<<<<, =======, >>>>>>>.

3. Вибрати або об’єднати потрібні зміни вручну.

4. Позначити файл як вирішений:

git add <file>

5. Завершити merge/rebase комітом:

git commit

24. Що таке fast-forward merge у Git?

GIT

• Fast-forward merge — це злиття, коли гілка-ціль (наприклад main) не має нових комітів після відгалуження feature-гілки. Тоді Git просто пересуває вказівник main на останній коміт feature-гілки без створення додаткового merge-коміту.

Приклад:

git checkout main
git merge feature/my-task --ff

Це "чисте" злиття без зайвих комітів.

25. Що таке three-way merge у Git?

GIT

• Three-way merge — це злиття, коли Git використовує три точки для об’єднання:

1. common ancestor (базовий коміт, від якого розійшлися гілки),

2. HEAD (останній коміт у цільовій гілці, наприклад main),

3. branch tip (останній коміт у зливаній гілці, наприклад feature).

Git порівнює зміни відносно спільного предка й створює новий merge-коміт, що має двох батьків.

Цей підхід застосовується, коли fast-forward неможливий (тобто в обох гілках є нові коміти).

26. Які кроки виконати, щоб перебазувати (rebase) гілку в Git?

GIT

1. Перейти в свою гілку:

git checkout feature/my-task

2. Виконати rebase на актуальну main:

git fetch origin git rebase origin/main

3. Якщо є конфлікти — вирішити їх, додати файли:

git add <file> git rebase --continue

4. Коли все готово — оновити remote (з форсом, бо історія переписана):

git push origin feature/my-task --force

Rebase робить історію лінійною, на відміну від merge.

27. Які плюси й мінуси rebase у порівнянні з merge?

GIT

✅ Переваги rebase

• Лінійна, чиста історія без merge-комітів.

• Зручніше читати git log, легше дебажити.

• Кожен коміт виглядає так, ніби зроблений поверх останнього main.

❌ Недоліки rebase

• Переписує історію (особливо небезпечно для спільних гілок).

• Потрібен --force push, що може зламати історію іншим.

• Вимагає більшої дисципліни в команді.

✅ Переваги merge

• Зберігає повну історію розробки, без переписування.

• Безпечний для командної роботи.

• Простий у використанні.

❌ Недоліки merge

• Брудніший git log з великою кількістю merge-комітів.

• Історію важче аналізувати.

Загалом: merge — безпечніше для команд, rebase — краще для чистої історії.

28. Для чого використовуються теги в Git?

GIT

• Теги в Git — це фіксовані маркери на певні коміти, зазвичай для позначення релізів (v1.0, v2.1).

  • Lightweight tag — просто вказівка на коміт, без додаткової інформації.

  • Annotated tag — зберігає автора, дату, повідомлення і може бути підписаний GPG.

Теги зручні для:

• Відстеження версій у продакшн.

• Швидкого переходу на конкретний реліз:

git checkout v1.0

• CI/CD для автоматичного деплою.

29. Як скасувати коміт, який вже запушено на remote?

GIT

1. Якщо потрібно повністю видалити коміт (історія переписується, небезпечно для інших):

git reset --hard <коміт_до_потрібного>
git push origin <гілка> --force

2. Якщо потрібно зберегти історію, створивши "відкат" без перепису:

git revert <hash_коміту>
git push origin <гілка>

• reset --hard + force push змінює історію (небезпечно для спільних гілок).

• revert створює новий коміт, що відміняє зміни — безпечніше для команд.

30. Яке призначення головної гілки (main/master) у Git?

GIT

Головна гілка (main або раніше master) — це стабільна, завжди робоча версія проєкту, на яку орієнтуються всі інші гілки.

• Від неї створюють feature-, release-, hotfix-гілки.

• Вона слугує базою для релізів.

• Зазвичай на ній запускається CI/CD і деплой в продакшн.

Робочі процеси та шаблони використання Git

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 (локальна історія, робота офлайн).

✅ Простий процес, мінімум гілок. ❌ Важко масштабувати в команді: часто виникають конфлікти, немає ізоляції фіч.

Організація та адміністрування Git-репозиторіїв

36. Що таке remote repository у Git і для чого він потрібен?

GIT

• Віддалений репозиторій (remote) — це версія Git-репозиторію, що зберігається на сервері (GitHub, GitLab, Bitbucket).

Призначення:

• Спільна робота команди (push/pull змін).

• Централізоване зберігання коду та історії.

• Інтеграція з CI/CD.

Приклади команд:

git remote -v              # переглянути підключені remote
git remote add origin URL  # додати віддалений репозиторій
git push origin main       # відправити зміни
git pull origin main       # отримати зміни

37. Як змінити URL remote-репозиторію в Git?

GIT

• Для оновлення URL використовують команду:

git remote set-url origin <новий_URL>

• Перевірити зміни можна так:

git remote -v

• Або замінити remote повністю:

git remote remove origin
git remote add origin <новий_URL>

Використовується, наприклад, при переході з HTTPS на SSH чи зміні репозиторію на GitHub/GitLab.

38. Які команди використовуються, щоб синхронізувати локальний репозиторій з remote у Git?

GIT

1. Отримати останні зміни з remote:

git fetch origin

2. Об’єднати з локальною гілкою:

git pull origin main

• (еквівалент fetch + merge).

3. Відправити свої зміни на remote:

git push origin main

Коротко: pull → підтягнути зміни, push → відправити свої.

39. Як видалити невикористані (застарілі) гілки локально й на remote у Git?

GIT

• Локально:

git branch -d branch_name      # видалити вже злиту гілку
git branch -D branch_name      # примусово видалити

• Віддалено:

git push origin --delete branch_name

• Очистити локальний список remote-гілок (які вже видалені на сервері):

git fetch --prune

Практика: після merge у main видаляємо feature-гілки, щоб не захаращувати репозиторій.

40. Які кроки потрібно виконати для вирішення merge conflict у Git?

GIT

1. Спробувати злиття або rebase:

git merge feature/my-task

2. Git повідомляє про конфлікти. Перевірити файли:

git status

3. Відкрити конфліктні файли, знайти маркери:

<<<<<<< HEAD
...
=======
...
> > > > > > > feature/my-task

4. Вирішити конфлікт вручну (залишити потрібні зміни).

5. Позначити файли як вирішені:

git add <file>

6. Продовжити merge/rebase:

git commit # якщо merge git rebase --continue # якщо rebase

7. Перевірити, що все працює, і пушити зміни:

git push origin main

Збереження та очищення змін у Git

41. Для чого призначена команда git stash?

GIT

• git stash дозволяє тимчасово сховати незавершені зміни (modified/ staged файли) у локальному репозиторії, щоб переключитися на іншу гілку або виконати інші операції, не комітячи їх.

Приклади:

git stash           # сховати зміни
git stash pop       # повернути сховані зміни
git stash list      # переглянути список схованих змін

Використовується, коли потрібно швидко переключитися на main для виправлення багу або pull останніх змін.

42. Як переглянути зміни у файлах, які ще не закомічені, або історію комітів у Git?

GIT

1. Зміни в робочому каталозі (не staged):

git diff

2. Зміни, які вже додані до staging area:

git diff --staged

3. Історія комітів:

git log

4. Коротка історія:

git log --oneline --graph --decorate --all

5. Перегляд змін конкретного файлу:

git diff <file>
git log -p <file>

43. Чи можна застосувати зміни з Git stash, не видаляючи їх зі списку?

GIT

Так, для цього використовують команду:

git stash apply

• Застосовує обрану сховану зміну до робочої гілки.

• Не видаляє її зі списку stash.

Якщо потрібно одночасно застосувати і видалити зі списку, використовують:

git stash pop

44. Що робить команда git clean?

GIT

• git clean видаляє незатрековані файли та каталоги з робочого каталогу, тобто ті, що не відслідковуються Git.

Приклади:

git clean -n       # показати, що буде видалено (dry-run)
git clean -f       # видалити незатрековані файли
git clean -fd      # видалити файли та каталоги
git clean -fx      # видалити файли, включаючи ті, що в .gitignore

Використовується, щоб очистити робочий каталог перед збіркою або тестуванням, коли потрібен чистий стан.

45. Як видалити файл з локального робочого каталогу, але залишити його в репозиторії Git?

GIT

Для цього використовують команду:

git rm --cached <file>

• Файл видаляється з індексу (staging area) і робочого каталогу локально.

• Після коміту і пушу він залишиться в репозиторії, але більше не відслідковується Git.

Якщо потрібно залишити файл у робочому каталозі, але перестати відслідковувати:

git rm --cached <file>
git commit -m "Stop tracking file"

Перегляд та аналіз історії комітів

46. Як переглянути історію комітів у Git?

GIT

1. Базовий перегляд:

git log

2. Коротка форма:

git log --oneline

3. Графічне відображення гілок:

git log --graph --oneline --decorate --all

4. Перегляд змін у комітах:

git log -p git show <commit_hash>

5. Фільтрація по файлу:

git log -- <file>

Використовується для аналізу історії, пошуку змін або перевірки, хто і коли зробив коміт.

47. Як знайти всі коміти певного автора у Git?

GIT

• Використовують команду git log з опцією --author:

git log --author="Ім'я або email автора"

• Додатково можна скоротити вихід у один рядок:

git log --author="Ім'я" --oneline

Так можна переглянути всі коміти конкретного розробника у проєкті.

48. Як переглянути зміни, внесені конкретним комітом у Git?

GIT

1. Перегляд повних змін коміту:

git show <commit_hash>

2. Короткий варіант:

git show --stat <commit_hash>

3. Якщо потрібно переглянути зміни конкретного файлу в коміті:

git show <commit_hash> -- <file>

Використовується для аналізу, перевірки змін перед злиттям або дебагу.

49. Як переглянути список файлів, змінених у конкретному коміті Git?

GIT

1. Використовують git show з параметром --name-only:

git show --name-only <commit_hash>

• Показує лише імена файлів, без diff.

2. Або --name-status, щоб бачити статус змін (додано, змінено, видалено):

git show --name-status <commit_hash>

3. Для перегляду diff разом із файлами:

git show <commit_hash>

Це корисно для швидкого огляду, що змінився в конкретному коміті без аналізу повного diff.

50. Що робить команда git blame у Git?

GIT

• git blame <file> показує хто і коли вніс кожен рядок у файлі.

  • Для кожного рядка виводиться коміт, автор і дата.

  • Допомагає швидко знайти відповідального за зміни або зрозуміти історію рядка коду.

Приклади:

git blame app.js
git blame -L 10,20 app.js   # лише рядки з 10 по 20

Управління версіями та релізами

51. Що таке теги в Git і чим вони відрізняються від гілок?

GIT

• Тег — це фіксована позначка на конкретному коміті, зазвичай для релізів (v1.0, v2.1).

• Гілка — це рухомий вказівник на останній коміт у лінії розробки, куди додаються нові коміти.

Основні відмінності:

Характеристика	Тег	Гілка
Рухливість	Нерухомий	Рухливий
Використання	Позначення релізів	Розробка нових функцій
Коміти	Не додаються нові	Додаються нові коміти

Приклад створення тега:

git tag v1.0 git push origin v1.0

52. Як у Git створювати, видаляти та пушити теги?

GIT

Створення тегів:

• Lightweight тег:

git tag v1.0

• Annotated тег (з повідомленням):

git tag -a v1.0 -m "Release version 1.0"

Видалення тегів:

• Локально:

git tag -d v1.0

• Віддалено:

git push origin --delete tag v1.0

Надсилання тегів на remote:

• Один тег:

git push origin v1.0

• Всі теги:

git push origin --tags

53. Що таке семантичне версіонування і як його використовують у Git-тегах?

GIT

• Семантичне версіонування (SemVer) — це система нумерації версій у форматі MAJOR.MINOR.PATCH, яка відображає характер змін у релізі:

  • MAJOR — несумісні зміни API.

  • MINOR — додані нові функції, сумісні з попередньою версією.

  • PATCH — виправлення багів без зміни функціоналу.

• У Git-тегах використовують SemVer, щоб:

  • Позначати релізи (v1.2.3).

  • Легко відстежувати стабільність та сумісність версій.

  • Інтегруватися з CI/CD для автоматичного деплою конкретних версій.

54. Як у Git перейти на конкретний тег?

GIT

• Теги самі по собі не є гілками, тому перехід на них робить репозиторій у detached HEAD стані:

git checkout v1.0

• Або з новішим синтаксисом:

git switch --detach v1.0

У цьому режимі можна переглядати код, збирати чи тестувати, але нові коміти не будуть прив’язані до жодної гілки.

• Щоб працювати далі з тегу як із гілки:

git checkout -b release-1.0 v1.0

55. Як у Git створити реліз на основі тегу?

GIT

1. Створити тег на потрібному коміті:

git tag -a v1.0.0 -m "Release 1.0.0"

2. Надіслати тег у віддалений репозиторій:

git push origin v1.0.0

(або всі теги: git push origin --tags)

3. У системі керування кодом (GitHub/GitLab/Bitbucket) на основі цього тега можна створити реліз:

   • GitHub: вкладка Releases → Draft a new release → вибрати тег.

   • Додати опис змін (changelog).

   • Опублікувати реліз.

Реліз із тегу зручний для CI/CD — можна налаштувати автоматичне збирання та деплой за певними тегами.

Просунуті методи роботи та управління версіями

56. Що таке Git submodule і в яких випадках його доцільно використовувати?

GIT

Git submodule — це механізм, що дозволяє вбудовувати один репозиторій у інший як залежність. Він зберігає посилання на конкретний коміт іншого репозиторію.

Використовують, коли:

• Є спільна бібліотека/модуль, який використовується в кількох проєктах.

• Потрібно зафіксувати залежність на певному коміті, а не останню версію.

• Хочеться уникнути копіювання коду між репозиторіями.

Приклад додавання підмодуля:

git submodule add https://github.com/example/lib.git libs/lib
git submodule update --init --recursive

❌ Мінуси: складніший workflow (оновлення вручну), можуть виникати проблеми при клонуванні без --recursive.

57. Що таке Git hooks і для чого вони потрібні?

GIT

Git hooks — це скрипти, які автоматично виконуються при певних подіях у репозиторії (наприклад, перед комітом, після злиття, перед пушем). Вони зберігаються у .git/hooks.

Використання:

• Перевірка стилю коду / запуск linter перед git commit (pre-commit).

• Заборона пушу у main напряму (pre-push).

• Автоматичне оновлення залежностей або документації після злиття (post-merge).

• Генерація changelog з повідомлень комітів.

Приклад: pre-commit для перевірки ESLint:

#!/bin/sh
npm run lint
if [ $? -ne 0 ]; then
  echo "Lint errors found. Commit aborted."
  exit 1
fi

58. Як у Git об’єднати кілька комітів у один (squash)?

GIT

• Squash роблять через інтерактивне перебазування:

git rebase -i HEAD~N

• де N — кількість останніх комітів, які треба переглянути.

Далі в редакторі:

• залишаєш перший коміт як pick,

• для наступних змінюєш pick на squash (або s).

Після збереження — Git об’єднає коміти, запропонує відредагувати повідомлення.

Використання:

• очистка історії перед злиттям у main,

• зручний changelog,

• уникнення зайвих "дрібних" комітів.

59. Що таке git bisect і як із ним працювати?

GIT

• git bisect — це інструмент Git для бінарного пошуку коміту, який ввів баг. Він автоматично звужує діапазон між “good” і “bad” комітами.

Використання:

1. Запустити:

git bisect start
git bisect bad                # вказати коміт з багом
git bisect good <commit_hash> # вказати коміт, де все працювало

2. Git переключається на середній коміт. Ви тестуєте і кажете Git:

git bisect good   # якщо багу немає
git bisect bad    # якщо баг є

3. Повторює, доки не знайде проблемний коміт.

4. Завершення:

git bisect reset

Використовується для швидкого знаходження помилок у великих історіях проєкту.

60. Як вручну вирішити конфлікт при злитті в Git?

GIT

1. Виконати злиття:

git merge feature-branch

• Git зупиниться на конфліктах.

2. Відкрити файли з конфліктами — вони містять маркери:

<<<<<<< HEAD
код з поточної гілки
=======
код з feature-branch
>>>>>>> feature-branch

3. Вручну вибрати або об’єднати потрібні зміни, видалити маркери.

4. Позначити файл як вирішений:

git add <file>

5. Завершити злиття:

git commit

(якщо Git не зробив commit автоматично).

Порада: можна використовувати інструменти для merge (наприклад, VS Code, IntelliJ, Meld).

Конфігурація та персоналізація робочого середовища

61. Як налаштувати ім’я користувача та email у Git?

GIT

• Для глобальних налаштувань (усі репозиторії):

git config --global user.name "Ваше Ім’я"
git config --global user.email "ваш@email.com"

• Для конкретного репозиторію (тільки в поточному):

git config user.name "Ваше Ім’я"
git config user.email "ваш@email.com"

• Перевірка:

git config --list

Email важливий для зв’язку комітів з GitHub/GitLab профілем.

62. Які рівні конфігурації Git існують і яка їхня область дії?

GIT

• Git має три рівні конфігурації:

1. System (/etc/gitconfig) – застосовується для всіх користувачів і всіх репозиторіїв на машині.

git config --system ...

2. Global (~/.gitconfig або ~/.config/git/config) – застосовується для поточного користувача на всіх його репозиторіях.

git config --global ...

3. Local (.git/config у корені репозиторію) – застосовується лише для цього репозиторію. Має найвищий пріоритет.

git config ...

Пріоритет: local > global > system.

63. Як у Git створити alias (псевдонім) для команди?

GIT

Псевдоніми додають через git config. Наприклад:

• Глобально (для всіх репозиторіїв):

git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.cm "commit -m"

• У конкретному репозиторії:

git config alias.lg "log --oneline --graph --all --decorate"

Після цього можна виконувати, наприклад:

git st
git co main
git lg

Зберігаються псевдоніми у файлі ~/.gitconfig або .git/config.

64. Для чого використовується файл .gitignore у Git?

GIT

• .gitignore визначає, які файли й папки Git має ігнорувати — тобто не відстежувати і не додавати у коміти.

Використовується для:

• тимчасових файлів (логів, кешів, .DS_Store, thumbs.db);

• залежностей (node_modules/, vendor/);

• згенерованих артефактів (білди, coverage-звіти);

• локальних конфігів (наприклад, .env).

Важливо: .gitignore не видаляє файли, які вже відстежуються Git, лише забороняє додавати нові.

65. Як налаштувати глобальний .gitignore, щоб ігнорувати файли у всіх репозиторіях?

GIT

1. Створити глобальний файл, наприклад:

touch ~/.gitignore_global

2. Додати в нього правила (наприклад, IDE, системні файли):

.DS_Store
Thumbs.db
node_modules/
*.log

3. Прописати Git, щоб він його використовував:

git config --global core.excludesfile ~/.gitignore_global

4. Перевірити:

git config --list | grep excludesfile

Тепер усі нові репозиторії автоматично ігноруватимуть ці файли.

Безпека роботи з Git

66. Як налаштувати Git для підпису комітів GPG-ключем?

GIT

1. Створити або імпортувати GPG-ключ

gpg --full-generate-key gpg --list-secret-keys --keyid-format=long

• Скопіювати GPG_KEY_ID.

2. Сказати Git, який ключ використовувати

git config --global user.signingkey GPG_KEY_ID git config --global
commit.gpgsign true # підписувати всі коміти

3. Опціонально — підписувати лише вибрані коміти

git commit -S -m "Signed commit"

4. Для GitHub/GitLab

• Вивести публічний ключ:

gpg --armor --export GPG_KEY_ID

• Додати його в налаштування акаунта (GPG keys).

5. Перевірка

git log --show-signature

6. У VS Code потрібно додати в settings.json:

"git.enableCommitSigning": true

67. Які найпоширеніші практики безпеки при роботі з Git-репозиторіями?

GIT

1. SSH-ключі замість паролів – для автентифікації з віддаленими репозиторіями.

2. GPG-підпис комітів – гарантія авторства і цілісності коду.

3. .gitignore для секретів – не зберігати .env, ключі, паролі в репозиторії.

4. Сканування на секрети (наприклад, GitGuardian, TruffleHog) перед пушем.

5. Обмеження доступу – мінімальні права (read/write), захищені гілки (protected branches).

6. Pull Request review – код потрапляє в main тільки після рев’ю.

7. CI/CD з секретним сховищем (Vault, GitHub Actions Secrets) замість hardcode.

8. Регулярне оновлення залежностей – щоб уникнути вразливостей.

Головне правило: ніколи не зберігати у Git секретні дані у відкритому вигляді.

68. Які способи існують для зберігання конфіденційних даних у Git-репозиторії у зашифрованому вигляді?

GIT

1. git-crypt – прозоре шифрування вибраних файлів у репозиторії (розшифровка тільки для користувачів із ключами).

2. git-secret – базується на GPG, дозволяє шифрувати .env, ключі та інші секрети.

3. SOPS (Mozilla SOPS) – зручний інструмент для керування секретами (AES + інтеграція з AWS KMS, GCP KMS, HashiCorp Vault).

4. BlackBox (StackExchange) – управління зашифрованими файлами в репозиторіях.

5. Зберігати секрети поза Git – у менеджерах секретів (Vault, AWS Secrets Manager, Doppler), а в репозиторії залишати лише посилання/шаблони (.env.example).

📌 На практиці: для фронтенд/.NET проєкту зручніше або git-secret + GPG, або SOPS, якщо інфраструктура в AWS/GCP.

69. Які існують стратегії зберігання та керування обліковими даними (credentials) у Git?

GIT

1. Credential helpers Git

• cache — тимчасове збереження у пам’яті.

• store — збереження у відкритому вигляді у файлі (небезпечний варіант).

• manager (Windows) або osxkeychain (macOS) — інтеграція з системним менеджером паролів.

2. SSH-ключі

• Основний безпечний метод для GitHub/GitLab.

• Використання ssh-agent для зручності.

3. Персональні токени доступу (PAT)

• Альтернатива паролям (наприклад, для GitHub).

• Краще зберігати через credential manager.

4. GPG-підпис

• Для підтвердження авторства комітів, не для аутентифікації.

5. Secrets Manager (AWS, Vault, Doppler і т.д.)

• Для CI/CD або автоматизації замість хардкоду.

📌 Найкраща практика: SSH-ключі для доступу + Credential Manager для зручності + Secrets Manager для CI/CD.

70. Які способи є для скасування доступу користувачу до Git-репозиторію?

GIT

1. GitHub / GitLab / Bitbucket

• Власник або адміністратор видаляє користувача з collaborators або з групи/команди.

• Можна змінити права доступу (read → none).

2. SSH-ключі

• Видалити публічний ключ користувача з налаштувань репозиторію або сервера.

3. Персональні токени (PAT)

• Відкликати або видалити токен у налаштуваннях акаунта.

4. CI/CD секрети

• Якщо користувач мав доступ до секретів (наприклад, у GitHub Actions), треба їх відкликати/оновити.

Загальний принцип: відкликати доступ на рівні платформи (GitHub/GitLab) + знеактивувати ключі/токени.

Виявлення та усунення проблем у Git

71. Як у Git знайти та відновити файл, який був видалений?

GIT

1. Якщо файл ще не закомічений (видалений лише локально):

git checkout -- <file>

2. Якщо файл видалено і закомічено:

• Знайти коміт, де файл існував:

git log -- <file>

• Відновити файл з того коміту:

git checkout <commit_hash> -- <file>

3. Відновлення файлу з останнього коміту у поточній гілці:

git restore <file>

Порада: перед checkout або restore переконайтеся, що немає незбережених змін, щоб їх не перезаписати.

72. Що робити, якщо випадково закомітити секретні дані у Git-репозиторій?

GIT

1. Негайно видалити файл із історії:

git rm --cached <file>     # видалити з індексу, залишивши локально
echo "<file>" >> .gitignore
git commit -m "Remove sensitive file"

2. Якщо дані вже запушені на remote:

• Використати git filter-repo (або старий git filter-branch) для повного видалення файлу з історії:

git filter-repo --path <file> --invert-paths

3. Переписати історію у віддаленому репозиторії:

git push origin --force

4. Оновити секрети:

• Змінити паролі, ключі API, токени, оскільки вони вже могли бути скомпрометовані.

5. Додати файл у .gitignore для запобігання повторного коміту.

Порада: у команді попереджати колег і перевірити форки/клони, якщо дані були пушені.

73. Що таке detached HEAD у Git і як з ним працювати?

GIT

1. Що це:

• detached HEAD — стан, коли Git не знаходиться на гілці, а вказує безпосередньо на конкретний коміт або тег.

• Коміти в такому стані не прив’язані до жодної гілки і можуть бути втрачені після переключення.

2. Перехід у detached HEAD:

git checkout <commit_hash>
git switch --detach <tag_name>

3. Робота у detached HEAD:

• Можна змінювати код, робити коміти.

• Щоб зберегти коміти, треба створити гілку:

git checkout -b new-branch

4. Вихід без збереження комітів:

git checkout main

• Нові коміти будуть втрачені, якщо не створити гілку.

Використання: тестування старих комітів, перегляд тегів, експерименти без впливу на основну гілку.

74. Як у Git відновити втрачений або випадково видалений stash?

GIT

1. Перевірка списку всіх stash:

git stash list

2. Відновлення конкретного stash:

git stash apply <stash@{n}>

• Застосовує зміни, не видаляючи їх зі списку.

3. Відновлення після випадкового видалення (git stash drop або pop):

• Знайти commit, який зберіг stash:

git fsck --no-reflogs | grep commit

• Потім застосувати його через:

git stash apply <commit_hash>

4. Профілактика:

• Регулярно робити резервні копії важливих stash.

Порада: видалений stash не завжди повністю втрачено — Git зберігає об’єкти до очищення garbage collector.

75. Як змінити повідомлення останнього коміту у Git?

GIT

1. Якщо коміт ще не запушений на remote:

git commit --amend -m "Нове повідомлення коміту"

2. Якщо коміт вже запушений:

• Змінити локально:

git commit --amend -m "Нове повідомлення коміту"

• Примусово оновити remote:

git push --force

Порада: не робіть --force на загальнодоступній гілці, щоб не порушити історію для інших розробників.

Спільна робота з Git

76. Що таке Pull Request (PR) і як він працює у Git-платформах?

GIT

• Pull Request — це запит на внесення змін з однієї гілки у іншу (зазвичай з feature-branch у main або develop) через Git-платформи: GitHub, GitLab, Bitbucket.

• Як працює:

1. Розробник створює гілку та робить коміти.

2. Відправляє гілку на remote.

3. Створює PR у веб-інтерфейсі, додає опис змін та рев’юверів.

4. Команда переглядає код, залишає коментарі, може запустити CI/CD.

5. Після схвалення PR зливається (merge) у цільову гілку.

Переваги PR:

• Контроль якості коду через рев’ю.

• Історія обговорень та змін.

• Автоматичні перевірки через CI/CD.

77. Як внести зміни в уже відкритий Pull Request?

GIT

1. Перейти у гілку, на основі якої створено PR:

git checkout feature-branch

2. Внести потрібні зміни та закомітити їх:

git add .
git commit -m "Updated changes for PR"

3. Відправити зміни у віддалений репозиторій:

git push origin feature-branch

Git автоматично оновить Pull Request на платформі (GitHub/GitLab/Bitbucket) після пушу в ту ж гілку.

78. Що таке code review (перевірка коду) у контексті Git і як він працює?

GIT

• Code review — це процес перевірки змін у коді іншими розробниками перед їх злиттям у основну гілку.

• Зазвичай відбувається через Pull Request (PR) у Git-платформах: GitHub, GitLab, Bitbucket.

Як працює:

1. Розробник створює гілку та робить коміти.

2. Відкриває PR із детальним описом змін.

3. Рев’ювери перевіряють код: стиль, логіку, тестування, безпеку.

4. Залишають коментарі або запитують зміни.

5. Після схвалення PR зміни зливаються в основну гілку.

Переваги:

• Покращує якість коду.

• Виявляє баги та проблеми на ранньому етапі.

• Підвищує знання команди про кодову базу.

79. Як вирішувати конфлікти в Pull Request перед злиттям у Git?

GIT

1. Визначити конфлікти

• GitHub/GitLab позначає PR як “This branch has conflicts that must be resolved”.

2. Оновити локальну гілку

git checkout feature-branch
git fetch origin
git merge origin/main   # або target-branch

3. Вирішити конфлікти вручну

• Відкрити файли з маркерами:

<<<<<<< HEAD
код main
=======
код feature-branch
>>>>>>> feature-branch

• Вибрати або об’єднати потрібні зміни, видалити маркери.

4. Позначити вирішені файли

git add <file>

5. Завершити злиття локально

git commit

6. Оновити PR на remote

git push origin feature-branch

Порада: для фронтенд-проектів зручніше використовувати VS Code Merge Tool або Sourcetree/IntelliJ для візуального вирішення конфліктів.

80. У чому різниця між git pull і комбінацією git fetch + git merge?

GIT

1. git fetch

• Завантажує всі зміни з віддаленого репозиторію у локальні remote-branch, але не змінює вашу поточну гілку.

• Дозволяє переглянути зміни перед інтеграцією.

2. git merge після fetch

• Локально об’єднує зміни з remote-branch у поточну гілку.

• Контролює процес злиття і конфлікти.

3. git pull

• Це швидка команда, яка фактично робить git fetch + git merge в один крок.

• Менш контрольований, бо merge відбувається автоматично.

Висновок:

• git fetch + git merge → безпечніше, дозволяє перевірити зміни перед злиттям.

• git pull → зручно, коли потрібно швидко синхронізуватися.

Продуктивність та масштабованість Git

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?

GIT

1. Shallow clone (--depth)

• Завантажувати тільки останні коміти, щоб зменшити обсяг історії.

2. Sparse checkout / partial clone

• Клонувати тільки потрібні директорії або файли (git sparse-checkout).

3. Git gc (garbage collection)

• Виконувати прибирання і оптимізацію об’єктів:

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-білдів.

83. Що таке shallow clone у Git і коли доцільно його застосовувати?

GIT

Shallow clone — це клон репозиторію з обмеженою історією комітів. Виконується командою:

git clone --depth <N> <repo-url>

де <N> — кількість останніх комітів, які потрібно завантажити.

Переваги:

• значно швидше клонування;

• менший розмір репозиторію;

• корисно для CI/CD, де потрібен лише останній стан коду.

Недоліки:

• обмежена історія (неможливо повноцінно досліджувати старі коміти);

• складніше працювати з перебазуванням і пошуком у глибокій історії.

Використовують, коли потрібен лише актуальний стан проєкту без повної історії (наприклад, білд на CI).

84. Які підходи можна застосувати для зменшення розміру репозиторію Git?

GIT

1. Прибрати непотрібні файли з історії

• Використати git filter-repo (сучасний варіант git filter-branch):

git filter-repo --path <file> --invert-paths

• (видалить файл з усієї історії).

2. Очистити великі файли у репозиторії

• Інтегрувати Git LFS для зберігання бінарників/медіа окремо.

3. Запустити прибирання

git gc --aggressive --prune=now

• (стисне об’єкти й прибере сміття).

4. Видалити старі гілки та теги

• Локально:

git branch -D <branch>

• Віддалено:

git push origin --delete <branch>

5. Використовувати shallow clone (--depth 1) на CI/CD для швидших зборок, замість повного репо.

У реальних командах основний варіант — перенесення великих файлів у Git LFS + чистка історії filter-repo.

85. Що таке Git LFS і як ним користуватись?

GIT

Git LFS (Large File Storage) — це розширення Git для зберігання великих файлів (зображення, відео, бінарники) поза основною історією репозиторію. У Git зберігаються лише посилання (пойнтери) на ці файли, а самі дані лежать у спеціальному сховищі.

Як працює:

1. Установлюємо:

git lfs install

2. Відзначаємо типи файлів, які треба винести в LFS:

git lfs track "_.png" git lfs track "_.mp4"

• (створюється/оновлюється .gitattributes).

3. Додаємо та комітимо як звичайні файли:

git add .gitattributes image.png
git commit -m "Add image with LFS"
git push origin main

Переваги:

• репозиторій не роздувається;

• швидше клонування й робота з історією;

• зручно для мультимедіа або артефактів білду.

Недоліки:

• потрібна підтримка на стороні віддаленого репозиторію (GitHub, GitLab, Bitbucket підтримують, але є ліміти);

• обмеження за розміром файлів/трафіку (особливо у безкоштовних планах).

Використовують тоді, коли в проєкті є важкі бінарні чи медіафайли, які часто оновлюються.

Інтеграція з процесами CI/CD для автоматизації розробки

86. Як Git інтегрується в CI/CD-процеси?

GIT

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 — автоматизація всіх подальших процесів.

87. Як налаштовується автоматизоване розгортання (deployment) з використанням Git?

GIT

Автоматизоване розгортання з 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 — це тригер і контроль версій, а автоматизація виконується пайплайнами, що читають код і конфіг з репозиторію.

88. Як налаштувати правила захисту гілок у Git, щоб інтегрувати їх із CI/CD?

GIT

Призначення — захищені гілки (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, а у продакшен не потрапить "сирий" код.

89. Яку роль відіграють Git hooks (гачки) в автоматизації процесів?

GIT

• 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.

90. Як Git використовується для відкату змін у разі невдалого деплою?

GIT

• Git робить відкат безпечним, оскільки кожен реліз — це фіксований коміт або тег. У випадку невдалого розгортання:

1. Повернення до стабільної версії

• checkout на попередній тег/коміт:

git checkout v1.2.3

• деплой цього стану коду.

2. Використання git revert

• створює новий коміт, що відміняє зміни проблемного:

git revert <commit_hash>

3. CI/CD інтеграція

• у пайплайні зазвичай деплої відбуваються з тегів або main/master.

• можна швидко redeploy попереднього тегу без ручного втручання.

4. Blue-Green / Canary деплоймент (залежить від інфраструктури, але Git виступає як джерело істини для коду).

Головна ідея: Git дозволяє миттєво відтворити будь-який попередній стан коду, що робить rollback контрольованим і передбачуваним.

Інтеграція Git з IDE та іншими інструментами

91. Як налаштувати та інтегрувати Git у сучасне IDE для зручної роботи?

GIT

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 скорочує контекстні переключення і робить робочий процес швидшим, особливо для фронтенд-команд.

92. Які плюси та мінуси використання GUI для Git у порівнянні з командним рядком?

GIT

Переваги 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 для щоденної роботи.

93. Які популярні плагіни та розширення використовують для інтеграції Git у IDE та редакторах коду?

GIT

Для 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.

94. Як вирішувати Git merge конфлікти за допомогою візуальних інструментів?

GIT

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. Після вирішення

git add <resolved_file>
git commit           # закомітити результат злиття

Порада:

• Візуальні інструменти особливо зручні для фронтенду, де конфлікти часто виникають у JSX, CSS, JSON.

• Для складних сценаріїв (великий обсяг коду) IDE + GUI клієнт дають максимум наочності.

95. Що таке Git bridge і яку роль він відіграє у взаємодії з іншими системами контролю версій?

GIT

• 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.

Git просунуті концепції та методи

96. Як керувати великими бінарними файлами в Git, якщо не використовувати Git LFS?

GIT

1. Ігнорування великих файлів

• Додати їх у .gitignore, щоб не відстежувати у Git:

*.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

• Не завантажувати всю історію репозиторію або непотрібні директорії:

git clone --depth 1 <repo>
git sparse-checkout init --cone
git sparse-checkout set src/

Висновок: без Git LFS великі файли краще зберігати зовні, а в Git тримати лише код і lightweight метадані.

97. Для чого використовується git rebase -i (інтерактивний rebase)?

GIT

• git rebase -i дозволяє інтерактивно змінювати історію комітів у локальній гілці.

• Основні сценарії використання:

1. Squash комітів – об’єднати кілька маленьких комітів в один.

2. Редагування повідомлень комітів – змінити commit message.

3. Видалення непотрібних комітів – drop комітів із історії.

4. Перестановка комітів – змінити порядок комітів для чистішої історії.

Приклад:

git rebase -i HEAD~3

• Відкриває останні 3 коміти в текстовому редакторі для редагування.

• Кожен коміт можна позначити як pick, squash, edit, drop.

Порада: використовувати тільки для локальної гілки, яка ще не пушилась у віддалений репозиторій, щоб не порушити історію інших розробників.

98. Як організувати безперервне резервне копіювання репозиторіїв Git?

GIT

1. Віддалені репозиторії (Remote Backup)

• Основний метод — регулярний пуш у віддалений репозиторій (GitHub, GitLab, Bitbucket, приватний сервер).

• Приклад автоматичного резервного копіювання локального репо:

git remote add backup <backup-repo-url>
git push --mirror backup

• --mirror зберігає всі гілки, теги та refs.

2. Автоматизація через CI/CD або cron

• Використати cron на сервері або workflow у CI/CD для періодичного пушу:

0 2 * * * cd /path/to/repo && git fetch origin && git push --mirror backup

3. Бекап з архівуванням

• Створювати архіви (tar/zip) репозиторію:

git bundle create repo.bundle --all

• Архів можна зберігати на іншому сервері або S3.

• Відновлення:

git clone repo.bundle -b main <new-dir>

4. Хмарне сховище

• Регулярний бекап .git директорії у S3, Google Drive, Azure Blob.

Порада:

• Комбінувати віддалений mirror + архіви для критичних проєктів.

• Перевіряти бекапи, щоб уникнути "битих" репозиторіїв.

99. Як чутливість до регістру впливає на Git і як її контролювати на різних ОС?

GIT

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:

git config core.ignorecase true # ігнорувати регістр (Windows/macOS) git config
core.ignorecase false # враховувати регістр (Linux)

• Рекомендація: у командах, де є Linux-сервери, тримати false, щоб уникнути несподіванок.

• Для зміни імен файлів регістром:

git mv File.txt temp.txt git mv temp.txt file.txt git commit -m "Fix filename
case"

Висновок:

• Регістрочутливість важлива для кросплатформових проєктів.

• Краще дотримуватись уніфікованого стилю іменування файлів і налаштувати core.ignorecase відповідно до основної CI/CD-платформи.

100. Як організувати підтримку кількох версій продукту за допомогою Git-гілок?

GIT

1. Гілка для основної версії (main/master)

• Використовується для стабільного коду, який завжди готовий до деплою.

2. Гілки для релізів (release branches)

• Кожна підтримувана версія продукту має свою гілку, напр.:

release/1.0
release/1.1
release/2.0

• На цих гілках виправляються баги, без нових функцій.

3. Гілки для розробки (feature branches)

• Створюються від main або від конкретної release/* для нових функцій або критичних патчів.

3. Злиття та backport

• Багфікси з нових релізів можна переносити (backport) у старі версії:

git checkout release/1.0
git cherry-pick <bugfix_commit_hash>

5. Тегування версій

• Кожен стабільний реліз позначати тегом для швидкого rollback або деплою:

git tag -a v1.0.0 -m "Release 1.0.0"
git push origin v1.0.0

Порада:

• Використовувати стратегію Gitflow або спрощений Release Branch Workflow.

• Кожна версія продукту підтримується окремою гілкою, що дозволяє паралельно виправляти баги у старих релізах, не блокуючи нову розробку.

101. ???

GIT

• Coming Soon... 😎

---

GIT

Вітаю! ✨ Цей репозиторій містить вичерпний конспект, який я створила під час проходження курсу Нікіти Тимошенка про Git та GitHub

📌 Конспект у форматі питання-відповіді, щоб ви могли перевірити себе та швидко знаходити потрібну інформацію.

📌 Структура наближена до курсу, тож вам буде легко орієнтуватися в темах і знаходити потрібний матеріал.

📌 Раджу пройти сам курс та прочитати конспект від Нікіти адже там багато корисного:

• детальний опис команд,
• практичні завдання,
• корисні посилання.

✨ А цей конспект допоможе вам перевірити, наскільки добре ви засвоїли отримані знання! 🚀

Якщо є якісь зауваження, або пропозиції для покращення не соромтесь створювати issues або pull requests. Я відкрита до зворотного зв'язку 🙌

Легкого навчання!😊

---

Зміст

Командний рядок

• Командний рядок — терміни
• Файлова система — терміни
• Шлях до файлів
• Читання вмісту папок(команди)
• Взаємодія з папками(команди)
• Взаємодія з файлами(команди)

Git

• Короткий огляд
• Основні налаштування
• Теорія, основні концепції
• Основні команди
• Розширення основ
• Вступ до відновлення версій
• Вступ в git branch

GitHub

• Основні концепції
• Перший репозиторій
• Файл .gitignore
• Watch, fork & stars
• Копіювання репозиторію (Fork)
• Створення Pull Requests (PR)
• Створення Issues (задач)
• Огляд типового workflow
• SSH-ключ
• Push локального репозиторію
• Гілки та pull request
• Клонування репозиторію

---

Комадний рядок

Конспект

Командний рядок — терміни

Що таке GUI?

• графічний інтерфейс користувача (Graphical User Interface)
  • спосіб взаємодії користувача з комп'ютером із використанням графічних елементів (вікна, кнопки і тд)

Що таке Сommand Line?

• командний рядок
  • текстовий інтерфейс для взаємодії з операційною системою
  • простір, де вводяться текстові команди
  • і тут же можуть викликатися і запускатися певні програми

Що таке термінал?

• програма або інструмент, який надає доступ до командного рядка (вікно, куди команди вводяться)

Що таке Shell?

• оболонка
  • програма, яка виконує команди, введені у терміналі (інтерпретатор команд)

Принцип роботи Shell (схема)

Що таке Bash?

• один із типів оболонок (Shell)
• Bourne Again Shell (Bash)
• підтримується у Windows через Git Bash

Взаємодія з ОС (схема)

---

Файлова система — терміни

Що таке каталог (директорія)?

• структура, яка використовується для організації файлів у файловій системі

Що таке поточний каталог?

• папка, в якій користувач перебуває прямо зараз
  • команди по замовчуванню виконуються у поточному каталозі

Що таке батьківський каталог?

• папка, що знаходиться на один рівень вища, за поточний

Що таке домашній каталог?

• персональний каталог користувача
  • Диск С —> Users —> User name (або USER)

Що таке кореневий каталог?

• початкова точка файлової системи
  • найвищий рівень ієрархії каталогів

Структура каталогів (схема)

---

Шлях до файлів

Що таке шлях (path)?

• адреси файлів у каталозі файлової системи

Які є два види шляхів до файлів?

• абсолютний
• відносний

Де починається абсолютний шях?

• з кореневого каталогу

Що визначає відносний шях?

• розташування файлу по відношенню до поточного каталогу

Що таке розширення файлів?

• частина назви файлу, що йде після крапки

Для чого потрібне розширення файлів?

• для визначення типу файлу

---

Командний рядок — читання вмісту папок (команди)

Конспект

Практичні завдання

Яка команда відображає вміст всієї папки, у якій знаходиться користувач?

• ls

Яка команда дозволяє відобразити вміст каталогу відмінного від поточного?

• ls path (вказати шлях)

Які типи шляхів це дозволяють?

• обидва: відносний та абсолютний

Яка команда дозволяє повернути вмісти кореневого каталогу?

• ls /

Яка команда дозволяє повернути вмісти батьківського каталогу?

• ls ..

Яка команда очищає вікно терміналу?

• clear

Як у Git Bash навігувати по командам, що вже були написані?

• стрілочка вгору (до попередніх команд)
• стрілочка вниз (до наступних команд, що були після попередніх)

Що таке прапорці команд?

• додаткові опції команд

Як впроваджуються прапорці команд?

• через дефіси, які ми пишемо після команди

Який прапорець надає довідку?

• комадна --help

Яка команда дозволяє повернути вміст всіх папок у довгому форматі (з прапорцем)?

• ls -l

Як вивести дані, які повертає команда у вигляді текстового файлу?

• your_command > file_name.extension

Яка команда дозволяє вивести вміст папок у вигляді текстового файлу?

• ls > file_name.extension
  • наприклад, ls > output.txt

Яка команда дозволяє вивести вміст папок у вигляді текстового файлу у довгому форматі?

• ls -l > file_name.extension
  • наприклад, ls -l > output.txt

---

Командний рядок — взаємодія з папками (команди)

Конспект

Практичні завдання

Яка команда показує поточну директорію?

• pwd
  • prind working directory

Що повертає ця команда?

• шлях до каталогу, у якому ми знаходимось

Яка команда дозволяє змінити поточну директорію на домашній каталог користувача?

• cd
  • change directory

Як змінити поточну директорію на якусь конкретну іншу?

• cd path (вказати шлях)

Яка команда повертає до батьківської директорії?

• cd ..

Яка команда створює нову папку?

• mkdir directory_name
  • make directory

Як створити одразу кілька папок у поточній директорії?

• mkdir directory_name_1 directory_name_2
• якщо потрібні вкладені каталоги:
  • mkdir -p dir1/dir2/dir3

Яка команда дозволяє скопіювати директорію до певної папки?

• cp -r copy_directory to_directory

Яка команда дозволяє видалити директорію?

• rm -r file_name (рекурсивне видалення)
• якщо директорія містить файли:
  • rm -rf directory_name

---

Командний рядок — взаємодія з файлами (команди)

Конспект

Практичні завдання

Яка команда створює файл?

• touch file_name.extension

Як команда дозволяє скопіювати файл і перенести його до іншої папки?

• cp copy_file destination_directory/
  • copy

Яка команда дозволяє записати щось у файл?

• echo print_something > in_file

Яка команда дозволяє повернути вміст файлу?

• cat file_name

Яка команда дозволяє видалити файл?

• rm file_name

---

Git

Git — короткий огляд

Що таке Git?

• програмне забезпечення
• система контролю версій (VCS — version control system)
  • відстежує зміни у файлах
  • дає змогу повернутися до попередніх версій
  • забезпечує зручну співпрацю команд

Що пропонує Git?

• локальну базу даних
• синхронізацію з іншими серверами
• відновлення даних у разі збою

Які основні стани файлів у Git?

1. modified — файл змінено, але не додано до бази даних
2. staged — файл підготовлено до збереження
3. committed — зміни збережено у локальній базі даних

Основні стани файлів у Git (схема)

Що робить звичайну папку локальним репозиторієм?

• папка .git

Яка команда ініціалізує репозиторій?

• git init
  • після цієї команди з'являється папка .git і наша папка стала репозиторієм

---

Git — налаштування

Як переконатися, що Git встановлено (яка команда)?

• git --version

Яка команда дозволяє змінити налаштування (конфігурацію) Git?

• git config

Який прапорець дозволяє встановити зміни конфігурації для всіх репозиторіїв (теперішніх і майбутніх)?

• --global

Як встановити ім'я користувача у конфігурації?

• git config --global user.name "your_name"

Як встановити пошту (email) користувача у конфігурації?

• git config --global user.email "your_email"

Навіщо потрібно встановлювати ці налаштування?

• щоб git міг відслідковувати, хто автор змін

Яка команда перелік всіх налаштувань конфігурації?

• git config --list

Яка команда дозволяє вивести всі папки, в тому числі приховані (трекінгові)?

• ls -a

Яка команда дозволяє перевірити статус статуси файлів?

• git status

Яка команда дозволяє отримати довідку?

• git --help
• git your_command --help (довідка для конкретної команди)

---

Git — теорія, основні концепції

Які три основні концепції git?

• коміти
• збереження усіх версій файлів
• гілки

Що таке коміт?

• збереження файлу (його версії)
• інформація про те:
  • хто зберіг
  • коли зберіг
  • що саме було зроблено
• можливість повернутися до попередніх версій файлів

Як зберігаються в комітах файли, в який не було жодних змін?

• зберігається посилання на вихідний файл

Який порядок локального збереження версій файлів?

• git add (staging area)
• git commit (committed area)

Локальне збереження файлів (схема)

Які шляхи вказання шляху до потрібної директорії (команда і два варіанти відображення шляху)?

• команда — cd
• відображення шляху:
  • перетягти папку у вікно git bash (і шлях відобразиться, треба тільки cd на початку дописати)
  • написати повністю шлях самостійно

Які каталоги git не відстежує?

• в яких немає файлів, або файлів, які ігноруються через .gitignore

---

Git — основні команди

Конспект

Додавання коду і коміти

Як додати усі файли однією командою у staging area?

• git add .

Як додати один файл у staging area?

• git add file_name

Як додати коротке повідомлення до коміту?

• git commit -m "your_comment"
• вказується коротко, які зміни зроблено

Внесення комітів через Wim (схема)

Внесення комітів через nano (схема)

Внесення комітів через notepad (схема)

Як змінити текстовий редактор і встановити його основним (команда)?

• git config --global core.editor `"your_editor"

Історія комітів

Яка команда виводить перелік всіх комітів?

• git log

Який прапорець дозволяє вивести історію у більш компактному вигляді?

• --oneline
• повний варіант команди: git log --oneline

Яка команда (з прапорцем) дозволяє подивитися зміни комітів?

• git log -p

Як вийти з інтерактивного режиму (яка клавіша)?

• q (маленька)

Яка команда дозволяє подивитись відмінності у файлах (і всього репозиторію)?

• git diff (difference)

---

Git — розширення основ

Конспект

Яка загальноприйнята практика формулювання повідомлень для комітів?

• наказова (імперативна) форма
  • (add, write, remove, delete, change, fix etc.)

Як додати тіло коміту, щоб детальніше описати зміни (послідовність кроків)?

• не закривати лапки
• клікнути enter
• перейти на новий рядок
• продовжити писати
• закрити лапки
• enter (для відправки коміту)

Як додати зміни так, щоб вони були частиною попереднього коміту, а не новоствореним комітом?

• git add .
• git commit --amend --no-edit (замість повідомлення)
• enter

Різниця у кроках між створення нового коміти і зміною існуючого (схема)

Як накопичувати зміни з різних файлів для одного коміту?

• внести зміни в різні файли та/або створити нові файли
• git add . (додаємо всі файли)
• git commit -m "your_commit"

Як додати кілька файлів (не всі) за один раз до staging area?

• git add <file_1> <file_3> <file_5>

Як побачити різницю у файлах, що вже додані до staging area?

• git diff --chached

Як повернути файли зі staging area до working area?

• після git add але до git commit
  • git restore --staged <file_name> or path to file

Як подивитися, який саме невідстежуваний файл користувач планує видалити (який прапорець)?

• -n
• повна команда: git clean -n

Яка команда дозволяє видалити невідстежувані файли з git (з прапорцем)?

• git clean -f

Яка команда дозволяє видалити невідстежувані файли і каталоги з git (з прапорцем)?

• git clean -fd
  • ця команда незворотна

Яка команда дозволяє видалити відстежувані файли з індексу та робочого каталогу?

• git rm <file_name> (remove)

Яка команда дозволяє видалити відстежувані файли тільки з індексу, залишивши його у робочому каталозі (з прапорцем)?

• git rm --cached <file_name>

---

Git — вступ до відновлення версій

Конспект

Що зберігається в комітах?

• зміни, що були зроблені у файлах

Що має унікальне кожна нова версія файлів?

• "#" — хеш-код (як id)
  • є унікальним для кожної версії файлу

Основні area (схема)

Яка команда дозволяє повернути закомічений файл (наприклад, після його видалення)?

• git restore file_name
  • за замовчування звернення до останньої закоміченої версії файлу

Яка команда дозволяє дізнатися, що було змінено в тому чи іншому коміті (по id)?

• git show commit_id

Яка команда дозволяє повернутися до конкретної версії файлу (а не тільки останньої, по id)?

• git restore --source=commit_id file_name

Яка команда дозволяє відмінити зміни, які вже були додані до staging area?

• git restore --staged file_name

Яка команда дозволяє повернутися до попередньої (та/або конкретної версії всього проєкту)?

• git reset прапорець HEAD або ID
• HEAD — останній коміт
• ID — конкретний коміт з переліку попередніх

Які прапорці має ця команда і чим вони відрізняються?

• --hard — перезапише повністю до поточної версії, до якої ми звернемося (через id) і повністю видаляє всі зміни

• --soft — дозволяє зберегти внесені зміни (у staging)

• --mixed — використовується за замовчуванням

  • всі зміни, які були додані до staging area, будуть прибрані назад у робочу директорію
  • тобто файли, які були в staging, знову стають "modified", але не видаляються

• повні команди:

  • git reset --hard ID
  • git reset --soft ID

---

Git — вступ в git branch

Конспект

Яка основна гілка проєкту?

• main (master) — різна назва, але значить одне й те саме

Принцип роботи гілок (схема)

HEAD

Що таке HEAD?

• вказівник того, де ми знаходимось
  • в якій гілці
  • в якому коміті
• за замовчуванням знаходимося в останньому коміті
• кожна окрема гілка має свій HEAD

Що означає "detached HEAD"?

• коли HEAD не вказує на останній коміт гілки, а вказує на конкретний коміт або тег

За допомогою якої команди HEAD переходить у стан detached HEAD?

• git checkout commit_hash
• у цьому випадку HEAD вказує на той коміт, а не на гілку

Що дає detached HEAD?

• У стані detached HEAD можна переглядати або тестувати код на певному коміті, але будь-які нові коміти, які будуть зроблені, не будуть пов'язані з жодною гілкою
• для збереження коміту, що був зроблений у цьому стані, потрібно створити нову гілку, щоб не втратити зміни

Як вийти зі стану "detached HEAD"?

• використати команду git checkout <branch-name>, де <branch-name> — це назва гілки, на якій ви хотіли б продовжити працювати

Принцип роботи HEAD (схема)

Конфлікти

Що таке конфлікти в git?

• ситуація, коли на одних і тих самих рядках, в одних і тим самих файлах вказані різні дані

Що значить "вирішити конфлікт"?

• конкретне вказання git, які саме зміни мають бути внесені

Merge vs Rebase

Що значить merge?

• впровадити зміни до основої гілки (об'єднати всі додаткові гілки в main)

Яка є альтернативна merge?

• rebase

Що дозволяє робити ця альтернатива?

• інтегрувати зміни після останньої актуальної версії в main гілці

Які складнощі пов'язані з цим способом?

• перезапис id деяких комітів, що може викликати певні складнощі, якщо виникне потреба відновити якісь попереднії версії

Різниця між merge і rebase (схема)

Гілки

Яка команда виведе список всіх гілок?

• якщо потрібно побачити тільки локальні гілки
  • git branch
• якщо потрібно побачити віддалені гілки
  • git branch -r

Яка команда дозволяє створити нову гілку?

• git branch branch_name

Яка команда дозволяє перемикатися між гілками?

• git checkout branch_name

Яка команда дозволяє створити і перемкнутися на гілку (одна команда — дві дії)?

• git checkout -b branch_name
  • -b — від слова branch

Яка є альтернативна команда для зміни гілки?

• git switch branch_name

Яка вона дозволяє за один крок створити гілку і одразу перемкнутися на неї (синтаксис команди)?

• git switch -b branch_name

Яка різниця між цими двома варіантами команд?

• git switch:
  • більш проста у розуміння і використанні
  • використовується спеціально для перемикання (та/або для створення і перемикання) між гілками
• git checkout:
  • більш універсальна
  • використовується для:
    • перемикання (та/або для створення і перемикання) між гілками
    • зміни гілок
    • відновлення файлів (скасування змін)
    • перемикання між комітами

В якій гілці ми маємо знаходитися перед тим, як зробити об'єднання гілок?

• в тій, в яку хочемо інтегрувати зміни (в цільовій)

Яка команда дозволяє об'єднати гілки?

• git merge branch_name

Назву якої гілки ми маємо писати у команді об'єднання?

• назву гілки, яку об'єднуємо з цільовою гілкою (тобто назву альтернативної, додаткової гілки)

Яка команда дозволяє тільки передати зміни, але не об'єднувати гілки?

• git fetch

Яка команда (з прапорцем) дозволяє видалити гілку?

• git branch -d branch_name
• git branch -D branch_name

Яка різниця між цими двома прапорцями?

• -d (soft delete) — не дозволить видалити гілку, яка ще не була передана до main (яка ще не інтегрована)
• -D (hard delete) — видалить гілку незалежно від того, чи вона вже інтегрована у main чи ще ні (безумовне видалення гілки)

---

GitHub

GitHub — основні концепції

Віддалений репозиторій

Які бувають git-сховища?

• GitHub
• GitLab
• Bitbucket, Azure DevOps, SourceForge — також популярні віддалені репозиторії

Яке типове ім'я git?

• origin - стандартна назва для віддаленого репозиторію, але її можна змінювати

Клонування (Clone)

Що передбачає концепція клонування?

• створення локальної копії віддаленого репозиторію на комп'ютері

SSH-ключ (SSH-key)

Що передбачає концепція такого ключа?

• спосіб безпечного підключення по GitHub без введення пароля
  • SSH-ключ складається з публічного та приватного ключа. Публічний ключ додається до GitHub, а приватний зберігається локально

Пуш (Push)

Що передбачає концепція push?

• надсилання змін у віддалений репозиторій

Яка команда?

• git push

Пул (pull)

Що передбачає ця концепція?

• завантаження змін з віддаленого репозиторію

Яка команда?

• git pull

Пул-реквест (Pull Request, PR)

Що передбачає ця концепція?

• запит на злиття змін із однієї гілки в іншу
• часто використовується для перевірки коду

Як називається перевірка коду іншим розробником?

• code review

Форк (Fork)

Що передбачає ця концепція?

• копіювання репозиторію в акаунт користувача, що дозволяє експериментувати з кодом, не змінюючи оригінал

README.md

Що це за файл?

• файл документації, що зазвичай містить опис проєкту, інструкції з використання та іншу корисну інформацію

Що означає розширення **.md**

• формат markdown
• система форматування тексту

Issues (Завдання)

Що передбачає ця концепція?

• систему відстеження помилок, запитів на нові функції та обговорень у репозиторії

---

GitHub — перший репозиторій

Яка має бути назва репозиторію?

• унікальною в межах репозиторію

Які бувають типи репозиторіїв?

• публічні
• приватні

Що таке ліцензія?

• документ, у якому прописано, що можна, а що заборонено робити з репозиторієм (чи можна завантажувати код, перевикористовувати його у власних проєктах і тд)
• опис можливостей взаємодії з репозиторієм

Про що говорить ліцензія MIT?

• про те, що код і файли з репозиторію можна використовувати як завгодно без обмежень, але обов'язково потрібно вказати авторство власника репозиторію, з якого беруться дані

Як можна додати файли у репозиторій?

• створити прямо на платформі у github
• завантажити з комп'ютера через командний рядок

---

GitHub — файл .gitignore

Що таке .gitignore?

• файл, який використовується для того, щоб ігнорувати певні файли та папки в git. Файли і теки, додані в .gitignore не будуть додватись у коміти та потрапляти у репозиторій

Яку папку ні в якому разі не можна додавати у репозиторій?

• node_module — тека, яка містить всі залежності, встановлені у проєкті

Якою командою можна завантажити цю папку, не завантажуючи її у репозиторій?

• npm install

---

GitHub — watch, fork & stars

Що дає змогу робити кнопка "Watch" у репозиторії?

• слідкувати за змінами репозиторію

Що дає змогу зробити кнопка "Fork"?

• зробити повну копію репозиторію

Як використовується зірочка в репозиторіях?

• як елементи рейтингу

---

GitHub — копіювання репозиторію (Fork)

Чи впливають зміни, внесені у скопійований репозиторій на оригінал?

• ніяким чином, це два окремі репозиторії

У якій вкладці можна подивитися, хто зробив копію репозиторію?

• insights —> forks

Як можна змінити видимість репозиторію (яка вкладка і шлях)?

• settings —> general —> danger zone —> change repository visibility

---

GitHub — створення Pull Requests (PR)

Що таке pull request?

• запит на об'єднання змін, які розробник вніс в код, з основною гілкою проєкту

Де розробник може вносити зміни віддалено без шкоди основному репозиторію (два варіанти)?

• створити окрему гілку (git branch -b branch_name)
• повністю скопіювати репозиторій (fork)

Яка вкладка відповідає за створення pull request?

• однойменна "Pull request"

Який статус повідомляє про те, що об'єднання можливе?

• able to merge

Головна анатомія створення реквесту (схема)

---

GitHub — створення Issues (задач)

Яка вкладка відповідає за створення завдання?

• однойменна "Issues"

Як можна створити задачу?

• натиснути на кнопку "New issue"
• ввести title — лаконічно пояснити, яка проблема виникла
• написати description (за потреби додати якісь додаткові матеріали) — запропонувати кілька рішень
• натиснути кнопку "create"

---

GitHub — огляд типового workflow

Огляд workflow роботи git-github (схема)

Які основні кроки?

1. connection — утворення зв'язку між git & github
   1. ssh-key
2. sync — синхронізація того, що є на комп'ютері і того, що є на github
   1. push local to remote repo або
   2. clone remote to local repo
3. pull — завантажити собі останню актуальну версію проєкту (оновлення локального репо)
4. branch — створюємо нову гілку
5. commit — передаємо зміни з гілки до локального репо
6. push — відправляємо всю гілку зі змінами до віддаленого репо
7. pull request — інформація про зміни, які ми плануємо передати до main
   1. code review
   2. merge
8. повторюємо цикл з пункту три

---

GitHub — SSH-ключ

Що таке ssh-ключ?

• файл, який має зберігати приватний ключ на комп'ютері та одночасно публічний ключ на github

У якій вкладці ці ключі зберігаються на github?

• profile settings —> SSH and GPG keys

Яка послідовність створення і збереження?

1. створити файл на машині, де буде зберігатися ключ
2. додати його на github

Скільки разів має створюватися цей ключ?

• один раз на одну машину

Мега важливий конспект по створенню і збереженню ssh ключа

---

GitHub — push локального репозиторію

Яка послідовність ініціалізацї, комітів та додавання файлів до локального репо (крок — команда)?

1. ініціалізація репозиторію
   1. git init
2. додати файли до staging area
   1. git add .
3. зробити коміт
   1. git commit -m "Initial commit"
4. перевірка статусу (за потреби)
   1. git status

Яка команда дозволяє відправити зміни на github?

• git remote add origin repo_link (https or ssh)

Що означає "origin"?

• використовується як псевдонім до посилання

Звідки можна взяти посилання на repo?

• з github
  • при створення порожнього репозиторію це вікно відкривається по дефолту з детальним описом, як віддалений репозиторій підв'язати до локального

Яка команда дозволяє відправити весь код з локальної машини на віддалений репозиторій після об'єднання цих репозиторіїв?

• git push -u origin main
• -u — від слова "upstream"

За що відповідає upstream?

• повідомляє github з якої гілки брати зміни та/або в яку гілку зміни завантажувати
  • Upstream гілка — це віддалена гілка, до якої підключено локальну гілку для відправки та отримання змін

Яка команда дозволяє перейменувати головну гілку (з master на main)?

• git branch -M main

---

GitHub — гілки та pull request

Яка команда дозволяє відправити на віддалений репозиторій гілку, яка була створено локально?

• git push --set -upstream origin branch_name
  • зазвичай git одразу пропонує цю команду за замовчування після команди push, тому залишається тільки скопіювати її і вставити в термінал

Що робить --set upstream?

• встановлює гілку на віддаленому репозиторії origin
  • --set-upstream встановлює зв'язок між локальною і віддаленою гілкою для автоматичної синхронізації

Анатомія гілок при pull request (схема)

---

GitHub — клонування репозиторію

За допомогою якої команди можна скопіювати репозиторій собі локально?

• git clone repo_link (https or ssh)

Яка різниця між використання https та ssh посилання?

• https вимагає явної авторизації
• з ssh ключем проводиться неявна авторизація (немає потреби кожен раз вводити логін і пароль для підтвердження)

Яка команда дозволяє відобразити які локальні гілки пов'язані з віддаленими гілками?

• git branch -vv
• також ця команда показує інформацію про останні коміти в цих гілках