Шпаргалка по Git: все команды для работы с ветками и репозиториями

Ищете быстрый справочник по Git? Эта шпаргалка содержит все основные и продвинутые команды с практическими примерами для ежедневной работы с системой контроля версий.
Быстрая навигация: что искать по ситуации

Для новичков:

Для командной работы:

Продвинутые сценарии:

Самые частые задачи:

Git — распределённая система контроля версий, фундаментальный инструмент в разработке. Эта шпаргалка поможет быстро найти нужную команду: от настройки до продвинутых приёмов отладки.

Как пользоваться: Команды сгруппированы по задачам. Начните с базовых блоков, а расширенные используйте по мере роста мастерства. Для глубокого погружения обратитесь к официальной книге.

Установка и настройка Git

Базовые команды для начала работы

# Инициализировать новый репозиторий в текущей папке
git init

# Клонировать удалённый репозиторий
git clone <url-репозитория>

# Установить глобальное имя пользователя и email (обязательно для коммитов)
git config --global user.name "Ваше Имя"
git config --global user.email "ваш.email@example.com"

# Просмотреть все текущие настройки
git config --list

Расширенные настройки и инструменты

Для тонкой настройки окружения и оптимизации workflows.

# Создать короткий алиас для команды (пример: `git co` вместо `git checkout`)
git config --global alias.<короткое-имя> "<полная-команда>"

# Установить текстовый редактор по умолчанию для Git (например, VSCode)
git config --global core.editor "code --wait"

# Включить цветной вывод всех команд Git
git config --global color.ui auto

# Кэшировать учётные данные на 1 час (чтобы не вводить логин/пароль)
git config --global credential.helper "cache --timeout=3600"

# Настроить внешний инструмент для сравнения файлов (diff)
git config --global diff.tool vscode
git config --global difftool.vscode.cmd "code --wait --diff $LOCAL $REMOTE"

# Настроить внешний инструмент для разрешения конфликтов (merge)
git config --global merge.tool vscode

# Запустить сравнение через внешний инструмент
git difftool

# Запустить инструмент для разрешения конфликтов слияния
git mergetool

Файловые операции и базовый рабочий цикл

Основной цикл: статус, добавление, коммит

# Показать состояние файлов: изменённые, новые, удалённые
git status

# Добавить конкретный файл в индекс (staging area)
git add <имя_файла>

# Добавить ВСЕ изменённые/новые файлы в индекс
git add .

# Зафиксировать изменения в репозитории с сообщением
git commit -m "Краткое описание изменений"

# Показать разницу между рабочим каталогом и последним коммитом
git diff

Удаление и перемещение файлов под контролем Git

# Удалить файл из индекса и рабочего каталога
git rm <имя_файла>

# Удалить файл только из индекса (оставить в рабочем каталоге)
git rm --cached <имя_файла>

# Переименовать или переместить файл (Git отследит историю)
git mv <старое_имя> <новое_имя>

Сравнение изменений и работа с историей файлов

# Показать разницу между двумя конкретными коммитами
git diff <хэш_коммита_1>..<хэш_коммита_2>

# Показать разницу между текущим состоянием и конкретным коммитом
git diff <хэш_коммита>

# Показать, что изменилось в конкретном коммите
git show <хэш_коммита>

Расширенные приёмы работы с индексом

Для ситуаций, когда нужно временно исключить файлы из отслеживания или детально управлять тем, что попадает в коммит.

# Временно отключить отслеживание изменений в файле (файл "исчезнет" из git status)
git update-index --assume-unchanged <имя_файла>

# Возобновить отслеживание изменений в файле
git update-index --no-assume-unchanged <имя_файла>

# Интерактивное добавление: выбрать, какие части изменений добавить в коммит
git add -p <имя_файла>

Восстановление файлов (git restore)

Безопасная замена для git checkout -- <файл> и git reset HEAD <файл>.

# Отменить изменения в рабочем каталоге (вернуть к состоянию в индексе)
git restore <файл>

# Вернуть файл к состоянию в определённом коммите
git restore --source=<хэш_коммита> <файл>

# Убрать файл из индекса (отменить `git add`), оставив изменения в рабочем каталоге
git restore --staged <файл>

# Комбинированная операция: убрать из индекса И вернуть к состоянию в HEAD
git restore --staged --worktree <файл>

Классический способ (git checkout и git reset)

# Отменить изменения в файле (устаревший способ, менее безопасный)
git checkout -- <файл>

# Убрать файл из индекса (устаревший способ)
git reset HEAD <файл>

Ветвление и слияние

Создание, просмотр и удаление веток

# Показать список локальных веток (текущая будет помечена *)
git branch

# Создать новую ветку с указанным именем
git branch <имя_новой_ветки>

Совет: Для работы с несколькими ветками одновременно без их переключения используйте git worktree.

# ----------- ПЕРЕКЛЮЧЕНИЕ ВЕТОК (рекомендуемый способ) -----------
# Переключиться на существующую локальную ветку
git switch <имя_ветки>

# Создать новую ветку И сразу переключиться на неё
git switch -c <имя_новой_ветки>

# Создать ветку, которая отслеживает удалённую ветку, и переключиться на неё
git switch -c <локальное_имя> --track <имя_удалённого_репозитория>/<удалённое_имя>

# ----------- КЛАССИЧЕСКИЙ СПОСОБ (git checkout) -----------
# Переключиться на существующую ветку (устаревший, но всё ещё рабочий способ)
git checkout <имя_ветки>

# Создать новую ветку И сразу переключиться на неё (устаревший способ)
git checkout -b <имя_новой_ветки>

# ----------- УДАЛЕНИЕ ВЕТОК -----------
# Удалить локальную ветку (если она уже слита)
git branch -d <имя_ветки>

# Принудительно удалить локальную ветку (даже если не слита)
git branch -D <имя_ветки>

Подробнее о преимуществах git switch над устаревшим git checkout читайте в статье «Современные команды и возможности Git» и детальном сравнении switch vs checkout.

Если вы случайно удалили ветку, её можно восстановить. Подробное руководство по восстановлению удалённых веток.

Базовое слияние веток

# Влить изменения из указанной ветки в текущую
git merge <имя_ветки_для_слияния>

# Отменить процесс слияния в случае конфликтов
git merge --abort

После того как вы освоили слияние веток (merge), можно изучить более продвинутый способ интеграции изменений — перебазирование. Оно создаёт линейную историю, но требует аккуратности.

Перебазирование (rebase)

Используйте для поддержания линейной истории. Внимание: Не используйте rebase на ветках, с которыми работают другие люди.

rebase переписывает историю. Если вы уже отправили ветку в общий репозиторий, не используйте rebase — это создаст проблемы коллегам. В таких случаях используйте merge или согласуйте rebase с командой. Если процесс ребейза пошёл не так: практическое руководство по исправлению.

# Переместить коммиты текущей ветки на конец указанной ветки
git rebase <базовая_ветка>

# Начать интерактивное перебазирование (можно переписать, объединить, удалить коммиты)
git rebase -i <базовая_ветка>

# Прервать процесс перебазирования и вернуть всё как было
git rebase --abort

# Продолжить перебазирование после разрешения конфликтов
git rebase --continue

# Пропустить проблемный коммит во время перебазирования
git rebase --skip

Работа с удалёнными ветками

# Показать список всех удалённых веток
git branch -r

# Создать локальную ветку, которая отслеживает удалённую
git checkout -b <локальное_имя> origin/<удалённое_имя>

# Показать связи между локальными и удалёнными ветками
git branch -vv

Разрешение конфликтов

Если при слиянии или перебазировании Git сообщает о конфликте:

  1. Найдите файлы с конфликтами (в них будут маркеры <<<<<<<, =======, >>>>>>>).
  2. Вручную отредактируйте их, оставив нужный код.
  3. Добавьте исправленные файлы в индекс: git add <имя_файла>.
  4. Завершите операцию: git commit (для слияния) или git rebase --continue.

Для глубокого понимания различий: Глубокое понимание merge, rebase, squash и cherry-pick.

Работа с удалёнными репозиториями

Просмотр и подключение удалённых репозиториев

# Показать список удалённых репозиториев (сокращённые имена, обычно origin)
git remote

# Показать список удалённых репозиториев с их URL
git remote -v

# Добавить новый удалённый репозиторий под указанным именем
git remote add <имя> <url>

# Показать детальную информацию об удалённом репозитории
git remote show <имя>

# Изменить URL существующего удалённого репозитория
git remote set-url <имя> <новый_url>

# Удалить ссылку на удалённый репозиторий
git remote remove <имя>

Получение изменений

# Скачать все изменения с удалённого репозитория, но не вливать в локальные ветки
git fetch <имя_удалённого_репозитория>

# Скачать изменения со ВСЕХ удалённых репозиториев
git fetch --all

# Скачать изменения и автоматически удалить ссылки на устаревшие удалённые ветки
git fetch -p

# Получить изменения из конкретной удалённой ветки и влить их в текущую ветку (fetch + merge)
git pull <имя_удалённого_репозитория> <имя_удалённой_ветки>

# Получить изменения и выполнить перебазирование вместо слияния
git pull --rebase <имя_удалённого_репозитория> <имя_удалённой_ветки>

Отправка изменений

# Отправить изменения из локальной ветки в удалённую ветку с тем же именем
git push <имя_удалённого_репозитория> <имя_локальной_ветки>

# Отправить изменения и установить связь для последующих push/pull (удобно при первой отправке)
git push -u <имя_удалённого_репозитория> <имя_локальной_ветки>

# Отправить ВСЕ локальные ветки в удалённый репозиторий
git push <имя_удалённого_репозитория> --all

# Отправить ВСЕ теги в удалённый репозиторий
git push <имя_удалённого_репозитория> --tags

# Принудительно отправить изменения, перезаписав историю на удалённом репозитории (ОПАСНО!)
git push --force <имя_удалённого_репозитория> <имя_локальной_ветки>

Синхронизация и управление удалёнными ветками

# Удалить ветку на удалённом репозитории
git push <имя_удалённого_репозитория> --delete <имя_удалённой_ветки>

# Удалить из локального списка ссылки на ветки, которых уже нет на удалённом репозитории
git remote prune <имя_удалённого_репозитория>

# Показать список удалённых веток, которые уже влиты в текущую локальную ветку
git branch -r --merged

# Показать список удалённых веток, которые НЕ влиты в текущую локальную ветку
git branch -r --no-merged

# Взять за основу локальной ветки конкретную удалённую ветку
git checkout --track <имя_удалённого_репозитория>/<имя_удалённой_ветки>

Просмотр и анализ истории коммитов

Базовый просмотр лога

# Показать историю коммитов в стандартном подробном формате
git log

# Показать историю в сокращённом виде (только хэш и сообщение)
git log --oneline

# Показать историю с визуализацией ветвления
git log --graph

# Показать историю для конкретной ветки
git log <имя_ветки>

Фильтрация и поиск в истории

# Показать коммиты конкретного автора
git log --author="<имя_или_email_автора>"

# Показать коммиты, содержащие изменения в указанном файле
git log -- <путь_к_файлу>

# Показать коммиты, сообщения которых содержат указанную фразу
git log --grep="<фраза_для_поиска>"

# Показать коммиты, созданные после указанной даты
git log --since="2023-01-01"

# Показать коммиты, созданные до указанной даты
git log --until="2023-12-31"

# Показать последние N коммитов
git log -<количество>

Детальный анализ изменений

# Показать историю вместе с изменениями (diff) в каждом коммите
git log -p

# Показать изменения, внесённые конкретным коммитом
git show <хэш_коммита>

# Показать статистику по изменениям файлов в каждом коммите (сколько строк добавлено/удалено)
git log --stat

# Показать, какие файлы изменились в коммите (только имена файлов)
git show <хэш_коммита> --name-only

Пользовательские форматы вывода

Для создания удобочитаемых отчётов или интеграции с другими инструментами.

# Краткий формат с автором и относительной датой
git log --pretty=format:"%h - %an, %ar : %s"

# Формат для последующего парсинга (например, в скрипт)
git log --pretty=format:"%H|%an|%ad|%s" --date=iso

Ключи format:

  • %h — короткий хэш,
  • %H — полный хэш,
  • %an — автор,
  • %ar — относительная дата,
  • %ad — дата,
  • %s — сообщение.

Понятие HEAD — ключевое для работы с историей. Подробнее о том, как работает HEAD в Git.

Работа с тегами

Теги используются для отметки важных точек в истории (например, версий релизов v1.0.0). В отличие от веток, теги не двигаются.

Создание тегов

# Создать легковесный тег на текущем коммите (без дополнительной информации)
git tag <имя_тега>

# Создать аннотированный тег с сообщением, автором и датой (рекомендуется для релизов)
git tag -a <имя_тега> -m "Сообщение для тега"

# Создать тег на указанном коммите
git tag <имя_тега> <хэш_коммита>

Просмотр и сравнение тегов

# Показать список всех тегов в алфавитном порядке
git tag

# Показать информацию об определённом теге (автор, дата, сообщение)
git show <имя_тега>

# Показать список тегов, соответствующих шаблону (например, v1.*)
git tag -l "v1.*"

# Сравнить, что изменилось между двумя тегами
git diff <тег_1>..<тег_2>

Удаление и синхронизация тегов с удалённым репозиторием

# Удалить локальный тег
git tag -d <имя_тега>

# Отправить один тег в удалённый репозиторий
git push <имя_удалённого_репозитория> <имя_тега>

# Отправить ВСЕ локальные теги в удалённый репозиторий
git push <имя_удалённого_репозитория> --tags

# Удалить тег из удалённого репозитория
git push <имя_удалённого_репозитория> --delete <имя_тега>

Временное сохранение изменений (Stash)

Stash (тайник) позволяет временно отложить незакоммиченные изменения, чтобы быстро переключить контекст, не создавая коммитов.

Базовые операции со stash

# Временно сохранить все отслеживаемые изменения и вернуть рабочую директорию к последнему коммиту
git stash

# Сохранить изменения с поясняющим сообщением
git stash push -m "Моё пояснение, что откладываю"

# Показать список всех сохранённых тайников
git stash list

# Применить изменения из последнего тайника и УДАЛИТЬ его из списка
git stash pop

# Применить изменения из последнего тайника, но ОСТАВИТЬ его в списке
git stash apply

# Применить изменения из конкретного тайника (например, stash@{2})
git stash apply stash@{<номер>}

Удаление и просмотр содержимого stash

# Показать, что находится в последнем тайнике (diff)
git stash show

# Показать подробные изменения в конкретном тайнике
git stash show -p stash@{<номер>}

# Удалить последний тайник из списка
git stash drop

# Удалить конкретный тайник
git stash drop stash@{<номер>}

# Удалить ВСЕ тайники
git stash clear

Расширенные сценарии

# Сохранить в stash ВМЕСТЕ с неотслеживаемыми (новыми) файлами
git stash -u

# Создать новую ветку на основе коммита, на который указывает stash, и применить stash
git stash branch <имя_новой_ветки> stash@{<номер>}

Исправление истории и точечное копирование изменений

Внимание: Команды из этого раздела изменяют историю коммитов. Избегайте их использования для коммитов, которые уже были отправлены в общий удалённый репозиторий, если только вы не согласовали это с командой.

Безопасное исправление последнего коммита

# Добавить текущие изменения к предыдущему коммиту и/или изменить его сообщение
git commit --amend
# После выполнения откроется редактор, чтобы изменить сообщение.

💡 Продвинутый приём: Для аккуратного исправления старых коммитов используйте fixup и autosquash.

Отмена изменений (без удаления истории)

# Создать НОВЫЙ коммит, который отменяет изменения указанного коммита
git revert <хэш_коммита>
# Безопасный способ отмены для опубликованной истории.

Перемещение указателя ветки (изменение истории)

# "Жёсткий" сброс: отменить все изменения, вернуть рабочую директорию и историю к указанному коммиту
git reset --hard <хэш_коммита>
# Удалит все незакоммиченные изменения и последующие коммиты. Используйте с крайней осторожностью.

# "Мягкий" сброс: отменить коммиты, но оставить изменения в рабочей директории и индексе
git reset --soft <хэш_коммита>
# Полезно для переделки последних коммитов.

# Сбросить индекс, но оставить изменения в рабочей директории (отменить `git add`)
git reset --mixed <хэш_коммита> # или просто git reset

Точечное применение коммитов (Cherry-Pick)

git cherry-pick — мощный инструмент для переноса отдельных коммитов. Подробное руководство по стратегиям, лучшим практикам и скрытым опасностям cherry-pick.

# Скопировать изменения из указанного коммита и применить их как новый коммит в текущей ветке
git cherry-pick <хэш_коммита>

# Скопировать несколько коммитов подряд (диапазон)
git cherry-pick <начальный_хэш>..<конечный_хэш>

# Скопировать коммит, но НЕ создавать автоматически новый коммит (изменения останутся в индексе)
git cherry-pick -n <хэш_коммита>

Спасение: журнал ссылок (Reflog)

# Показать журнал всех перемещений указателя HEAD (даже после "опасных" команд)
git reflog
# Позволяет восстановить "потерянные" коммиты. Пример: `git reset --hard HEAD@{2}`

Восстановление отдельных файлов (безопасная альтернатива reset для файлов)

# Вместо `git reset --hard HEAD -- <файл>` можно использовать:
git restore --source=HEAD --staged --worktree <файл>

# Вместо `git reset HEAD <файл>`:
git restore --staged <файл>

Для полного руководства по отмене любых действий в Git, включая сложные случаи, обратитесь к циклу статей: Часть 1, Часть 2, Переписывание истории.

Работа с вложенными репозиториями: подмодули (submodules) и поддеревья (subtrees)

  • Подмодули — ссылки на внешние репозитории, хранящиеся как отдельные проекты.
  • Поддеревья — позволяют вставить один репозиторий в подкаталог другого, сохраняя историю.

Основные операции с подмодулями (Submodules)

Как использовать git submodule

# Добавить внешний репозиторий как подмодуль в указанную поддиректорию
git submodule add <url-репозитория> <путь/к/папке>

# Клонировать проект и сразу инициализировать/обновить все его подмодули
git clone --recursive <url-основного-репозитория>

# Инициализировать подмодули в уже клонированном проекте (скачать их)
git submodule init

# Обновить все подмодули до актуальных коммитов, указанных в основном репозитории
git submodule update

# Выполнить команду внутри каждого подмодуля (например, получить обновления)
git submodule foreach git pull

Управление и обновление подмодулей

# Обновить подмодуль до последнего коммита в его ветке (и зафиксировать в основном проекте)
cd <путь/к/подмодулю>
git pull origin main
cd -
git add <путь/к/подмодулю>
git commit -m "Обновлён подмодуль X"

# Удалить подмодуль (несколько шагов)
git submodule deinit -f <путь/к/подмодулю>
git rm -f <путь/к/подмодулю>
# Удалить запись из .gitmodules вручную

Основные операции с поддеревьями (Subtrees)

# Добавить внешний репозиторий как поддерево в указанную поддиректорию
git subtree add --prefix=<путь/к/папке> <url-репозитория> <ветка> --squash

# Получить обновления из внешнего репозитория и влить в поддерево
git subtree pull --prefix=<путь/к/папке> <url-репозитория> <ветка> --squash

# Отправить изменения из поддерева обратно во внешний репозиторий
git subtree push --prefix=<путь/к/папке> <url-репозитория> <ветка>

Обмен изменениями через патчи (patch files)

Патчи (файлы .patch или .diff) — текстовые файлы, описывающие изменения. Удобны для code review, отправки изменений по почте или когда прямой push невозможен.

Создание патчей

# Создать патч для всех незакоммиченных изменений в рабочей директории
git diff > my_changes.patch

# Создать патч, содержащий изменения последнего коммита
git format-patch HEAD~1..HEAD --stdout > last_commit.patch

# Создать серию патчей из нескольких последних коммитов (по одному файлу на коммит)
git format-patch -<количество_коммитов>

Применение патчей

# Применить патч к рабочей директории (без создания коммита)
git apply <файл.patch>

# Применить патч и протестировать, не внося реальных изменений (проверка)
git apply --check <файл.patch>

# Применить патч, созданный командой `format-patch`, с сохранением информации об авторе и коммите
git am <файл.patch>

# Применить все патчи из текущей папки
git am *.patch

Разрешение конфликтов при наложении патчей

# Если `git apply` завершился с конфликтом:
# 1. Вручную разрешите конфликты в файлах.
# 2. Добавьте исправленные файлы: `git add <файлы>`.
# 3. Продолжите применение: `git am --continue`.

# Прервать процесс применения патча
git am --abort

Инструменты для совместной работы и аудита кода

Поиск и анализ кодовой базы

# Найти все файлы, отслеживаемые Git (включая файлы в .gitignore, если они уже добавлены)
git ls-files

# Найти строки, соответствующие шаблону (регулярному выражению), во всех отслеживаемых файлах
git grep -n "шаблон_поиска"

# Показать краткую статистику по коммитам каждого автора (для отчётов)
git shortlog -sn

Подготовка изменений для отправки (Pull Request)

# Сгенерировать текстовое описание изменений между двумя коммитами для отправки коллеге
git request-pull <начальный_коммит> <url-вашего-репозитория>

Отладка и поиск проблем: бисекция и проверка репозитория

Поиск коммита, внёсшего ошибку (бисекция)

Автоматизированный бинарный поиск по истории коммитов.

# Начать процесс бисекции
git bisect start

# Пометить текущий коммит как "плохой" (содержит ошибку)
git bisect bad

# Пометить известный старый коммит как "хороший" (ошибки не было)
git bisect good <хэш_стабильного_коммита>

# Git автоматически переключится на коммит посередине. Протестируйте его:
# Если ошибка ЕСТЬ: `git bisect bad`
# Если ошибки НЕТ: `git bisect good`
# Повторяйте, пока Git не найдёт проблемный коммит.

# Завершить сеанс бисекции и вернуться в исходное состояние
git bisect reset

Для более глубокого изучения, включая продвинутые сценарии, см. обзор git bisect.

Проверка и обслуживание репозитория

# Проверить целостность репозитория (исправность объектов)
git fsck

# Запустить сборку мусора (оптимизация хранилища, удаление лишних объектов)
git gc --auto

# Удалить все неотслеживаемые файлы и папки из рабочей директории (НЕВОССТАНОВИМО!)
git clean -df

Полезные конфигурации и команды для ежедневной работы

Ускорение и кастомизация командной строки

# Включить автокоррекцию опечаток в командах Git (исправляет 'git sttaus' в 'git status')
git config --global help.autocorrect 20

# Настроить пейджер (less) для корректного отображения цветного вывода
git config --global core.pager 'less -RFX'

# Показать все установленные алиасы
git config --get-regexp alias

Просмотр истории и изменений

# Показать историю для одного файла вместе с изменениями (patch)
git log -p -- <путь_к_файлу>

# Красивый графический вывод истории с ветвлением и тегами
git log --oneline --graph --decorate --all

# Быстрый просмотр статистики изменений (сколько файлов и строк изменено)
git diff --stat <хэш_или_ветка>

# Показать дерево файлов и папок на определённом коммите
git ls-tree --name-only -r <хэш_коммита>

Специальные приёмы для сложных сценариев

# Создать пустой коммит (например, для запуска CI/CD или тега)
git commit --allow-empty -m "chore: trigger deployment"

# Выполнить "пробный" merge, чтобы увидеть возможные конфликты, не создавая коммит
git merge --no-commit --no-ff <ветка>

# Сохранить в stash даже неотслеживаемые (новые) файлы
git stash push -u -m "Сообщение"

Комментарии


Дополнительные материалы

Предыдущая Статья

Хуки жизненного цикла в Laravel

Следующая Статья

Vim: Подсчёт вхождений