📦 Как извлечь один файл из другого коммита? (Git Checkout/Restore)

Бывает, что ты случайно удалил важный файл пару дней назад или так сильно его переписал, что проще вернуться к старой версии. При этом тебе не нужно откатывать весь проект — нужен только один конкретный файл.

Задача:
— Вернуть файл из старого коммита в текущую рабочую директорию.
— Скопировать версию файла из другой ветки, не переключаясь на неё.

Решение:

Раньше для этого использовали checkout, но в новых версиях Git рекомендуется restore с указанием источника (source):

# Восстановить файл из конкретного коммита
git restore --source <hash_коммита> path/to/file.js

# Забрать файл из другой ветки (например, из main)
git restore --source main path/to/file.js

# Если привык к старой школе:
git checkout <hash_коммита> -- path/to/file.js

Почему это удобно?
— Точечность: ты меняешь только то, что нужно, не затрагивая остальной код.
— Скорость: не надо искать файл в истории вручную и копипастить содержимое.
— Безопасность: файл попадает в рабочую зону, и ты можешь проверить его перед коммитом.

Это отличный способ быстро исправить ошибки рефакторинга или вернуть случайно удаленные ассеты и документацию.

🔥 — если часто «грабишь» старые коммиты
🤝 — если просто отменяешь изменения через Ctrl+Z

➡️ GitHub Ready | #урок

📋 Как узнать, кто написал эту строку? (Git Blame)

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

Задача:
— Определить автора конкретной строки кода.
— Найти коммит, в котором было внесено изменение.
— Понять дату и время правки.

Решение:

Используем команду blame, которая выводит содержимое файла с аннотациями для каждой строки:

# Показать автора и коммит для каждой строки файла
git blame path/to/file.txt

# Если файл слишком большой, можно ограничить диапазон строк
git blame -L 10,20 path/to/file.txt

# Чтобы игнорировать изменения, связанные только с пробелами (рефакторинг)
git blame -w path/to/file.txt

Почему это важно?
— Коммуникация: ты сразу видишь, к кому из коллег пойти за пояснениями.
— Контекст: по хэшу коммита можно найти задачу в Jira или описание в Pull Request.
— История: помогает отследить, как менялась логика файла со временем.

Совет: Если тебе нужно посмотреть историю строки, которая уже была удалена, лучше использовать git log -S (тот самый поиск-кирку), о котором мы говорили раньше.

🔥 — если постоянно «блеймишь» коллег (или себя)
🤝 — если просто переписываешь код, не спрашивая

➡️ GitHub Ready | #урок

🧹 Как очистить проект от лишнего мусора? (Git Clean)

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

Задача:
— Быстро удалить все файлы, которые не входят в репозиторий (untracked files).
— Очистить проект от мусора перед сборкой или переключением контекста.

Решение:

Команда clean работает довольно жестко, поэтому у неё есть «предохранитель». Она не сработает без флагов:

# 1. Сначала всегда делай "сухой прогон" (покажет, что будет удалено)
git clean -n

# 2. Удалить все неотслеживаемые файлы
git clean -f

# 3. Удалить файлы вместе с пустыми папками
git clean -fd

# 4. Удалить даже те файлы, которые прописаны в .gitignore
git clean -fdx

Почему это полезно?
— Чистота: ты уверен, что никакие старые артефакты сборки не влияют на текущий код.
— Скорость: одна команда заменяет ручной поиск и удаление файлов через проводник.
— Надежность: это лучший способ привести репозиторий в «заводское» состояние без удаления самой папки .git.

Важно: Помни, что git clean удаляет файлы безвозвратно. Если файл не был закоммичен, reflog его не спасет. Всегда используй флаг -n перед окончательным удалением.

🔥 — если любишь идеальный порядок в папках
🤝 — если годами хранишь test_1.js и logs.txt в корне проекта

➡️ GitHub Ready | #урок

🌀 Как объединить несколько коммитов в один? (Git Squash)

Иногда в процессе работы над фичей получается гора мелких коммитов типа «fix», «typo» или «test». Чтобы не пугать коллег грязной историей в общем репозитории, их лучше объединить в один логичный и красивый коммит перед слиянием.

Задача:
— Схлопнуть цепочку мелких правок в одну осмысленную запись.
— Сделать историю проекта чистой и понятной для чтения.

Решение:

Самый гибкий способ — это интерактивный ребейз (interactive rebase).

# 1. Запускаем интерактивный режим для последних N коммитов (например, 3)
git rebase -i HEAD~3

# 2. В открывшемся текстовом редакторе ты увидишь список коммитов.
# Замени слово 'pick' на 'squash' (или просто 's') у тех коммитов, 
# которые хочешь присоединить к предыдущему:

pick a1b2c3d Добавил логику входа
squash b2c3d4e Исправил опечатку в логине
squash c3d4e5f Добавил тесты для валидации

# 3. Сохрани и закрой файл. Git предложит отредактировать 
# итоговое сообщение для объединенного коммита.

Почему это важно?
— Читаемость: в истории остаются только важные этапы разработки.
— Удобство отката: если фича сломала билд, её можно отменить одним revert, а не искать все 20 мелких правок.
— Профессионализм: чистый Git-лог — признак высокого качества работы над проектом.

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

🔥 — если всегда делаешь squash перед мержем
🤝 — если оставляешь историю как есть, «для истории»

➡️ GitHub Ready | #урок

📋 Как перенести один коммит в другую ветку? (Git Cherry-pick)

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

Задача:
— Скопировать один конкретный коммит и применить его в текущей ветке.
— Избежать полного слияния (merge) веток.

Решение:

Для этого существует команда «выбора вишенки» — cherry-pick. Она берет изменения из указанного коммита и создает их точную копию в твоей ветке.

# 1. Перейди в ветку, куда хочешь добавить изменения
git checkout main

# 2. Примени нужный коммит по его хэшу
git cherry-pick a1b2c3d

# Если возникли конфликты — исправь их и продолжи:
git add .
git cherry-pick --continue

Почему это удобно?
— Точечность: ты переносишь только то, что действительно нужно.
— Гибкость: можно забирать коммиты из любой ветки, даже если они еще не влиты в общий поток.
— Чистота: история текущей ветки не засоряется лишними изменениями из соседних веток.

Важно: Помни, что cherry-pick создает новый коммит с новым хэшем. Если ты потом решишь слить ветки целиком, Git поймет, что эти изменения уже есть, и не будет создавать дублей (в большинстве случаев).

🔥 — если часто «воруешь» коммиты из соседних веток
🤝 — если предпочитаешь честный merge или rebase

➡️ GitHub Ready | #урок

📥 Как временно спрятать изменения? (Git Stash)

Бывает, что ты в самом разгаре работы над фичей, код сломан и не компилируется, но тут прилетает срочный баг-репорт. Нужно быстро переключиться на другую ветку, но Git не дает этого сделать, пока у тебя есть незакоммиченные правки.

Задача:
— Быстро убрать текущие изменения «в карман», не делая грязных коммитов.
— Очистить рабочую директорию для переключения веток.
— Вернуть изменения позже, когда разберешься с багом.

Решение:

Используем команду stash, которая сохраняет текущее состояние в специальный временный стек.

# 1. Спрятать все текущие изменения (включая индекс)
git stash

# 2. Дать заначке имя, чтобы не запутаться (рекомендуется)
git stash save "Работа над валидацией форм"

# 3. Посмотреть список всех отложенных правок
git stash list

# 4. Вернуть последние изменения и удалить их из стека
git stash pop

# 5. Применить изменения, но оставить их в стеке (на всякий случай)
git stash apply stash@{0}

Почему это удобно?
— Чистая история: тебе не нужно плодить коммиты вроде "temp" или "wip".
— Мобильность: заначку можно «вывалить» даже на другую ветку, если ты начал писать код не там, где нужно.
— Безопасность: ты всегда можешь откатиться к чистому состоянию ветки за одну секунду.

Важно: По умолчанию stash не берет новые (untracked) файлы. Чтобы спрятать и их, добавь флаг -u.

🔥 — если stash — твой лучший друг в экстренных ситуациях
🤝 — если предпочитаешь делать временные коммиты

➡️ GitHub Ready | #урок

🏷️ Как работать с тегами в Git? (Git Tags)

Когда проект доходит до важного этапа — например, релиза версии 1.0 — простого коммита недостаточно. Чтобы быстро находить такие точки в истории, используются теги. Это своего рода «закладки» на конкретных моментах времени.

Задача:
— Зафиксировать версию проекта.
— Создать удобную навигацию по релизам.
— Отметить важные вехи разработки.

Решение:

Теги бывают легковесными (просто указатель) и аннотированными (полноценный объект с автором и датой). Лучше всегда использовать аннотированные.

# Создать аннотированный тег для текущего коммита
git tag -a v1.0.0 -m "Релиз первой стабильной версии"

# Создать тег для коммита, который был в прошлом (по хэшу)
git tag -a v0.9.5 5f3a2b1

# Отправить теги на сервер (обычный push их не переносит)
git push origin v1.0.0
# Или отправить сразу все локальные теги
git push origin --tags

# Посмотреть список всех тегов
git tag -l

Почему это удобно?
— Стандартизация: теги позволяют легко интегрироваться с системами сборки и авто-релизами на GitHub/GitLab.
— Навигация: вместо того чтобы искать хэш коммита в логах, ты просто переключаешься на v2.1.0.
— Долговечность: в отличие от веток, теги не меняются и всегда указывают на один и тот же коммит.

Если тебе нужно скачать код конкретной версии, ты можешь просто сделать git checkout v1.0.0. Git перейдет в состояние "detached HEAD", что идеально подходит для сборки проекта.

🔥 — если помечаешь каждый релиз тегом
🤝 — если ориентируешься только по датам коммитов

➡️ GitHub Ready | #урок

Обратная сторона Windows 😂

➡️ GitHub Ready | #урок

🔍 Как найти коммит по сообщению? (Git Log Grep)

Бывает, что ты помнишь: месяц назад кто-то фиксил баг с авторизацией или добавлял интеграцию со Stripe. Ты не помнишь ни хэша, ни ветки, ни точной даты. Листать git log вручную — задача для очень терпеливых. Но в Git есть встроенный поиск по сообщениям.

Задача:
— Быстро найти все коммиты, в описании которых есть ключевое слово.
— Отфильтровать историю по конкретной задаче из Jira или Trello.

Решение:

Используем команду log с флагом --grep:

# Найти все коммиты, где в описании упоминается "auth"
git log --grep="auth"

# Искать без учета регистра (Auth, AUTH, auth)
git log -i --grep="auth"

# Поиск по нескольким словам (найдет коммиты, где есть либо "fix", либо "bug")
git log --grep="fix" --grep="bug"

# Показать только хэш и первую строку сообщения для компактности
git log --grep="stripe" --oneline

Почему это полезно?
— Экономия времени: поиск по тысячам коммитов занимает доли секунды.
— Восстановление контекста: можно быстро найти задачу и посмотреть, какие файлы тогда менялись.
— Аудит: легко проверить, сколько раз за проект фиксили одну и ту же проблему.

Совет: Если ты ищешь не в сообщении, а в самом коде (кто вписал это слово в файл?), используй git grep "слово". А если нужно найти, когда это слово *появилось* или *исчезло* из кода — используй «поиск-кирку»: git log -S "слово".

🔥 — если пользуешься поиском чаще, чем скроллом
🤝 — если ищешь коммиты через поиск в браузере на GitHub

➡️ GitHub Ready | #урок

🕵️ Как найти, где в коде появилось или исчезло слово? (Git Log -S)

Обычный grep ищет слово в текущем состоянии файлов. Но что делать, если функция была удалена месяц назад, и ты даже не помнишь, в каком файле она находилась? Или тебе нужно найти момент, когда в проект добавили конкретный API-ключ?

Задача:
— Найти все коммиты, в которых количество упоминаний строки изменилось (добавили или удалили).
— Отследить судьбу конкретной переменной или метода через всю историю проекта.

Решение:

Используем так называемый «поиск-кирку» (pickaxe search) с флагом -S:

# Найти коммиты, где добавляли или удаляли строку "calculateTotal"
git log -S "calculateTotal"

# Посмотреть сразу с изменениями кода (diff) внутри найденных коммитов
git log -S "calculateTotal" -p

# Если нужно найти строку по регулярному выражению
git log -G "api_key_[0-9]+"

Почему это круто?
— Археология: ты можешь найти код, которого больше нет ни в одной ветке.
— Расследование: легко понять, кто и зачем удалил ту самую «важную проверку», из-за которой всё упало.
— Скорость: Git просматривает историю изменений, а не сканирует каждый файл целиком, что гораздо быстрее.

Важно: Флаг -S сработает только если количество упоминаний строки изменилось. Если ты просто перенес строку из одного места в другое внутри того же коммита, используй -G.

🔥 — если чувствуешь себя детективом, используя -S
🤝 — если просто ищешь по файлам через VS Code

➡️ GitHub Ready | #урок

⏱ Как узнать, на что уходит время? (Git Log --since)

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

Задача:
— Выгрузить список задач, сделанных за конкретный спринт.
— Посмотреть, какие правки вносились в проект с момента последнего релиза.

Решение:

Используем флаги --since (с тех пор) и --until (до тех пор). Git понимает даже человекоподобные форматы дат:

# Показать коммиты за последние две недели
git log --since="2 weeks ago"

# Посмотреть, что было сделано с начала вчерашнего дня
git log --since="yesterday"

# Выгрузить активность за конкретный период (например, за прошлый месяц)
git log --since="2026-02-01" --until="2026-02-28" --oneline

# Коммиты конкретного автора за последнюю неделю
git log --since="1 week ago" --author="Ivan"

Почему это удобно?
— Отчетность: пара секунд, и у тебя готов список всех закрытых тикетов для дейлика или ретро.
— Аналитика: можно быстро оценить интенсивность разработки в разные периоды проекта.
— Чистота: ты не отвлекаешься на старый код и видишь только актуальный контекст.

Совет: Если добавить флаг --no-merges, Git скроет технические коммиты о слиянии веток, и в списке останутся только твои реальные изменения.

🔥 — если используешь это для отчетов
🤝 — если каждый раз мучительно вспоминаешь, что делал в понедельник

➡️ GitHub Ready | #урок

📊 Как получить статистику по репозиторию? (Git Shortlog)

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

Задача:
— Быстро посчитать количество коммитов каждого автора.
— Сгруппировать сообщения для отчета или анализа активности.

Решение:

Команда shortlog создана специально для обобщения истории. Она группирует коммиты по авторам и выводит их в алфавитном порядке.

# Показать авторов и заголовки их коммитов
git shortlog

# Вывести только количество коммитов для каждого автора (summary)
git shortlog -s

# Отсортировать список по количеству коммитов (от самых активных к менее)
git shortlog -s -n

# Посмотреть статистику только за последнюю неделю
git shortlog -s -n --since="1 week ago"

Почему это полезно?
— Аналитика: сразу видно, кто «владеет» кодовой базой или кто активнее всех участвует в спринте.
— Подготовка релизов: флаг -s помогает быстро составить список контрибьюторов для Changelog.
— Оценка нагрузки: если один человек делает 90% коммитов, возможно, стоит перераспределить задачи.

Совет: Если один и тот же человек отображается под разными именами (например, из-за разных конфигов на домашнем и рабочем ПК), это можно исправить с помощью файла .mailmap в корне проекта.

🔥 — если следишь за статистикой команды
🤝 — если тебе не важно количество, главное — качество

➡️ GitHub Ready | #урок

🔍 Как найти коммит, в котором изменилась конкретная функция? (Git Log -L)

Мы уже разбирали, как искать по строкам, но что если тебе нужно отследить эволюцию целого метода или функции? Файлы могут меняться, строки сдвигаться, но Git умеет «привязываться» именно к логическому блоку кода.

Задача:
— Посмотреть историю изменений только одной функции, не отвлекаясь на остальной файл.
— Найти момент, когда в логику метода закралась ошибка.

Решение:

Используем флаг -L. Он позволяет указать имя функции и файл, в котором она находится. Git сам поймет, где она начинается и заканчивается.

# Синтаксис: git log -L :имя_функции:путь_к_файлу
git log -L :calculateTotal:src/utils/cart.js

# Если нужно отследить конкретный диапазон строк (например, с 15 по 30)
git log -L 15,30:src/utils/cart.js

Почему это эффективнее обычного лога?
— Фокус: ты видишь только те коммиты, которые реально затронули код внутри этой функции.
— Наглядность: Git сразу показывает diff (разницу) для каждого изменения, так что ты видишь, как трансформировались аргументы или условия.
— Интеллект: даже если ты переименовал файл или передвинул функцию выше по коду, Git (в большинстве случаев) не потеряет след.

Это незаменимый инструмент для рефакторинга: прежде чем переписывать старый метод, посмотри, через какие «боли» он прошел за последние полгода.

🔥 — если копаешь историю до самого основания
🤝 — если просто смотришь последний коммит через аннотации в IDE

➡️ GitHub Ready | #урок

🚦 Как проверить, какие коммиты есть в одной ветке, но нет в другой? (Git Log A..B)

Частая ситуация перед мержем: тебе нужно понять, что именно ты сейчас собираешься влить из feature-ветки в main. Или наоборот — хочешь проверить, насколько твоя локальная ветка отстала от сервера.

Задача:
— Увидеть список изменений, которые есть в «источнике», но отсутствуют в «цели».
— Убедиться, что в ветку не попало ничего лишнего перед отправкой Pull Request.

Решение:

Используем синтаксис «двух точек» (..). Это мощный фильтр, который показывает разницу в истории между двумя указателями.

# Показать коммиты, которые есть в feature-branch, но нет в main
git log main..feature-branch

# Самый частый кейс: что я накодил относительно мастера?
git log master..HEAD --oneline

# Что нового появилось на сервере, чего у меня еще нет?
# (После git fetch)
git log HEAD..origin/main

# Если хочешь посмотреть не только список, но и сам код
git log -p main..feature-branch

Почему это важно?
— Безопасность: ты точно видишь дельту изменений и не принесешь в проект «сюрпризов».
— Скорость ревью: ты можешь сам быстро пробежаться по своим коммитам и поправить сообщения или код до того, как их увидит команда.
— Понимание: это лучший способ визуализировать разрыв между ветками без использования сложных GUI-клиентов.

Совет: Если использовать три точки (A...B), Git покажет коммиты, которые есть в любой из этих веток, но отсутствуют в их общем предке (симметрическая разность). Это помогает понять, насколько сильно разошлись пути двух разработчиков.

🔥 — если всегда проверяешь дифф перед мержем
🤝 — если доверяешь кнопке "Merge" на GitHub

➡️ GitHub Ready | #урок

🌳 Как увидеть дерево проекта прямо в консоли? (Git Log --graph)

Когда в проекте работают десятки людей и создаются сотни веток, обычный список коммитов превращается в бесконечную ленту, в которой невозможно разобраться. Чтобы понять, кто от кого отпочковался и где произошел мерж, нужно визуальное дерево.

Задача:
— Посмотреть структуру веток и их пересечения без использования тяжелых GUI-клиентов.
— Понять, на каком этапе ветки разошлись и где они слились воедино.

Решение:

Используем комбинацию флагов для построения текстового графа. Это выглядит олдскульно, но максимально информативно.

# Базовая команда для отрисовки дерева
git log --graph --oneline --all

# "Золотой стандарт" alias (красиво и с цветами):
git log --graph --pretty=format:'%C(auto)%h %C(magenta)%ad %C(cyan)%an %C(auto)%d %s' --date=short --all

Почему это удобно?
— Наглядность: ты видишь «щупальца» веток и точки их слияния (merge commits).
— Скорость: не нужно открывать GitKraken или Sourcetree, чтобы быстро прикинуть состояние репозитория.
— Контроль: сразу заметно, если кто-то забыл сделать rebase или наплодил лишних мержей.

Разбор флагов:
— --graph — рисует текстовую схему слева.
— --oneline — компактно умещает один коммит в одну строку.
— --all — показывает вообще все ветки (и локальные, и удаленные), а не только текущую.
— --decorate — подсвечивает названия веток и теги рядом с коммитами.

🔥 — если твой терминал всегда выглядит как матрица
🤝 — если предпочитаешь смотреть граф в GitHub Desktop

➡️ GitHub Ready | #урок

⌨️ Как ускорить работу с Git? (Git Aliases)

Если тебе надоело каждый раз вводить длинные команды вроде git log --graph --oneline --all, пришло время настроить алиасы. Это короткие псевдонимы, которые экономят время и превращают работу в терминале в удовольствие.

Задача:
— Сократить часто используемые команды до 2–3 букв.
— Создать свои собственные «супер-команды» со сложными флагами.
— Перестать ошибаться в длинных словах типа checkout.

Решение:

Алиасы прописываются в глобальном конфиге Git. Вот самые полезные сокращения, которыми пользуются профи:

# Настройка через терминал:
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status

# Создаем крутой лог-граф одной командой 'git lg'
git config --global alias.lg "log --graph --oneline --all --decorate"

# Чтобы быстро отменить последний коммит, но оставить код (uncommit)
git config --global alias.uncommit "reset --soft HEAD~1"

Почему это маст-хэв?
— Скорость: git st вместо git status — это доли секунды, которые за день складываются в минуты продуктивности.
— Кастомизация: ты настраиваешь инструмент под свои привычки.
— Меньше опечаток: короткую команду сложнее написать с ошибкой.

Как проверить свои алиасы?
Все твои настройки хранятся в файле ~/.gitconfig. Ты можешь открыть его любым редактором и отредактировать секцию [alias] вручную.

🔥 — если твой конфиг уже забит алиасами
🤝 — если по старинке пишешь команды целиком

➡️ GitHub Ready | #урок

📋 Как изменить сообщение последнего коммита? (Git Commit --amend)

Ошибки в описании — классика: опечатался, забыл указать номер задачи или просто понял, что «Fix» — это не самое информативное сообщение в мире. Если ты еще не запушил этот коммит в общий репозиторий, всё можно исправить за пару секунд.

Задача:
— Отредактировать текст последнего коммита.
— Добавить забытый файл в тот же самый коммит, не создавая новый.

Решение:

Используем флаг --amend. Эта команда берет текущую стадию (staging area) и «склеивает» её с последним коммитом, позволяя заодно переписать сообщение.

# Если нужно только изменить текст сообщения:
git commit --amend -m "Новое правильное сообщение"

# Если забыл добавить файл:
git add forgotten_file.js
git commit --amend --no-edit
# Флаг --no-edit оставит прежнее сообщение, просто добавив файл

Почему это важно?
— Чистота истории: в логе не будет лишних правок типа «исправил опечатку в коммите».
— Атомарность: изменения, которые логически принадлежат одной задаче, остаются в одном коммите.
— Профессионализм: твой Pull Request выглядит аккуратно и легко читается.

Важно: Никогда не делай --amend для коммитов, которые уже улетели в общую ветку (push). Это меняет хэш коммита, и у твоих коллег возникнут конфликты при попытке обновиться.

🔥 — если постоянно правишь свои сообщения
🤝 — если оставляешь опечатки как часть «авторского стиля»

➡️ GitHub Ready | #урок

🛠 Как отменить последние изменения? (Git Reset)

Бывает, что ты ушел не в ту сторону: наворотил лишнего в коде или случайно закоммитил то, что не должно было попасть в репозиторий. Чтобы не плодить «коммиты-откаты», можно просто вернуть состояние ветки назад во времени.

Задача:
— Отменить один или несколько последних коммитов.
— Выбрать: оставить правки в файлах или удалить их полностью.

Решение:

Команда reset перемещает указатель ветки на нужный коммит. Есть три основных режима:

# 1. SOFT — отменяет коммит, но оставляет все правки в индексе (готовы к коммиту).
# Идеально, если нужно просто переписать сообщение или объединить файлы.
git reset --soft HEAD~1

# 2. MIXED (по умолчанию) — отменяет коммит и убирает файлы из индекса, 
# но оставляет их в рабочей директории.
git reset HEAD~1

# 3. HARD — удаляет всё подчистую. Коммит исчезает, а файлы возвращаются 
# к состоянию "как было до этого коммита".
# Осторожно: несохраненные правки удалятся навсегда!
git reset --hard HEAD~1

Почему это полезно?
— Исправление ошибок: можно быстро «откатиться», если тесты упали после последнего коммита.
— Чистка индекса: если случайно добавил в git add лишние папки (например, node_modules).
— Гибкость: ты сам решаешь, насколько глубоко нужно «стереть» историю.

Важно: Как и с любой операцией, меняющей историю, используй reset только для локальных коммитов. Если код уже на сервере — лучше использовать git revert.

🔥 — если часто юзаешь --soft, чтобы переделать коммит
🤝 — если используешь только --hard, потому что «гулять так гулять»

➡️ GitHub Ready | #урок