Що таке Squash commits у Git?

Squash об'єднує декілька комітів в один перед злиттям: чиста історія main, кожен коміт — логічно завершена фіча.

Як відкатити неправильний push у Git?

Якщо ніхто не pulled: git reset --hard HEAD~1 + git push --force-with-lease. Якщо вже pulled: git revert HEAD.

Version Control

Git — розподілена система контролю версій

Q: Rebase vs Merge в Git — що обрати?

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

Q: Git Submodules vs Monorepo?

Submodules — окремі репозиторії всередині основного, складніші в управлінні. Monorepo — один репозиторій для всіх проєктів, атомарні зміни та спільні залежності.

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

Distributed VCS Branching CI/CD Integration GitHub/GitLab

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

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

Distributed Version Control

Кожен розробник має повну копію репозиторію з історією змін. Робота можлива офлайн, а синхронізація відбувається через push/pull з віддаленими репозиторіями.

Branching Strategies

Гілки дозволяють ізольовано розробляти функції, виправляти баги та готувати релізи. Git Flow, GitHub Flow, Trunk Based — різні підходи до організації роботи з гілками.

Collaboration & Code Review

Pull/Merge Requests — механізм колаборації через код-рев'ю. CI/CD інтеграція запускає тести автоматично, забезпечуючи якість перед злиттям.

Git Workflow: від змін до віддаленого репозиторію

Класичний Git workflow складається з чотирьох зон, через які проходять зміни перед потраплянням до спільного репозиторію.

Working Directory

→

Staging Area

→

Local Repository

→

Remote Repository

📁 Working Directory → Staging

Файли у робочій директорії можуть бути untracked, modified або staged. Команда git add переміщує зміни до staging area — індексу наступного коміту. Можна додавати окремі файли або частини файлів (-p для інтерактивного вибору).

💾 Local → Remote Repository

Команда git commit зберігає зміни у локальному репозиторії з унікальним хешем SHA-1. git push відправляє коміти на віддалений сервер (GitHub, GitLab, Bitbucket). git pull отримує та інтегрує зміни з віддаленого репозиторію.

Інтерактивний симулятор Git-репозиторію

Моделювання характеристик репозиторію залежно від параметрів команди: розмір, кількість гілок, частота комітів та розробників.

Розмір репозиторію (MB) 50

Кількість гілок (1-50) 5

Комітів на день 10

Кількість розробників 5

Depth git history (комітів) 1000

% бінарних файлів 10

Рекомендується shallow clone для великих репозиторіїв.

Розмір клону -

Час клонування -

Ймовірність конфліктів -

Глибина історії -

Git workflow команди та CI/CD конфігурація

Найпоширеніші Git команди для роботи з гілками, комітами, злиттям та перебазуванням, а також типова конфігурація GitHub Actions для автоматизації.

# Git Workflow команди

# Створення та переключення на нову гілку
git checkout -b feature/new-feature
# або (Git 2.23+)
git switch -c feature/new-feature

# Перегляд статусу та додавання змін
git status
git add filename.txt          # конкретний файл
git add .                     # всі зміни
git add -p                    # інтерактивний вибір

# Створення коміту з повідомленням
git commit -m "feat: add user authentication"

# Синхронізація з віддаленим репозиторієм
git fetch origin
git pull origin main
git push origin feature/new-feature

# Злиття та перебазування
git merge feature/new-feature  # злиття гілки
git rebase main                # перебазування на main
git rebase -i HEAD~3           # інтерактивне перебазування

# Корисні команди
git log --oneline --graph --all  # візуальна історія
git stash                        # тимчасово сховати зміни
git cherry-pick <commit>         # скопіювати коміт
git reset --soft HEAD~1          # скасувати останній коміт

# .github/workflows/ci.yml
# GitHub Actions CI/CD конфігурація

name: CI/CD Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    
    steps:
    - name: Checkout code
      uses: actions/checkout@v4
      with:
        fetch-depth: 0  # повна історія для sonar

    - name: Setup Node.js
      uses: actions/setup-node@v4
      with:
        node-version: '20'
        cache: 'npm'

    - name: Install dependencies
      run: npm ci

    - name: Run linter
      run: npm run lint

    - name: Run tests
      run: npm test -- --coverage

    - name: Build
      run: npm run build

    - name: Deploy to staging
      if: github.ref == 'refs/heads/develop'
      run: npm run deploy:staging

    - name: Deploy to production
      if: github.ref == 'refs/heads/main'
      run: npm run deploy:prod

Порівняння branching strategies

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

Характеристика	Git Flow	GitHub Flow	Trunk Based
Головна гілка	main + develop	main	trunk (main)
Тривалість гілок	Довгоживучі (feature, release)	Короткоживучі (PR)	Дуже короткі (<1 день)
Частота релізів	Рідко (тижні/місяці)	Часто (декілька разів на день)	Дуже часто (багато разів на день)
Розмір команди	Будь-який	Малий-середній	Досвідчені команди
Складність	Висока	Низька	Середня
Feature flags	Не обов'язково	Рекомендовано	Обов'язково
Коли використовувати	З запланованими релізами, QA процесом	Веб-додатки, SaaS, continuous delivery	High-frequency deployment, DevOps культура

Git Anti-patterns

Commit до main напряму — завжди використовуйте pull requests.
Великі коміти — комітьте логічно завершені зміни частіше.
Неописові повідомлення — використовуйте конвенцію (feat:, fix:, docs:).
Довгоживучі feature-гілки — інтегруйте зміни частіше для зменшення конфліктів.
Забутий .gitignore — не комітьте залежності, білди та секрети.
Force push у shared гілки — небезпечно для командної роботи.
Залишені merge конфлікти — завжди тестуйте після вирішення конфліктів.

Кар'єрний шлях DevOps/Engineer

Junior Developer

Базові команди Git (add, commit, push, pull). Робота у feature-гілках. Розуміння PR/MR процесу.

Mid-Level Developer

Rebase, cherry-pick, stash, reflog. Code review навички. Понимання branching strategy команди.

Senior Developer / Team Lead

Архітектура Git workflow, налаштування захисту гілок. CI/CD інтеграція, Git hooks, automation.

DevOps / Platform Engineer

Self-hosted Git (GitLab, Gitea), монорепозиторії. GitOps, infrastructure as code, advanced workflows.

FAQ про Git

Rebase vs Merge — що обрати?

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

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

Ніколи не використовуйте rebase для публічних гілок, над якими працюють інші!

Що таке Squash і коли його використовувати?

Squash об'єднує декілька комітів в один перед злиттям. Переваги:

Чиста історія main без проміжкових "WIP" комітів.
Кожен коміт у main — логічно завершена фіча.
Спрощення revert — відкат цілої фічі одним комітом.

Більшість платформ (GitHub, GitLab) підтримують "Squash and merge" у PR.

Як працює Cherry-pick?

Cherry-pick застосовує зміни з конкретного коміту до поточної гілки без повної історії вихідної гілки. Використовується для:

Швидкого виправлення критичного багу на production без злиття всієї гілки.
Копіювання конкретних змін між гілками розробки.

git cherry-pick abc123 — застосує коміт з хешем abc123 до поточної гілки.

Git Submodules vs Monorepo?

Submodules — окремі репозиторії всередині основного. Підходять для:

Спільних бібліотек між незалежними проєктами.
Фіксація конкретної версії залежності.

Monorepo — один репозиторій для всіх проєктів. Переваги:

Атомарні зміни через межі проєктів.
Єдиний CI/CD, легше рефакторити shared код.
Єдине місце для issue tracking.

Як відкатити неправильний push?

Якщо ніхто ще не pulled:

git reset --hard HEAD~1 — локальний відкат.
git push --force-with-lease — форсований push (безпечніший ніж --force).

Якщо вже pulled: використовуйте git revert — створить новий коміт, що скасовує зміни, зберігаючи історію чистою.

Що робити при merge конфлікті?

Кроки вирішення конфлікту:

Переконайтесь, що розумієте обидва варіанти коду.
Відредагуйте файли, видаливши маркери <<<<<<<, =======, >>>>>>>.
Перевірте, що код працює коректно (запустіть тести).
git add . && git commit для завершення merge.

Профілактика: частіше pull з main, менші PR, комунікація в команді.

Глосарій Git

Commit

Знімок стану файлів у репозиторії з унікальним SHA-1 хешем. Містить автора, дату та повідомлення. Базова одиниця історії Git.

Branch

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

Merge

Операція об'єднання двох гілок. Створює merge commit з двома батьками або fast-forward, якщо можливо лінійне переміщення.

Rebase

Перезастосування комітів однієї гілки поверх іншої. Створює "чисту" лінійну історію, але змінює хеші комітів.

Staging

Проміжна область (index) між робочою директорією та репозиторієм. git add поміщає файли в staging для наступного коміту.

HEAD

Вказівник на поточний коміт чи гілку. HEAD~1 — батьківський коміт, HEAD~3 — три коміти назад. Від detached HEAD можна створити нову гілку.