Git для разработчика: команды на каждый день для работы с кодом

Введение

Git — это инструмент, без которого современная разработка невозможна. Каждый день вы коммитите изменения, переключаетесь между ветками, разрешаете конфликты и синхронизируете код с командой. Но многие разработчики используют лишь малую часть возможностей Git, ограничиваясь add, commit и push.

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

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

Начнём с того, что вы уже знаете, но добавим полезные флаги.

# Посмотреть состояние рабочей директории
git status -s

# Добавить все изменения, включая удалённые файлы
git add -A

# Коммит с сообщением одной командой
git commit -m "feat: добавить авторизацию через OAuth"

# Изменить последний коммит (если ещё не запушен)
git commit --amend --no-edit

Флаг -s для status показывает компактный вывод: M — изменён, A — добавлен, ?? — не отслеживается. Это удобнее громоздкого стандартного вывода.

--amend --no-edit пригодится, если забыли добавить файл в последний коммит — добавьте его через git add и выполните команду без изменения сообщения.

Работа с ветками

Ветки — основа командной разработки. Вот команды, которые должны быть на автомате.

# Создать ветку и сразу переключиться
git switch -c feature/user-profile

# Переключиться на существующую ветку
git switch main

# Удалить локальную ветку
git branch -d feature/old-stuff

# Принудительно удалить (даже если не смержена)
git branch -D feature/experiment

# Посмотреть все ветки, включая удалённые
git branch -a

Команда switch появилась как замена устаревшему checkout для работы с ветками. Используйте её — это безопаснее, потому что checkout делает слишком много разных вещей.

Stash: временное хранилище изменений

Классическая ситуация: работаете над фичей, прилетает срочный баг. Коммитить полуготовый код не хочется — на помощь приходит stash.

# Спрятать текущие изменения
git stash push -m "работа над формой регистрации"

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

# Применить последний stash и удалить из списка
git stash pop

# Применить, но оставить в списке
git stash apply stash@{0}

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

Совет: всегда давайте описание через -m, иначе через неделю не вспомните, что там лежит.

Откат изменений

Наверное, самая страшная для новичков часть Git. На самом деле всё просто.

# Отменить изменения в файле (до git add)
git restore src/app.ts

# Убрать файл из индекса (после git add)
git restore --staged src/app.ts

# Откатить последний коммит, оставив изменения в рабочей директории
git reset --soft HEAD~1

# Откатить коммит и убрать изменения из индекса
git reset --mixed HEAD~1

# Полностью удалить последний коммит со всеми изменениями
git reset --hard HEAD~1

# Создать новый коммит, отменяющий указанный
git revert abc1234

Разница между reset и revert принципиальна. reset переписывает историю — нельзя использовать на запушенных коммитах. revert создаёт новый коммит с обратными изменениями — безопасно для общих веток.

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

# Получить изменения с сервера, но не применять
git fetch origin

# Получить и слить с текущей веткой
git pull --rebase origin main

# Запушить ветку с установкой upstream
git push -u origin feature/new-api

# Принудительный push с защитой от перезаписи чужих коммитов
git push --force-with-lease

Флаг --rebase для pull избавляет от мусорных merge-коммитов в истории. А --force-with-lease вместо обычного --force проверит, не появились ли новые коммиты в удалённой ветке — спасёт от случайной перезаписи работы коллеги.

Rebase и интерактивная история

Rebase позволяет переписать историю коммитов перед merge в основную ветку.

# Перенести коммиты текущей ветки поверх main
git rebase main

# Интерактивный rebase последних 3 коммитов
git rebase -i HEAD~3

В интерактивном режиме можно объединять коммиты (squash), менять сообщения (reword), удалять (drop) и менять порядок. Это must-have перед открытием pull request — превращает кашу из мелких коммитов в чистую историю.

Поиск и анализ

# Кто и когда менял каждую строку файла
git blame src/utils.ts

# Найти коммит, в котором появилась строка
git log -S "calculateTotal" --source --all

# Бинарный поиск коммита, сломавшего код
git bisect start
git bisect bad HEAD
git bisect good v1.2.0

git bisect — недооценённая команда. Когда не знаете, какой коммит сломал тесты, она автоматически делает бинарный поиск по истории.

Cherry-pick

Перенос конкретного коммита из одной ветки в другую.

# Применить коммит на текущую ветку
git cherry-pick abc1234

# Применить несколько коммитов
git cherry-pick abc1234 def5678

Полезно, когда нужно срочно перенести фикс из develop в release-ветку, не сливая остальные изменения.

Частые ошибки

Использование git push --force на общих ветках. Это перезатрёт работу коллег. Всегда применяйте --force-with-lease и только на своих feature-ветках.

Коммит больших файлов и секретов. Удалить их из истории сложно — потребуется git filter-repo и форс-пуш. Настройте .gitignore сразу и используйте инструменты вроде git-secrets.

Бесконечные merge-коммиты в истории. Если каждый pull создаёт коммит вида «Merge branch main» — настройте git config --global pull.rebase true.

Работа в ветке main напрямую. Даже на пет-проектах заведите привычку создавать feature-ветки. Это упростит откат и code review.

Игнорирование .gitignore. Перед первым коммитом в новом проекте всегда проверяйте, что node_modules, .env и build-артефакты исключены.

Заключение

Git — это не магия, а набор простых инструментов, которые становятся естественным продолжением рабочего процесса. Команды из этой статьи покрывают 95% задач, с которыми сталкивается разработчик ежедневно.

Главный совет: не бойтесь экспериментировать в учебном репозитории. Сломать что-то локально невозможно — даже после reset --hard коммиты остаются в git reflog ещё 30 дней. Освойте rebase -i, stash и cherry-pick — и ваша продуктивность вырастет в разы, а pull request'ы станут чище и понятнее для ревьюеров.