7 команд в GIT которые реально экономят время и нервы

1. git bisect — быстро находим ломающийся коммит

Допустим, у нас сломался билд после релиза версии v2.0.0. Последняя стабильная версия — v1.2.0. Проблема появилась где-то между ними. В такой ситуации можно искать причину наугад, а можно воспользоваться git bisect. Эта команда использует бинарный поиск, чтобы найти самый первый коммит с багом:

			$ git bisect start
$ git bisect bad v2.0.0
$ git bisect good v1.2.0

# Git переключает вас на промежуточный коммит:
Bisecting: 12 revisions left to test after this (roughly 4 steps)
[9a3c1f2] Рефакторинг работы с токенами

# Проверяем, есть ли баг. Баг не проявился:
$ git bisect good

# Git переключает дальше:
Bisecting: 6 revisions left to test after this (roughly 2 steps)
[d5f8e1a] Добавлен новый парсер конфигов

# Проверяем -- баг появился!
$ git bisect bad

# Повторяем несколько раз…

# В конце Git покажет:
9b2dca4d59f2b9b3a4b6cd3e7ac8f6bcfeaa9876 is the first bad commit
Автор: Иван Петров <ivan@example.com>
Дата:   Tue Jun 18 14:12:07 2024 +0300
		

Мы запускаем git bisect start, далее, при помощи git bisect bad и git bisect good, указываем диапазон коммитов, от нерабочего до стабильного. Git сам начнёт переключать нас между промежуточными версиями. Например, если коммитов 50, то он отправит нас на 25-й.

Далее мы проверяем этот коммит: если баг сохраняется, то отмечаем его как «плохой» с помощью git bisect bad; если баг исчез — отмечаем «хороший» через git bisect good. Git снова разделит диапазон пополам и отправит на следующий коммит для проверки. Так продолжается до тех пор, пока не останется один коммит, который внёс баг.

2. git switch — переключаемся между ветками без checkout

В любой активной разработке приходится прыгать между разными задачами. Раньше для этого использовали git checkout. Команда по возможностям напоминает швейцарский нож: она может не только переключать между ветками, но и заменять файлы, создавать новые ветки и даже возвращать отдельные коммиты. Из-за такой универсальности git checkout часто путает новичков (да и опытных разработчиков тоже), можно легко потерять все изменения из-за случайной ошибки.

В 2019 году в Git появилась отдельная команда — git switch. Она делает ровно одну вещь: быстро и безопасно переключает между ветками или создаёт новую. Ошибиться здесь сложно.

Примеры использования:

			$ git switch feature/new-login
# Перешли на ветку для проверки новой фичи

$ git switch -
# Вернулись обратно на предыдущую ветку (например, багфикс)

$ git switch -c hotfix/urgent-redirect
# Создали новую ветку и сразу перешли в неё
		

В этом примере мы сначала быстро переключаемся на ветку «new-login» с новой фичей, чтобы что-то проверить, а потом одной командой возвращаемся обратно — продолжать багфикс. Если появляется ещё одна срочная задача, заводим для неё отдельную ветку «urgent-redirect» с помощью -c и сразу попадаем в нужное место.

Такой подход экономит время и избавляет от путаницы, которая раньше возникала с многофункциональным git checkout.

3. git restore — откатываем изменения для конкретных файлов

Допустим, мы внесли кучу изменений, что-то пошло не так — и хочется вернуть всё обратно, но только для определённых файлов. Использовать git reset или checkout слишком рискованно: легко случайно стереть не то, что нужно. В таких случаях пригодится команда git restore.

Она работает как с рабочей директорией, так и с индексом, не затрагивая остальной проект.

Примеры использования:

			git restore main.c
# Вернуть файл main.c к состоянию последнего коммита

git restore --staged *.js
# Убрать файлы из индекса, но оставить изменения в рабочей директории

git restore --source=HEAD~1 --worktree .
# Откатить все файлы к предыдущему коммиту (HEAD~1)
		

В первом случае файл main.c возвращается к состоянию последнего коммита. Во втором мы убираем из индекса все файлы с расширением .js, но наши изменения остаются в рабочей директории. Третий вариант позволяет вернуть все файлы к состоянию предыдущего коммита, если, например, мы случайно наделали лишних изменений во всём проекте.

4. git rebase — приводим историю в порядок

Иногда хочется привести историю коммитов в порядок: объединить случайные правки, переименовать сообщения и т. д. Команда git rebase -i открывает текстовый интерфейс, где можно управлять списком последних коммитов:

• Объединять несколько в один (squash),
• Менять порядок (pick),
• Редактировать сообщения (reword),
• Вставлять дополнительные команды (exec).

Примеры использования:

			git rebase -i HEAD~3
		

Git откроет в редакторе список из последних трёх коммитов, там будет указан их хэш и комментарий:

			pick 0a1b2c3 Исправил баг с авторизацией
pick 1d2e3f4 Добавил логирование ошибок
pick 2g3h4j5 Убрал лишний console.log
		

Мы можем перетасовать коммиты при помощи команды pick, в этом примере мы поменяли верхний и нижний коммиты местами:

			pick 2g3h4j5 Убрал лишний console.log
pick 1d2e3f4 Добавил логирование ошибок
pick 0a1b2c3 Исправил баг с авторизацией
		

Если хотим объединить второй коммит с предыдущим, то можем использовать команду squash:

			pick 0a1b2c3 Исправил баг с авторизацией
squash 1d2e3f4 Добавил логирование ошибок
pick 2g3h4j5 Убрал лишний console.log
		

Теперь оба изменения попадут в один коммит.

Чтобы изменить сообщение у последнего коммита, меняем pick на reword:

			reword 2g3h4j5 Убрал лишний console.log
		

После этой команды git предложит ввести новый текст комментария.

Таким образом, за одну операцию можно собрать историю под ключ: объединить, переименовать, проверить — и только потом отправить в общий репозиторий аккуратную, читаемую цепочку коммитов. Однако не рекомендуется использовать git rebase для командной работы, так как стирание истории может запутать других разработчиков и привести к конфликтам в разных версиях проекта.

5. git stash — прячем незаконченные правки, чтобы вернуться к ним позже

Бывает, что срочно нужно переключиться на другую задачу или ветку, но текущие изменения ещё не готовы к коммиту. Не хочется захламлять историю, да и откладывать задачу опасно — можно забыть, где остановился. Для этого в Git есть команда git stash, которая убирает все незавершённые правки «под ковёр» до лучших времён.

Пример использования:

			$ git stash save "WIP: Исправление ошибки авторизации"
# Сохранили изменения с описанием, чтобы не забыть, что там было

$ git stash list
# stash@{0}: On feature/auth: WIP: Исправление ошибки авторизации
# stash@{1}: On main: Начало новой фичи

$ git stash apply stash@{0}
# Применили последние сохранённые изменения

$ git stash pop
# Применили и удалили последние сохранённые изменения
		

В первом примере мы сохраняем все незакоммиченные изменения при помощи git stash save, давая им осмысленное имя. Так мы сможем вернуться к правкам позже.

Команда git stash list показывает все «стеши» — сохранённые правки, которые нам надо применить.

git stash apply возвращает изменения в рабочую директорию, но не удаляет стеши из списка. Ещё есть git stash pop, который делает то же самое, но сразу удаляет стеши.

6. git cherry-pick — добавляем только нужные коммиты

Иногда в соседней ветке уже есть нужный багфикс или маленькая фича, а добавлять её всю не хочется — появится куча лишних изменений. Для таких случаев подходит git cherry-pick: эта команда позволяет взять конкретный коммит (или диапазон коммитов) и аккуратно «приземлить» его в свою ветку.

Примеры использования:

			git cherry-pick f1a2b3c        # применить один коммит
git cherry-pick 1a..4d         # применить все коммиты между 1a и 4d (без первого)
git cherry-pick --continue     # продолжить после решения конфликтов
		

Сначала мы применяем команду git cherry-pick, после которой указываем хэш нужного коммита (например, f1a2b3c). Git найдёт этот коммит в истории и «применит» его изменения к текущей ветке — как будто мы только что их закоммитили сами.

Если нужно забрать сразу несколько коммитов, можно указать диапазон через две точки «..» как в примере: git cherry-pick 1a..4d. Важно: команда возьмёт все коммиты после 1a, но не сам 1a.

Иногда при cherry-pick возникают конфликты — это нормально. В таком случае Git попросит разрешить эти конфликты вручную. После того как это сделано, мы можем ввести команду git cherry-pick --continue, чтобы продолжить слияние.

7. git log — визуализируем историю проекта

Когда в проекте появляется несколько веток и десятки коммитов, обычный просмотр истории быстро превращается в путаницу. В такие моменты помогает визуализация истории — чтобы увидеть, где расходились ветки, когда были слияния, и где появился тот самый «пропавший» коммит.

В Git для этого есть команда:

			git log --graph --decorate --oneline --all
		

• --graph рисует дерево истории с линиями, которое показывает, где ветки расходятся и сливаются.
• --decorate подписывает ветки и теги прямо в выводе, чтобы сразу было видно, где «main», «feature», релиз.
• --oneline делает вывод лаконичным: каждая запись — одна строка, только хеш и короткое описание.
• --all показывает не только текущую ветку, но и всю историю репозитория.

Писать эту команду неудобно, она слишком длинная, поэтому мы можем создать алиас — короткую версию:

			git config --global alias.graph "log --graph --decorate --oneline --all"
		

Теперь, чтобы команда сработала, достаточно применить git graph.

Например, если у нас две ветки, которые разошлись, а потом слились, мы увидим вот такой граф:

			*   8c1a5df (HEAD -> main, tag: v1.0) Merge branch 'feature/login'
|\
| * a7e893f (feature/login) Добавил страницу логина
| * 43c1c11 Фикс ошибок авторизации
* | 1fbb2e7 Верстка главной страницы
* | e3e13aa Первый рабочий коммит
|/
* 12ab7cd Инициализация проекта
		

Звёздочки и линии показывают, где расходились ветки (feature/login отделялась от main), а где обратно слились (Merge).

Метки (например, main, feature/login, tag: v1.0) появляются рядом с коммитами — это и есть результат --decorate.

Все коммиты выстроены по одной строке — это делает схему быстрой для чтения.

Заключение

Освоить Git — значит не просто выучить базовые команды, а знать, как быстро решить типовые проблемы и не тратить время на рутину. Даже одна «правильная» команда может в нужный момент сэкономить время и нервы. А какие команды-git вы используете чаще всего? Напишите в комментариях. Кто знает, может в следующий раз именно ваша подборка появится в будущих материалах.