Git

Налаштування та конфігурація

Команда	Назва	Опис
`git config --global user.name "Ім'я"`	Ім'я користувача	Встановлює ім'я автора для всіх Git-репозиторіїв на глобальному рівні. Це ім'я відображається у всіх ваших commit. Прапорець `--global` застосовує налаштування до всіх репозиторіїв користувача. Без `--global` налаштування застосовується лише до поточного репозиторію. Приклад: `git config --global user.name "Vlad"`. Для тимчасового перезапису в конкретному репозиторії використовуйте команду без `--global` або змінну середовища `GIT_AUTHOR_NAME`.
`git config --global user.email "mail@example.com"`	Email користувача	Встановлює email-адресу автора для всіх commit на глобальному рівні. Email прив'язується до кожного commit і використовується для ідентифікації автора. Важливо вказувати правильний email, особливо при роботі з GitHub/GitLab — він повинен збігатися з верифікованим email для push. Для приватності на GitHub використовуйте no-reply email виду `id+noreply@github.com`. Перевірити налаштування: `git config user.email`.
`git config --list`	Перегляд конфігурації	Показує всі активні налаштування Git, об'єднані з файлів: `~/.gitconfig` (глобальні), `.git/config` (репозиторій) та системні. Налаштування відображаються у форматі `section.key = value`. При конфлікті пріоритет має: локальний > глобальний > системний. Для перегляду конкретного значення: `git config user.name`. Для редагування GUI: `git config --edit`.
`git help`	Допомога	Відкриває вбудовану довідкову систему Git. Показує детальну документацію по командах, включаючи опції, приклади та посилання на додаткову інформацію. Для допомоги по конкретній команді: `git help config` або `git config --help`. Для пошуку в довідці: `git help -g` (список груп), `git help -a` (всі команди). У Windows відкриває HTML-сторінку, у Linux — man-сторінку.
`git version`	Версія Git	Показує встановлену версію Git у системі. Формат виводу: `git version X.Y.Z`. Корисно для діагностики сумісності — деякі команди доступні лише в нових версіях. Наприклад, `git switch` і `git restore` з'явилися в Git 2.23+. Для перевірки доступності Git: `git --version` (аналог). На CI/CD серверах часто вимагається певна версія Git.
`git bugreport`	Створення bug report	Генерує детальний діагностичний звіт для баг-репортів. Включає версію Git, інформацію про систему, конфігурацію, шляхи та середовище. Вивід напрямується в термінал або файл. Використовуйте перед відправкою бага: `git bugreport \| git compress`. Альтернатива — `git env` для виводу тільки змінних середовища. Корисно при відладці проблем з Git на складній конфігурації.

Створення та клонування репозиторію

Команда	Назва	Опис
`git init`	Створення репозиторію	Ініціалізує новий Git-репозиторій у поточній директорії, створюючи приховану папку `.git/` з метаданими. Після виконання ви можете почати відстежувати файли. Для ініціалізації в конкретній директорії: `git init /path/to/dir`. Для ініціалізації з початковою віткою (Git 2.28+): `git init -b main`. Прапорець `--bare` створює «голий» репозиторій без робочої директорії (для сервера). Прапорець `--separate-git-dir` дозволяє розмістити `.git` в іншому місці.
`git clone https://github.com/user/project.git`	Клонування репозиторію	Завантажує повну копію віддаленого репозиторію в локальну директорию, включаючи всю історію commit, всі вітки та теги. За замовчуванням створює локальну вітку `main` або `master` з відстеженням віддаленої вітки під ім'ям `origin`. Для клонування в конкретну директорию: `git clone url new-dir/`. Підтримує протоколи: `https://`, `ssh://`, `git@`. Для аутентифікації по SSH налаштуйте ключі: `ssh-keygen` + додайте ключ у GitHub/GitLab.
`git clone --depth 1 repo-url`	Поверхневе клонування	Клонує репозиторій з обмеженою історією commit (`--depth 1` = тільки останній commit). Значно прискорює клонування великих репозиторіїв (наприклад, ядра Linux). Історія `git log` буде містити тільки 1 commit. Для збільшення глибини після клонування: `git fetch --depth 10`. З Git 2.24+ можна конвертувати shallow-клон у повний: `git fetch --unshallow`. Не підтримує `git branch` і `git tag` без додаткового `git fetch`.
`git clone --branch dev repo-url`	Клонування вітки	Клонує конкретну вітку замість вітки за замовчуванням. Корисно при роботі з монорепо або коли потрібно одразу отримати потрібну вітку. Для клонування конкретної вітки з відстеженням: `git clone --branch dev --single-branch url`. Прапорець `--single-branch` обмежує завантаження тільки однією віткою (економить місце). Можна клонувати тег: `git clone --branch v1.0 --depth 1 url` для отримання конкретної версії.

Індексування та зміни файлів

Staging area (індекс) — проміжне сховище змін перед створенням commit. Git відстежує тільки файли, додані в staging.

Команда	Назва	Опис
Додавання файлів у staging
`git add app.js`	Додавання файлів	Додає вказаний файл у staging area, готуючи його для commit. Після `git add` зміни файла будуть включені в наступний commit. Можна додавати кілька файлів: `git add file1.js file2.css`. Підтримує glob-патерни: `git add *.md` (всі Markdown-файли). Для додавання тільки нових (untracked) файлів використовуйте `git add -N` (по частинах). Файли, яких немає в репозиторії, потрібно додавати явно — Git не відстежує їх автоматично.
`git add .`	Додати всі зміни	Додає всі змінені та нові файли в поточній директорії та піддиректоріях рекурсивно. Точка `.` означає «поточна директорія». Важливо: `git add .` не додає файли, які раніше були ігнорувані через `.gitignore`. Також не додає повністю нові (untracked) файли в піддиректоріях, якщо вони не були раніше відстежувані. Для додавання всіх untracked файлів використовуйте `git add -A` або `git add --all`.
`git add -A`	Додати всі зміни	Додає всі зміни: нові (untracked), змінені (modified) та видалені (deleted) файли відносно вказаної директорії. На відміну від `git add .`, `git add -A` також фіксує видалення файлів, яких раніше були в репозиторії. Працює швидше при великих проєктах. Альтернатива: `git add --all` (повний аналог). Для додавання тільки змінених файлів: `git add -u` (update).
`git add -p`	Інтерактивне додавання	Дозволяє вибрати конкретні hunks (частини) змін для додавання в staging. Відкриває інтерактивний режим з питаннями: `y` (додати), `n` (пропустити), `q` (вийти), `a` (все решту), `s` (розбити на частини), `e` (ручний ввід). Корисно при великих змінах, коли потрібно додати тільки частину правок. Наприклад, ви виправили баг і додали нову функцію — можна додати тільки hunks бага. Альтернатива: `git add --patch` (повний аналог).
Відновлення та видалення
`git restore index.js`	Відновлення файлів	Відновлює файл з останньої версії в working directory (анулює незатріфіровані зміни). За замовчуванням відновлює з `HEAD` (останнього commit). Для відновлення зі staging: `git restore --source=HEAD index.js`. Для відновлення до конкретної версії: `git restore --source=abc123 index.js`. Для відновлення всіх файлів: `git restore .`. Альтернатива: `git checkout -- index.js` (класичний синтаксис).
`git restore --staged app.js`	Зняти зі staging	Видаляє файл зі staging area (індекса), але зберігає зміни в working directory. Файл залишиться зміненим, але не буде готовим до commit. Аналогічно `git reset HEAD app.js`. Для видалення всіх файлів зі staging: `git restore --staged .`. З Git 3.0+ можна використовувати `--worktree` для відновлення та робочої директорії одночасно.
`git rm old.js`	Видалення файла	Видаляє файл з Git-репозиторію та файлової системи. Файл автоматично додається в staging для наступного commit. Після `git commit` файл буде повністю видалений. Для видалення тільки з Git (залишивши файл на диску): `git rm --cached old.js`. Для видалення директорії: `git rm -r dir/`. Для видалення за патерном: `git rm *.log`. Видалений файл можна відновити: `git restore old.js` (до commit) або `git checkout HEAD~1 -- old.js` (після commit).
`git rm --cached .env`	Видалення з Git	Видаляє файл тільки з Git-відстеження, але залишає його в робочій директорії. Корисно для файлів з конфіденційними даними (.env, config.php), які випадково потрапили в репозиторій. Після видалення додайте файл у `.gitignore`, щоб він більше не потрапив в репозиторій. Приклад: `git rm --cached .env && echo ".env" >> .gitignore && git add .gitignore`. Файл залишиться на диску, але перестане відстежуватися.
`git mv old.js new.js`	Перейменування файла	Переміщує або перейменовує файл з автоматичним додаванням у staging. Git відстежує перейменування через аналіз змісту (content-based detection). Альтернатива: `mv old.js new.js && git add new.js && git rm old.js` (ручний аналог). Для переміщення в іншу директорию: `git mv src/old.js dst/new.js`. Після commit перейменування буде коректно відображатися в історії: `git log --follow new.js` (прапорець `--follow` відстежує перейменування).
Статус
`git status`	Статус репозиторію	Показує поточний стан репозиторію: які файли змінені, які в staging, які untracked. Вивід розділений на секції: «Changes to be committed» (в staging) і «Changes not staged» (не в staging). Показує поточну вітку та її статус відносно remote. Корисні прапорці: `-sb` (краткий вивід з віткою), `-uno` (показувати тільки untracked файли). Для автоматичного запуску status при кожному дії: `git config status.submoduleSummary true`.
`git status --short`	Краткий статус	Виводить краткий формат статусу, зручний для парсингу скриптами. Кожна рядок: `XY filename`, де `X` — статус індекса, `Y` — статус working directory. Коди: `A` (added), `M` (modified), `D` (deleted), `?` (untracked), `R` (renamed), `U` (unmerged). Для кольорової індикації: `--porcelain` (стабільний формат для скриптів). Для виводу тільки untracked: `git status --short --untracked-files=no`.

Перевірка стану та відмінностей

Ці команди допомагають аналізувати зміни, переглядати історію та розуміти, що сталося в репозиторії.

Команда	Назва	Опис
`git diff`	Відмінність змін	Показує відмінності між working directory та staging area (або останнім commit). Виводить построчні зміни: `+` — додані рядки, `-` — видалені. Корисно перед `git add` для перевірки, що ви додаєте. Прапорці: `--stat` (статистика змін), `--color-words` (підсвітка змінених слів), `-W` (показувати тільки функції). Для порівняння конкретного файла: `git diff app.js`. Для ігнорування пробілів: `git diff -w`.
`git diff --staged`	Відмінність staged файлів	Показує відмінності між staging area та останнім commit (HEAD). Корисно перед commit для перевірки, що саме буде зафіксовано. Альтернатива: `git diff --cached` (повний аналог). Для порівняння з конкретною версією: `git diff --staged abc123`. В поєднанні з `--name-only` показує тільки імена змінених файлів: `git diff --staged --name-only`.
`git show HEAD`	Перегляд об'єкта Git	Показує зміст вказаного об'єкта Git: commit, tag або файл. `HEAD` — останній commit у поточній вітці. Показує метадані commit (автор, дата, повідомлення) та diff змін. Для перегляду конкретного commit: `git show abc123`. Для файла: `git show HEAD:app.js` (вивід змісту файла з commit). Для тега: `git show v1.0`. Для перших N рядків diff: `git show --stat HEAD`.
`git log`	Історія commit	Показує повну історію комитів поточної вітки з метаданими (автор, дата, hash). За замовчуванням виводить: hash, ім'я автора, дату та повідомлення. Для навігації використовуйте vim-подібні команди: `j` (вниз), `k` (вгору), `q` (вихід). Прапорці: `-p` (показати diff), `--stat` (статистика файлів), `--since="2 weeks ago"` (за останні 2 тижні), `--author="Vlad"` (конкретний автор), `--grep="fix"` (за повідомленням).
`git log --oneline`	Кратка історія	Компактний вивід: короткий hash (7 символів) та повідомлення кожного commit в один рядок. Ідеально для швидкого перегляду історії. Комбінуйте з іншими прапорцями: `git log --oneline --graph --all` (граф всіх віток), `git log --oneline -20` (останні 20 commit), `git log --oneline --since="2024-01-01"` (з визначеної дати). Для виводу з номерами рядків у diff: `git log -p --oneline`.
`git log --graph`	Граф віток	Візуалізує гілляння репозиторію ASCII-графіками, показуючи як вітки об'єднуються та розходяться. Комбінуйте з `--oneline` і `--all` для повного огляду: `git log --oneline --graph --all --decorate`. Прапорець `--decorate` додає імена тегов та remote-віток. Для обмеження глибини: `git log --oneline --graph --max-count=50`. Корисно для розуміння структури проєкту перед merge/rebase.
`git blame app.js`	Автор рядків	Показує построчно, хто і коли змінив кожен рядок файла. Виводить: hash commit, автор, номер рядка, зміст. Корисно для пошуку джерела багів («хто це написав?»). Прапорці: `-L 10,20` (рядки 10-20), `-C` (врахувати переміщені рядки), `-M` (врахувати скопійовані рядки), `-w` (ігнорувати пробіли). Для перегляду в реальному часі: `git blame -p app.js \| less`. Для конкретного commit: `git blame abc123 -- app.js`.

Commit

Commit (коміт) — снапс стану репозиторію в певний момент часу. Кожний commit має унікальний hash, автора, дату та повідомлення.

Команда	Назва	Опис
`git commit`	Створення commit	Створює commit із staged змін, відкриваючи текстовий редактор (vim/nano) для повідомлення. Повідомлення commit має описувати що змінено: `feat: add login page`, `fix: resolve null pointer`. Після збереження редактора commit створюється автоматично. Для налаштування редактора: `git config core.editor "code --wait"`. Для скасування: `Ctrl+C` в vim (без збереження). Commit створюється локально — для публікації використовуйте `git push`.
`git commit -m "Fix login bug"`	Commit з повідомленням	Створює commit з повідомленням в один рядок, без відкриття редактора. Корисно для автоматизації та швидких комитів. Повідомлення закладають у лапки: `-m "повідомлення"`. Для багаторядкового повідомлення: `git commit -m "Заголовок" -m "Детальний опис"`. Convention: використовуйте формат `type: description` (Conventional Commits): `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `chore`.
`git commit --amend`	Зміна commit	Змінює останній commit: замінює його новим із відредагованим повідомленням або staged змінами. Корисно для виправлення орфографічних помилок у повідомленні або додавання забутих файлів. Якщо staging порожній — тільки редагується повідомлення. Якщо є staged файли — вони додаються до останнього commit. ВАЖЛИВО: amend змінює hash commit — не використовуйте для вже опублікованих віток. Для зміни commit в середині історії: `git rebase -i`.
`git commit --amend --no-edit`	Оновлення commit	Додає staged зміни до останнього commit, зберігаючи оригінальне повідомлення. Використовується коли ви забули додати файли: `git add missed.js && git commit --amend --no-edit`. Дата і author commit зберігаються. Hash commit зміниться. Альтернатива: `git commit --amend -C HEAD` (аналогічний синтаксис). Для додавання без amend: створіть новий commit.

Вітки (Branches)

Вітка (branch) — незалежний шлях розробки. За замовчуванням всі зміни йдуть у вітку main або master. Вітки дозволяють паралельно працювати над різними функціями без втручання в основний код.

Команда	Назва	Опис
Список та створення віток
`git branch`	Список віток	Показує всі локальні вітки, поточна вітка позначена зірочкою `*`. Для вмичення інформації про останній commit: `git branch -v`. Для показу remote-віток: `git branch -a` (всі), `git branch -r` (тільки remote). Для пошуку віток з певним іменем: `git branch -a \| grep feature`. Для показу віток, злитих з поточною: `git branch --merged`. Для показу незлитих: `git branch --no-merged` (небезпечно видаляти).
`git branch feature-auth`	Створення вітки	Створює нову вітку з вказаним іменем, вказуючи на той же commit, що й поточна вітка. Вітка створюється миттєво (легка операція). Для створення з іншої вітки: `git branch feature-auth main`. Для створення та миттєвого перемикання: `git switch -c feature-auth` або `git checkout -b feature-auth`. Імена віток: стрічкові літери, дефіси, без пробілів. Дозволяється: `feature/user-login`, `fix/header-bug`, `hotfix/security`.
`git branch -d old-feature`	Видалення вітки	Видаляє вказану локальну вітку, але тільки якщо вона злита з поточною віткою (безпечне видалення). Якщо вітка не злита — Git запросить підтвердження. Після видалення commit залишаться доступними через `git reflog`. Для видалення всіх злитих віток: `git branch --merged \| grep -v '\*' \| xargs git branch -d`. Remote-вітку видалимо окремо: `git push origin --delete old-feature`.
`git branch -D`	Примусове видалення	Примусово видаляє вітку незалежно від її статусу злиття. Аналог `git branch --delete --force`. Використовуйте з обережністю — незлиті commit можуть стати важкодоступними. Зазвичай застосовується для віддалених віток: `git branch -D origin/old-feature`. Перед видаленням переконайтеся: `git branch --no-merged` покаже які вітки незлиті. Для безпеки спочатку зробіть `git log old-feature` для перевірки.
Перемикання віток
`git switch`	Перемикання вітки	Сучасна заміна `git checkout` для перемикання віток (Git 2.23+). Перемикатє working directory на вказану вітку, оновлюючи файли. Для переходу: `git switch main`. Якщо вітка не існує і потрібно створити: `git switch -c new-branch`. Для повернення до останньої вітки: `git switch -`. На відміну від checkout, switch не використовується для checkout файлів/commitів — для цього є `git restore`.
`git switch -c feature-api`	Створення + перехід	Створює нову вітку від поточної HEAD і миттєво перемикається на неї. Прапорець `-c` означає «create». Аналог: `git checkout -b feature-api` (класичний). Можна створити з іншої вітки: `git switch -c feature-api main` (від main, а не від поточної). Після створення автоматично встановлюється tracking з origin (якщо існує). Корисно у workflow: `git switch -c feature/$(echo $ISSUE \| tr '[:lower:]' '[:upper:]')`.
`git checkout`	Checkout об'єкта	Універсальна команда для checkout об'єктів. Історично використовується для віток, але також працює з commit/tag/файлами. Для віток: `git checkout main`. Для створення: `git checkout -b feature-api`. Для файлів: `git checkout -- app.js` (відновити файл). Для commit: `git checkout abc123` (detached HEAD). В Git 2.23+ рекомендується розділяти: `git switch` для віток, `git restore` для файлів.
`git checkout`	Checkout commit	Перемикає репозиторій в «detached HEAD» режим — ви можете переглядати код на конкретному commit без створення вітки. Working directory оновлюється до стану цього commit. Корисно для перегляду старих версій: `git checkout abc123`, `git checkout v1.0`. Для створення вітки з цього стану: `git checkout -b view-branch`. Для повернення: `git checkout main`. В detached режимі не можна робити commit без створення вітки.

Merge / Rebase / Cherry-pick

Ці команди об'єднують зміни з різних віток. Merge створює commit злиття, rebase переміщує commit на іншу вітку, cherry-pick копіює окремі commit.

Команда	Назва	Опис
`git merge develop`	Злиття віток	Об'єднує вказану вітку в поточну, створюючи merge-commit (або fast-forward без нового commit). При fast-forward (вітка не розійшлася) новий commit не створюється. При конфлікті злиття: Git залишить маркери `<<<` / `======` / `>>>` у файлах — вирішіть вручну, потім `git add + git commit`. Для створення merge без fast-forward: `git merge --no-ff develop` (зберігає історію вітки). Для злиття з конкретним повідомленням: `git merge develop -m "Merge feature-auth"`.
`git merge --abort`	Скасування merge	Скасовує поточний merge і повертає репозиторій в початковий стан. Працює тільки під час конфлікту злиття. Після вирішення конфлікту `--abort` вже не спрацює. Для скасування після `git commit` використовуйте `git reset --hard HEAD~1`. Альтернатива: `git merge --abort` еквівалентний `git reset --merge`. Перед merge завжди робіть `git status` для перевірки чистоти working directory.
`git rebase`	Rebase віток	Переносить всі commit поточної вітки на початок іншої вітки, створюючи лінійну історію. На відміну від merge, не створює merge-commit — commit переписуються. Корисно для підтримки чистої історії. Для rebase на main: `git rebase main`. Перед rebase переконайтеся, що вітка не опублікована — rebase змінює hash commit. Для роботи з опублікованими вітками використовуйте `git merge`. Для запобігання випадкового rebase: `git config --global rebase.verifyRemoteRefs false`.
`git rebase -i`	Interactive rebase	Відкриває інтерактивний редактор для редагування commit history. Дозволяє: `pick` (залишити), `reword` (змінити повідомлення), `edit` (зупинитися для змін), `squash` (об'єднати з попереднім), `fixup` (об'єднати, зберігши повідомлення попереднього), `drop` (видалити), `exec` (виконати команду). Для останніх N commit: `git rebase -i HEAD~5`. Для rebase на конкретний commit: `git rebase -i abc123`. Порядок в редакторі = порядок виконання (зверху — найстаріший).
`git rebase --continue`	Продовження rebase	Продовжує rebase після вирішення конфліктів. Після вирішення конфліктів у файлах: `git add` (перевірте через `git diff`), потім `git rebase --continue`. Для пропуску commit: `git rebase --skip`. Для скасування: `git rebase --abort`. При інтерактивному rebase конфлікти можуть виникати для кожного commit — повторюйте процес. Для автоматичного вирішення конфліктів: `git config rerere.enabled true` (rerere — reuse recorded resolution).
`git rebase --abort`	Скасування rebase	Повністю скасовує поточний rebase і повертає до початкового стану. Працює в будь-який момент rebase-процесу. Після abort репозиторій повністю повертається до стану до `git rebase`. Всі вирішення конфліктів втрачаються. Для збереження точки rebase: `git reflog` покаже новий HEAD. Перед abort переконайтеся, що не втратите важливі дані.
`git cherry-pick`	Копіювання commit	Застосовує зміни з вказаного commit в поточну вітку, створюючи новий commit з тими ж змінами. Корисно для перенесу фіксів між вітками: `git cherry-pick abc123`. Для кількох commit: `git cherry-pick abc123 def456` (послідовно). Для діапазону: `git cherry-pick abc123..def456`. Для останнього commit: `git cherry-pick HEAD~1`. При конфлікті: вирішіть і `git cherry-pick --continue`. Для скасування: `git cherry-pick --abort`. Для застосування без commit (тільки зміни): `git cherry-pick -n abc123` (no-commit).
`git cherry-pick --abort`	Скасування cherry-pick	Скасовує поточний cherry-pick при виникненні конфлікту. Повертає репозиторій до стану до cherry-pick. Працює тільки під час конфлікту. Після abort всі staged зміни від cherry-pick втрачаються. Для скасування вже застосованого cherry-pick: `git revert HEAD` (створює скасовуючий commit).

Робота з віддаленими репозиторіями

Remote-репозиторії — віддалені сховища коду (GitHub, GitLab, Bitbucket). За замовчуванням основний remote називається origin. Робота з remote дозволяє синхронізувати локальні та віддалені репозиторії.

Команда	Назва	Опис
`git remote -v`	Список remote	Показує всі налаштовані remote-репозиторії з URL. Прапорець `-v` (verbose) показує ім'я remote і повний URL. Зазвичай є `origin` (основний) і можливо `upstream` (для форків). Для конкретного remote: `git remote -v \| grep origin`. Для перевірки доступності: `git ls-remote origin`. Для відображення тільки імен: `git remote`. Для відображення тільки URL: `git remote get-url origin`.
`git remote add origin repo-url`	Додавання remote	Додає віддалений репозиторій з вказаним іменем та URL. Ім'я `origin` — стандартне за замовчуванням. Для додавання кількох remote (наприклад, для fork workflow): `git remote add upstream https://github.com/original/repo.git`. Для перевірки дублікатів: `git remote`. Для зміни URL: `git remote set-url origin new-url`. Для тестування підключення: `git ls-remote origin` (повинен повернути список віток).
`git fetch`	Отримання змін	Завантажує зміни з remote в локальний репозиторій БЕЗ об'єднання (merge). Після fetch ви можете переглянути зміни перед merge. Завантажує remote-вітки як `origin/branch-name`. Для завантаження конкретного remote: `git fetch origin`. Для конкретної вітки: `git fetch origin main`. Для всіх remote: `git fetch --all`. Для відстеження нових віток: `git fetch --prune` (видаляє віддалені remote-вітки з локального кешу). Для моніторингу: `git fetch --progress` (показує прогрес).
`git pull`	Отримання + merge	Виконує `git fetch` + `git merge` в одній команді. Завантажує зміни та автоматично об'єднує з поточною віткою. Аналог: `git fetch && git merge origin/main`. Для конкретного remote/вітки: `git pull origin develop`. При конфлікті: вирішіть і `git commit`. Для автоматичного stash перед pull: `git pull --autostash`. Для скасування невдалого pull: `git reset --hard ORIG_HEAD`. Використовуйте з обережністю в командній роботі — може створити несподівані merge-commit.
`git pull --rebase`	Pull через rebase	Завантажує зміни та переміщує локальні commit поверх віддалених (замість merge-commit). Створює чістішу лінійну історію. Альтернатива `git pull` з merge. Для автоматичного використання: `git config pull.rebase true`. При конфлікті: вирішіть і `git rebase --continue`. Корисно у feature-branch workflow — кожен commit залишається окремих. Для скасування: `git rebase --abort`. Не використовуйте на спільних вітках без координації команди.
`git push`	Відправка змін	Відправляє локальні commit в remote-репозиторій. Відправляють тільки вітки з tracking-налаштуванням. Для конкретної вітки: `git push origin main`. Для створення нової remote-вітки: `git push origin feature-api`. Для видалення remote-вітки: `git push origin --delete old-feature`. Для відправки всіх віток: `git push --all`. Для тегів: `git push --tags`. При конфлікті (remote має нові commit): спочатку `git pull`. Для відправки з перевіркою: `git push --dry-run` (без реального push).
`git push -u origin main`	Push з upstream	Відправлять вітку в remote та встановлює tracking (upstream) для майбутньої синхронізації. Після цього `git pull` і `git push` без аргументів будуть працювати з `origin/main`. Прапорець `-u` = `--set-upstream`. Для перевірки tracking: `git branch -vv`. Для зміни upstream: `git branch --set-upstream-to origin/main`. Для видалення: `git branch --unset-upstream`. Це стандартний workflow для першої push нової вітки.
`git push --force-with-lease`	Безпечний force push	Примусово відправлять вітку, але перевіряє що remote не змінився з останнього fetch (безпечніше `--force`). Використовується після rebase/pick, коли історія переписана. Для активації за замовчуванням: `git config push.forceWithLease true`. На відміну від `--force`, не перезапише зміни, зроблені іншими розробниками. Для GitHub/GitLab: переконайтеся що дозволено force-push. Для повної безпеки: `git push --force-with-lease --force-with-lease=origin/main` (перевіряє конкретний remote-tracking).
`git remote remove origin`	Видалення remote	Видаляє віддалений репозиторій з конфігурації. Remote можна додати назад: `git remote add origin url`. Для видалення без підтвердження: `git remote remove origin`. Альтернатива: `git remote rm origin` (короткий аналог). Для видалення всіх remote: `git remote \| xargs git remote remove`. Після видалення втрачається можливість push/pull до додавання нового remote. Для перегляду результату: `git remote` (повинен бути порожній).

Stash

Stash — тимчасове збереження незатріфікованих змін для перемикання на іншу задачу. Зміни зберігаються як окремі commit в спеціальному стеку.

Команда	Назва	Опис
`git stash`	Збереження змін	Тимчасово зберігає всі змінені та staged файли, очищаючи working directory. Стек stash обмежений (зазвичай до 50 entries). Для збереження тільки staged (не unstaged): `git stash -S` або `git stash --staged`. Для збереження untracked файлів: `git stash -u` або `git stash --include-untracked`. Для збереження ignored файлів: `git stash -all` або `git stash --all`. Stash можна відновити на будь-якій вітці — він не прив'язаний до конкретної вітки.
`git stash push -m "WIP auth"`	Stash з повідомленням	Зберігає зміни з іменуваним повідомленням для ідентифікації. Корисно при багатьох stash. Формат: `git stash push -m "описання" [path]`. Для stash конкретних файлів: `git stash push -m "auth" app.js config.js`. Для створення в конкретній вітці: `git stash push -m "WIP" --include-untracked`. Для перегляду змісту stash: `git stash show stash@{n}`. Для створення patch-stash (тільки частина змін): `git stash push -p`.
`git stash list`	Список stash	Показує всі stash entries з індексами (stash@{0}, stash@{1} і т.д.) і повідомленнями. newest stash завжди `stash@{0`. Для фільтрації: `git stash list --author="Vlad"`. Для показу конкретного: `git stash show stash@{2}`. Для видалення порожніх stash: `git stash prune`. Для підрахунку: `git stash list \| wc -l`. Stash зберігається у `.git/refs/stash`.
`git stash pop`	Відновлення stash	Застосовує останній stash (stash@{0}) та видаляє його зі стека. Working directory буде містити збережені зміни. Якщо є конфлікт: вирішіть і `git add + git commit`. Для застосування конкретного stash: `git stash apply stash@{2}`. Для застосування без видалення: `git stash apply stash@{0}`. Для pop з конкретної вітки: спочатку перемиknйтесь, потім `git stash pop`. При помилці: `git stash drop` для видалення невдалого stash.
`git stash apply`	Застосування stash	Застосовує stash до поточної вітки БЕЗ видалення зі стека. Аналогічно pop, але stash залишається доступним для повторного застосування. Для конкретного stash: `git stash apply stash@{2}`. Для застосування в іншій директорії: `git stash apply stash@{0} -- /path/to/dir`. Для перегляду без застосування: `git stash show stash@{0}`. Для застосування з конфліктом: вирішіть як звичайний merge. Для створення вітки зі stash: `git stash branch feature-name stash@{0}`.
`git stash drop`	Видалення stash	Видаляє вказаний stash entry зі стека. За замовчуванням видаляє останній: `git stash drop` (аналог `git stash drop stash@{0}`). Для конкретного: `git stash drop stash@{3}`. Для видалення всіх крім останнього: `git stash drop stash@{1}`. Після drop stash необоротним видалений — але можна відновити через `git reflog`. Для видалення всіх stash: `git stash clear`. Для видалення порожніх: `git stash prune`.
`git stash clear`	Очищення stash	Видаляє ВЕСЬ stash entries зі стека. Необоротна операція — всі збережені зміни будуть втрачені. Перед очищенням: `git stash list` для перегляду. Для безпечного очищення: спочатку застосуйте потрібні stash, потім `git stash clear`. Для очищення конкретного діапазону: використовуйте `git stash drop` по одному. Після clear `git stash list` поверне порожній результат.

Команда	Назва	Опис
`git tag`	Список тегів	Показує всі теги репозиторію в алфавітному порядку. Для сортування за версією: `git tag -v` (потрібен git-vtag). Для пошуку тегів з патерном: `git tag -l "v2."` або `git tag --list "v2."`. Для показу з commit інформацією: `git tag -n` (повідомлення), `git tag -n10` (10 символів). Для показу останнього тега: `git describe --tags`. Для сортування за датою: `git tag --sort=-creatordate` (нові першими).
`git tag v1.0.0`	Створення tag	Створює lightweight tag — просте посилання на commit без додаткової метаінформації. Для конкретного commit: `git tag v1.0.0 abc123`. Lightweight теги менші за розміром, але не містять автора, дати або повідомлення. Для створення з підписом (GPG): `git tag -s v1.0.0 -m "Release v1.0.0"`. Для створення на конкретній вітці: перемиknйтесь на потрібний commit, потім створіть тег. Lightweight теги не можна оновити — для зміни створіть новий з тим же іменем (перепише).
`git tag -a v1.0 -m "Release"`	Annotated tag	Створює annotated tag з повною метаінформацією: автор, дата, повідомлення, можливість GPG-підпису. Містить об'єкт tag у Git-сховищі (на відміну від lightweight). Для створення з конкретним автором: `git tag -a v1.0 -m "Release" --author="Vlad "`. Для GPG-підпису: `git tag -s v1.0.0 -m "Release"`. Для перевірки підпису: `git tag -v v1.0.0`. Annotated теги рекомендується для релізів.
`git push origin --tags`	Push тегів	Відправлять усі локальні теги в remote-репозиторій. Теги не відправляються автоматично при push — їх потрібно відправляти окремо. Для відправки конкретного тега: `git push origin v1.0.0`. Для відправки всіх нових тегів: `git push origin --tags`. Для видалення remote-тега: `git push origin --delete v1.0.0`. Для оновлення тега: спочатку `git tag -f v1.0.0`, потім `git push origin --tags --force`. Для перегляду що буде відправлено: `git push --dry-run origin --tags`.
`git tag -d v1.0.0`	Видалення tag	Видаляє вказаний локальний тег. Для видалення: `git tag -d v1.0.0` або `git tag --delete v1.0.0`. Для видалення всіх тегів: `git tag \| xargs git tag -d`. Після видалення локального тега, видаліть і remote: `git push origin --delete v1.0.0`. Для видалення тега на remote безпосередньо: `git push origin --delete v1.0.0`. Видалення тега не видаляє commit — вони залишаться в репозиторії. Для видалення тега та його об'єктів: `git gc --prune=now` (обротно).

Reset / Undo

Reset і Undo — команди для скасування змін на різних рівнях: HEAD (вказувач вітки), staging area (індекс) та working directory. Важливо: git reset --hard необоротний — зміни безповоротно втрачаються.

Команда	Назва	Опис
`git reset`	Reset HEAD	Переміщує HEAD та оновлює staging area, але зберігає working directory. За замовчуванням працює в режимі `--mixed`. Для конкретного commit: `git reset abc123`. Для скасування останнього commit зі збереженням staged: `git reset HEAD~1`. Для повернення до конкретної вітки: `git reset main`. Після reset непубліковані commit можна відновити через `git reflog`. Для перегляду що буде сброшено: `git reset --dry-run` (не підтримується безпосередньо — використовуйте `git diff HEAD`).
`git reset --soft`	Soft reset	Переміщує HEAD, але зберігає staged зміни в staging area та working directory. Корисно для об'єднання кількох commit в один: `git reset --soft HEAD~3` (об'єднує 3 commit). Commit залишається в staging — наступний commit включить всі зміни. Для виправлення останнього commit: `git reset --soft HEAD~1` + `git commit`. Working directory не змінюється. Hash commit зміниться. Використовуйте `git log` для перевірки результату.
`git reset --mixed`	Mixed reset	Переміщує HEAD та оновлює staging area, але зберігає зміни в working directory (не staged). Це режим за замовчуванням для `git reset` без прапорця. Зміни залишаються у файлах, але потрібно знову додати через `git add`. Для конкретного commit: `git reset --mixed abc123`. Для поточної вітки: `git reset --mixed HEAD~1`. Зміни можна знову stage і commit. Для перевірки: `git status` покаже змінені файли.
`git reset --hard`	Hard reset	Повністю переміщує HEAD, очищає staging area та оновлює working directory до вказаного commit. ВСІ зміни (staged і unstaged) безповоротно видаляються. Використовуйте з крайньою обережністю! Для скасування останнього commit: `git reset --hard HEAD~1`. Для повернення до конкретної версії: `git reset --hard abc123`. Для очищення untracked файлів: `git clean -fd` (окрема команда). Для безпеки: спочатку `git status` і `git diff`. Для відновлення після помилкового reset: `git reflog` + `git reset --hard ORIG_HEAD`.
`git revert`	Revert commit	Створює НОВИЙ commit, який скасовує зміни вказаного commit. На відміну від reset, безпечний для опублікованих віток — не переписує історію. Для одного commit: `git revert abc123`. Для діапазону: `git revert abc123..def456`. Для останнього: `git revert HEAD`. Для скасування без відкриття редактора: `git revert --no-edit HEAD`. Для скасування кількох: `git revert abc123 def456 ghi789`. При конфлікті: вирішіть і `git revert --continue`. Для скасування: `git revert --abort`.
`git clean -fd`	Видалення untracked	Видаляє untracked (невідстежувани) файли та директорії з working directory. Прапорець `-f` (force) обов'язковий для реального видалення, `-d` — включає директорії. Для перегляду що буде видалено без видалення: `git clean -fd --dry-run`. Для видалення тільки файлів: `git clean -f`. Для видалення тільки директорій: `git clean -fd`. Для видалення ignored файлів: `git clean -fdx`. Для інтерактивного видалення: `git clean -i` (режим interactive). Для видалення тільки файлів з розширенням: використовуйте `find` + `git clean`. Перед clean завжди робіть `--dry-run`!

Робота з історією

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

Команда	Назва	Опис
`git reflog`	Історія HEAD	Показує ВСІ зміни HEAD (та інших refs) включаючи reset, merge, checkout, rebase. На відміну від `git log`, reflog показує навіть «втрачені» commit. Корисний для відновлення після `git reset --hard`. Формат: `hash@{n: timestamp}`. Для пошуку втраченого commit: `git reflog \| grep "message"`. Для відновлення: `git reset --hard abc123` (з reflog). Для конкретного ref: `git reflog show origin/main`. Для очищення: `git reflog expire --expire=now --all`. Commit залишаються доступні до `gc` (зазвичай 30 днів).
`git shortlog`	Кратка статистика	Групує commit по авторах, показуючи кількість commit кожного. Корисний для оцінки внеску учасників. Для всього репозиторію: `git shortlog`. Для конкретної вітки: `git shortlog main`. Для конкретного файла: `git shortlog -- app.js`. Прапорці: `-s` (тільки рахунок), `-n` (за кількістю), `-e` (показати email), `-a` (всі вітки), `-p` (розбіжка за підсистемами). Для включення всіх комитів (не тільки HEAD): `git shortlog --all`. Для експорту: `git shortlog -s -n --all > CONTRIBUTORS.md`.
`git describe`	Опис commit	Знаходить найближчий тег до вказаного commit і описує його у форматі `tag-N-gsha` (N commit після тега, ghash — hash). Корисний для визначення версії коду. Для поточного HEAD: `git describe`. Для конкретного commit: `git describe abc123`. Для тільки останнього тега: `git describe --tags --abbrev=0`. Для тегів з префіксом: `git describe --tags --match "v*"`. Для CI/CD: `git describe --always --abbrev=0` (завжди повертає результат). Для номера версії: `git describe --tags \| sed 's/^v//'` .
`git bisect`	Пошук bug commit	Використовує бінарний пошук для знаходження commit, який вніс баг. Працює в 3 кроках: 1) `git bisect start bad good`, 2) `git bisect run test-command` або `git bisect good/bad` вручну. Для автоматичного пошуку: `git bisect start HEAD~10 v1.0` (bad=HEAD~10, good=v1.0), потім `git bisect run npm test`. Для ручного: `git bisect good` (бага немає) / `git bisect bad` (бага є). Git сам вибере наступний commit для перевірки. Для виходу: `git bisect reset`. Для візуалізації: `git bisect visualize`.
`git range-diff`	Порівняння rebase	Порівнює два діапазони commit (зазвичай до і після rebase), показуючи як змінилися patch-и. Корисний для перевірки коректності rebase. Для порівняння: `git range-diff origin/main..HEAD main..HEAD`. Для порівняння з конкретними діапазонами: `git range-diff abc123..def456 ghi789..jkl012`. Прапорці: `--color` (підсвітка), `--indent-heuristic` (відступи). Для ревью перед push після rebase: `git range-diff HEAD~5 HEAD origin/HEAD~5 origin/HEAD`. Показує: які commit змінені, які додані, які видалені. Незамінний для безпечного rebase опублікованих віток.

Worktree та Submodules

Worktree дозволяє мати кілька робочих директорій для одного репозиторію з різними вітками. Submodule дозволяє вбудувати один Git-репозиторій в інший.

Команда	Назва	Опис
`git worktree add`	Додаткова робоча копія	Створює додаткову робочу копію репозиторію в вказаній директорії з вказаною віткою. Корисний для паралельної роботи над кількома задачами без commit/stash. Для створення: `git worktree add ../feature-api feature-api`. Для створення з існуючої вітки: `git worktree add ../hotfix hotfix`. Для створення нової вітки: `git worktree add -b new-feature ../new-feature`. Worktree ділить об'єкт репозиторію, але має окремий staging та working directory. Для перевірки: `git worktree list`. Для видалення: `git worktree remove ../feature-api`. Для автоматичного видалення при видаленні вітки: `git config worktree.autoprune on`.
`git worktree list`	Список worktree	Показує всі worktree репозиторію з шляхами та статусом. Формат: `path branch HEAD [detached]`. Для детального виводу: `git worktree list --porcelain` (для скриптів). Для показу тільки активних: `git worktree list \| grep -v detached`. Для показу з інформацією про вітку: `git worktree list -v`. Для видалення «мертвих» worktree: `git worktree prune`. Для перевірки що worktree не використовується: `git worktree list --ahead-behind` (показує різницю з upstream).
`git submodule add repo-url libs/core`	Додавання submodule	Додає зовнішній Git-репозиторій як підмодуль в вказану директорию. Створює запис у `.gitmodules` та клонує репозиторій. Для додавання: `git submodule add https://github.com/user/lib.git libs/core`. Для іменованого submodule: `git submodule add -b main repo-url libs/core --name my-lib`. Після додавання: `git add .gitmodules libs/core && git commit -m "Add submodule"`. Для оновлення URL submodule: `git submodule set-url libs/core new-url`. Для зміни вітки: `git submodule update --remote -- libs/core`.
`git submodule update --init --recursive`	Ініціалізація submodule	Клонує та ініціалізує всі підмодулі репозиторію. `--init` — ініціалізує submodule із `.gitmodules`. `--recursive` — рекурсивно обробляє вкладені submodules. Для повного клонування з submodules: `git clone --recurse-submodules url`. Для оновлення до конкретних комитів: `git submodule update`. Для оновлення до останніх віддалених версій: `git submodule update --remote`. Для ініціалізації конкретного submodule: `git submodule init libs/core && git submodule update libs/core`. Для синхронізації URL: `git submodule sync --recursive`.

Архівування та перенос

Команди для створення переносних архівів репозиторію, які можна distribute без Git-метаданих або з повною історією.

Команда	Назва	Опис
`git archive`	Створення архіву	Створює архів (zip/tar) змісту репозиторію БЕЗ Git-метаданих. Для конкретного commit/тега: `git archive -o release.zip v1.0.0`. Для tar з gzip: `git archive --format=tar.gz -o release.tar.gz HEAD`. Для конкретної директорії: `git archive -o src.tar HEAD -- src/`. Для додавання prefix в архів: `git archive --prefix="my-project/" -o release.zip HEAD`. Для виводу в stdout: `git archive HEAD \| gzip > release.tar.gz`. Для перегляду зміст без розпакування: `git archive HEAD --list`. Корисний для CI/CD деплою та створення релізів.
`git bundle create`	Bundle репозиторію	Експортує повну Git-історію в один файл, який можна перенести на іншу машину та клонувати. Для створення: `git bundle create repo.bundle main`. Для bundle з умовою: `git bundle create repo.bundle v1.0.0..HEAD` (тільки нові commit). Для перевірки: `git bundle verify repo.bundle`. Для списку віток: `git bundle list-heads repo.bundle`. Для клонування: `git clone repo.bundle`. Bundle містить повну історію — розмір близький до `.git` директорії. Корисний для переносу репозиторію через USB або при відсутності мережевого доступу.

Діагностика та обслуговування

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

Команда	Назва	Опис
`git fsck`	Перевірка репозиторію	Перевіряє цілісність Git-об'єктів і знаходить пошкоджені/сироти. Для повної перевірки: `git fsck --full`. Для показу тільки помилок: `git fsck --strict`. Для показу dangling об'єктів: `git fsck --dangling`. Для перевірки конкретного об'єкта: `git fsck --unreachable`. Для перевірки з вивідом інформації про кожен об'єкт: `git fsck --verbose`. Типові результати: `dangling commit` (втрачені commit), `dangling blob` (втрачені файли). Для відновлення dangling: `git fsck --dangling \| grep commit \| awk '{print $3}'`. Перед `git gc` завжди запускайте `git fsck`.
`git gc`	Garbage collection	Оптимізує репозиторій, видаляючи nieuikористовувані об'єкти та стискаючи дані. Автоматично запускається при push/commit, але можна запустити вручну: `git gc`. Для примусової побілки: `git gc --prune=now` (видаляє все старше 2 тижнів). Для видалення конкретних об'єктів: `git gc --prune=abc123`. Для оптимізації без видалення: `git gc --aggressive` (повільніше, але краще стиснення). Для перевірки перед gc: `git fsck`. Для автоматичної налаштування: `git config gc.auto 256` (автоматично при >256 об'єктів). Для моніторингу результату: `git count-objects -v`.
`git maintenance run`	Обслуговування Git	Запускає комплексне обслуговування репозиторію (Git 2.34+). Включає: gc, repack, index optimization, commit-graph. Для ручного запуску: `git maintenance run`. Для фонової роботи: `git maintenance start` (запускає як фоновий процес). Для зупинки: `git maintenance stop`. Для налаштування інтервалу: `git maintenance set --interval daily`. Для однократного запуску з aggressive-оптимізацією: `git maintenance run --aggressive`. Для перегляду статусу: `git maintenance status`. Працює тільки з звичайними (не bare) репозиторіями.
`git count-objects -v`	Статистика об'єктів	Показує детальну статистику об'єктів Git. Вивід: `count: N` (кількість об'єктів), `size: N` (розмір в КБ), `in-pack: N` (в pack-файлах), `packs: N` (кількість pack), `prunable: N` (можна видалити), `size: N` (розмір prunable), `empty: N` (порожні pack). Для краткого формату: `git count-objects` (тільки count + size). Для моніторингу росту репозиторію: запускайте регулярно. Якщо `prunable` великий — запустіть `git gc --prune=now`. Якщо `count` > 10000 — репозиторій потребує оптимізації.

Сучасні команди Git

Нові команди Git (2.23+), які розділяють функціональність старих команд для кращої ясності та безпеки.

Команда	Назва	Опис
`git switch`	Перемикання віток	Сучасна альтернатива checkout для перемикання віток (Git 2.23+). Розділяє функціональність checkout: тільки вітки, не файли/commit. Для перемикання: `git switch main`. Для створення та перемикання: `git switch -c feature-api`. Для повернення до попередньої: `git switch -`. Для detached HEAD: `git switch --detach abc123`. На відміну від checkout, switch не може випадково відновити файл — це запобігає випадним втратам. Для налаштування за замовчуванням: `git config checkout.defaultRemote main`.
`git restore`	Відновлення файлів	Сучасна команда undo для роботи з файлами (Git 2.23+). Розділяє функціональність checkout: тільки відновлення файлів. Для відновлення файла: `git restore app.js` (з HEAD). Для відновлення зі staging: `git restore --source=HEAD app.js`. Для відновлення всіх файлів: `git restore .`. Для видалення зі staging: `git restore --staged app.js`. Для відновлення до конкретної версії: `git restore --source=abc123 app.js`. Для відновлення тільки working directory (не staging): `git restore --worktree app.js`. Комбінуйте з switch для повного контролю.
`git sparse-checkout`	Частковий checkout	Дозволяє клонувати тільки частина файлів monorepo (економить місце і час). Для ініціалізації: `git sparse-checkout init --cone`. Для додавання директорій: `git sparse-checkout add libs/core docs`. Для списку: `git sparse-checkout list`. Для видалення: `git sparse-checkout remove libs/core`. Для вимкнення: `git sparse-checkout disable`. Для клонування з sparse: `git clone --filter=blob:none --sparse url && git sparse-checkout init --cone`. Для оновлення: `git sparse-checkout set libs/core src`. Працює з Git 2.28+ і server support `filter` protocol.
`git worktree`	Нескілька робочих директорій	Паралельна робота з вітками в окремих директоріях. Для створення: `git worktree add ../feature-api feature-api`. Для створення нової вітки: `git worktree add -b new-feature ../new-feature`. Для списку: `git worktree list`. Для видалення: `git worktree remove ../feature-api`. Для видалення з примусовим: `git worktree remove -f ../feature-api`. Для автоматичного видалення при видаленні вітки: `git config worktree.autoprune on`. Для очищення мертвих: `git worktree prune`. Worktree ділить об'єкт репозиторію, але має окремий staging та working directory. Корисний для hotfix-ів під час розробки.
`git maintenance`	Автоматичне обслуговування	Оптимізація репозиторію (Git 2.34+). Для запуску: `git maintenance run`. Для фонової роботи: `git maintenance start` (запускає як daemon). Для зупинки: `git maintenance stop`. Для статусу: `git maintenance status`. Для налаштування інтервалу: `git maintenance set --interval daily`. Для aggressive-режиму: `git maintenance run --aggressive`. Включає: gc, repack, index optimization, commit-graph. Працює тільки зі звичайними репозиторіями. Для Windows: використовуйте `git maintenance start` з планировщиком завдань.
`git backfill`	Partial clone objects	Завантажує відсутні об'єкти partial clone (Git 2.38+). Для partial clone репозиторіїв (з `--filter`): `git backfill`. Для завантаження конкретних об'єктів: `git backfill pack` . Для завантаження всіх: `git backfill --all`. Для перевірки статусу: `git backfill status`. Partial clone завантажує об'єкти по запиту — спочатку завантажується тільки структура. Backfill дозавантажує всі об'єкти для повної локальної роботи. Для створення partial clone: `git clone --filter=blob:none url`. Backfill корисний для дуже великих репозиторіїв (ядро Linux, Chromium).