Быстрая навигация: что искать по ситуации
Для новичков:
Для командной работы:
Продвинутые сценарии:
Самые частые задачи:
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 сообщает о конфликте:
- Найдите файлы с конфликтами (в них будут маркеры
<<<<<<<,=======,>>>>>>>). - Вручную отредактируйте их, оставив нужный код.
- Добавьте исправленные файлы в индекс:
git add <имя_файла>. - Завершите операцию:
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 "Сообщение"