⏱ Как узнать, на что уходит время? (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 | #урок

♻️ Как вернуть «удаленный» коммит? (Git Reflog)

Ты сделал git reset --hard и внезапно осознал, что удалил не тот коммит? Кажется, что код потерян навсегда, а часы работы улетели в пустоту. Но в Git почти ничего не исчезает бесследно, пока жива папка .git.

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

Решение:

На помощь приходит reflog (reference log) — это журнал всех перемещений указателя HEAD. Он записывает каждый ваш шаг, даже если вы прыгаете по истории или удаляете ветки.

# 1. Смотрим историю всех действий
git reflog

# Ты увидишь список вроде:
# ab12cd3 HEAD@{0}: reset: moving to HEAD~1
# ef45gh6 HEAD@{1}: commit: Добавил важную фичу  <-- ВОТ ОН!

# 2. Возвращаемся в то состояние, где всё было хорошо
git reset --hard ef45gh6

# Или просто создаем новую ветку из этого состояния, чтобы ничего не сломать
git branch recovery-branch ef45gh6

Почему это спасает жизни?
— Страховка: ты можешь смело экспериментировать с rebase и reset, зная, что всегда есть «черный ящик» с записями.
— Спокойствие: даже если ты удалил ветку целиком, её коммиты всё еще лежат в логе еще как минимум 30 дней (пока не придет Garbage Collector).
— Точность: reflog показывает не просто историю проекта, а твою личную историю действий в этом репозитории.

Важно: reflog хранится только локально. Если ты удалил что-то и переустановил систему или удалил папку с проектом, восстановить данные через него не получится.

🔥 — если reflog уже спасал твою карьеру
🤝 — если после reset --hard просто уходишь в депрессию

➡️ GitHub Ready | #урок

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

После долгой работы в проекте скапливаются не только коммиты, но и «хвосты»: временные логи, созданные скриптами папки, файлы конфигураций, которые ты забыл добавить в .gitignore, или просто артефакты сборки. Команда git status показывает их как untracked files, и они мозолят глаза.

Задача:
— Быстро удалить все файлы и папки, которые не отслеживаются Git.
— Привести рабочую директорию в идеально чистое состояние.

Решение:

Используем команду git clean. Она работает жестко, поэтому у неё есть «предохранитель» — по умолчанию она ничего не удалит без специального флага.

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

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

# 3. Удалить и файлы, и целые папки (directory)
git clean -fd

# 4. Удалить даже те файлы, что прописаны в .gitignore 
# (полезно, если нужно полностью пересобрать проект с нуля)
git clean -fdx

Почему это полезно?
— Порядок: git status снова становится коротким и понятным.
— Устранение багов: иногда странное поведение программы лечится просто удалением старых конфигов или кэша, которые застряли в папках.
— Подготовка: перед тем как заархивировать проект или передать его коллеге, стоит вычистить всё лишнее.

Важно: Будь предельно осторожен с флагом -x. Он удалит и node_modules, и .env файлы с ключами доступа. Всегда проверяй список через -n перед финальным запуском.

🔥 — если любишь, когда в status идеальная чистота
🤝 — если годами хранишь temp_v2_old.txt в корне проекта

➡️ GitHub Ready | #урок

🌍 Глобальный .gitignore: как не тащить мусор в каждый проект?

Каждый раз при создании нового репозитория мы добавляем в .gitignore одни и те же вещи: логи системы, кэш редактора (вроде .vscode или .idea) или скрытые файлы macOS (.DS_Store). Вместо того чтобы копировать их из проекта в проект, можно настроить один общий список для всего компьютера.

Задача:
— Автоматически игнорировать системный мусор во всех репозиториях.
— Сделать локальные файлы .gitignore чище, оставив там только специфичные для проекта вещи (например, node_modules или dist).

Решение:

Нужно создать один глобальный файл и сказать Git использовать его как эталон.

# 1. Создаем файл для глобального игнора (например, в домашней папке)
touch ~/.gitignore_global

# 2. Добавляем в него стандартный мусор (открой файл и вставь):
# .DS_Store
# .vscode/
# .idea/
# *.log
# thumbs.db

# 3. Регистрируем этот файл в глобальном конфиге Git
git config --global core.excludesfile ~/.gitignore_global

Почему это удобно?
— Чистые коммиты: ты никогда случайно не закинешь свои настройки VS Code в общий репозиторий.
— Экономия времени: создаешь папку, делаешь git init — и базовый игнор уже работает.
— Уважение к коллегам: пользователям Windows не мешают твои файлы из macOS, и наоборот.

Совет: Если ты работаешь на разных ОС, удобно держать такой файл в облаке или синхронизировать его через свой репозиторий с конфигами (dotfiles). А если не знаешь, что именно добавить в список, загляни на gitignore.io — там можно сгенерировать идеальный конфиг под твой стек.

🔥 — если уже настроил глобальный игнор
🤝 — если каждый раз гуглишь «что добавить в gitignore»

➡️ GitHub Ready | #урок

💨 Как «выселить» файл из Git, если он уже там? (Git rm --cached)

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

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

Решение:

Используем команду rm с флагом --cached. Это «мягкое» удаление: файл исчезнет из следующего коммита и из истории (в будущем), но физически останется в папке.

# 1. Удаляем конкретный файл из индекса
git rm --cached config.json

# 2. Если нужно удалить целую папку (например, случайно добавленные логи)
git rm -r --cached logs/

# 3. Теперь фиксируем изменения
git commit -m "Удалил конфиги из отслеживания"

# 4. Не забудь добавить этот файл/папку в .gitignore, 
# чтобы они снова случайно не попали в индекс!

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

Важно: Помни, что этот метод убирает файл из *текущего* состояния и будущих коммитов. В старых коммитах (в истории) файл всё равно останется. Если ты случайно закоммитил пароль от базы данных, его нужно либо менять, либо использовать специальные инструменты для полной очистки истории (например, BFG Repo-Cleaner).

🔥 — если хоть раз забывал скрыть .env
🤝 — если всегда проверяешь git add . перед коммитом

➡️ GitHub Ready | #урок

✂️ Как полностью стереть файл из истории? (BFG Repo-Cleaner)

Мы уже знаем, как перестать отслеживать файл, но что делать, если ты случайно закоммитил пароли, API-ключи или тяжеленное видео на 2 Гб? Даже если ты удалишь их в новом коммите, они навсегда останутся в истории папки .git, раздувая её размер и создавая дыру в безопасности.

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

Решение:

Стандартная команда git filter-branch очень медленная и сложная. Профи используют BFG Repo-Cleaner — это быстрая и простая альтернатива.

# 1. Сначала скачай bfg.jar (через brew или с официального сайта)

# 2. Удалить файл с конкретным именем из всей истории
java -jar bfg.jar --delete-files secret_key.txt

# 3. Удалить все папки с определенным именем (например, старые кэши)
java -jar bfg.jar --delete-folders .trash_data

# 4. После работы BFG нужно запустить очистку мусора самого Git
git reflog expire --expire=now --all && git gc --prune=now --aggressive

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

Важно: Эта операция полностью переписывает историю. После неё тебе придется сделать git push --force. Обязательно предупреди коллег, чтобы они переклонировали репозиторий, иначе их локальные версии «сойдут с ума» при попытке слияния.

🔥 — если чистил историю после случайного пуша
🤝 — если просто меняешь пароли, если они утекли

➡️ GitHub Ready | #урок

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

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

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

Решение:

Используем «карман» или «заначку» — команду stash. Она берет все твои незавершенные правки и временно убирает их в специальное хранилище.

# 1. Спрятать все текущие изменения (кроме новых файлов)
git stash

# 2. Спрятать всё, включая новые (untracked) файлы
git stash -u

# 3. Дать "заначке" имя, чтобы не запутаться в них через неделю
git stash save "Работа над корзиной: почти готово"

# 4. Посмотреть список всех своих заначек
git stash list

# 5. Вернуть изменения обратно и удалить их из хранилища
git stash pop

# 6. Вернуть изменения, но оставить их в списке stash
git stash apply

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

Совет: Если ты сделал stash pop и получил конфликты — не паникуй. Git вернет код в файлы, но пометит места конфликтов, как при обычном мерже. А если ты хочешь применить «заначку» к совершенно другой ветке — это тоже сработает!

🔥 — если stash — твоя любимая команда
🤝 — если коммитишь всё подряд с сообщением "."

➡️ GitHub Ready | #урок

🎯 Как вытащить из Stash только один файл?

Иногда в «заначке» (stash) лежит целая куча изменений: правки по стилям, новый метод в контроллере и фикс конфига. Тебе нужно вернуть только тот самый конфиг, а остальное оставить «до лучших времен». Стандартный git stash pop вывалит на тебя всё сразу, создавая хаос.

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

Решение:

Используем команду checkout (или restore), указывая путь к файлу и индекс заначки. По умолчанию последняя заначка — это stash@{0}.

# 1. Сначала посмотри список, чтобы найти нужный индекс
git stash list

# 2. Достаем конкретный файл из последней заначки
git checkout stash@{0} -- path/to/file.js

# 3. Если пользуешься современным Git (2.23+), лучше через restore:
git restore --source=stash@{0} path/to/file.js

# 4. Теперь файл у тебя в рабочей директории, а в stash 
# по-прежнему лежит полная копия всех изменений.

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

Совет: Если ты не помнишь, в какой именно заначке лежит нужный файл, используй git stash show -p stash@{1} — это покажет полный дифф (изменения кода) для конкретного сохранения.

🔥 — если любишь хирургическую точность в Git
🤝 — если всегда достаешь всё разом и сидишь в конфликтах

➡️ GitHub Ready | #урок

🌿 Как превратить заначку в отдельную ветку? (Git Stash Branch)

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

Задача:
— Безопасно перенести код из stash в новую чистую ветку.
— Избежать конфликтов, которые возникли бы при обычном pop.

Решение:

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

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

# Если заначка всего одна, можно просто:
git stash branch feature-new-logic

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

Когда это использовать?
Лучше всего это работает, когда вы начали делать фичу не в той ветке, вовремя спохватились, сделали stash, а теперь хотите продолжить работу уже в правильном, изолированном месте.

🔥 — если любишь идеальный порядок в ветках
🤝 — если просто копипастишь код в блокнот перед переключением

➡️ GitHub Ready | #урок

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

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

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

Решение:

Используем команду cherry-pick. Тебе нужно только знать хэш коммита (его можно найти через git log).

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

# 2. "Забираем" нужный коммит по его хэшу
git cherry-pick 7b2f3a1

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

Почему это удобно?
— Точность: ты берешь только то, что нужно, не прихватывая лишний «мусор» или недоделанные фичи из соседних веток.
— Мобильность: можно переносить исправления между версиями проекта (например, из ветки v2.0 в v1.0).
— Сохранение метаданных: Git сохраняет оригинальное сообщение коммита и автора, что упрощает навигацию в будущем.

Совет: Если тебе нужно забрать сразу несколько коммитов, идущих подряд, можно указать диапазон: git cherry-pick A..B (где А — более старый коммит, а B — более новый).

🔥 — если постоянно «воруешь» фиксы у коллег через cherry-pick
🤝 — если просто ждешь полного мержа веток

➡️ GitHub Ready | #урок

↩️ Как безопасно отменить коммит в общей ветке? (Git Revert)

Когда ошибка уже улетела на сервер (push), использовать reset или amend опасно — это перепишет историю и сломает работу коллегам. Для таких случаев есть «вежливый» способ отката — создание коммита, который делает всё ровно наоборот.

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

Решение:

Команда revert не удаляет старый коммит, а создает новый «анти-коммит». Если в оригинале вы добавили строку, revert её удалит. Если удалили файл — вернет.

# 1. Отменить самый последний коммит
git revert HEAD

# 2. Отменить конкретный коммит из прошлого по его хэшу
git revert 7b2f3a1

# 3. Отменить сразу несколько коммитов (диапазоном)
git revert A..B

Почему это лучше, чем Reset?
— Безопасность для команды: история только растет вперед, никто не получит ошибку "diverged branches".
— Документация: в логе остается четкий след: «Был коммит X, но мы его отменили коммитом Y из-за проблем».
— Гибкость: можно отменить коммит, который был сделан неделю назад, не затрагивая всё, что было написано после него.

Важно: Если при реверте возникают конфликты, это значит, что более свежий код затронул те же строки, что и отменяемый коммит. В этом случае нужно поправить файлы вручную, сделать git add и git revert --continue.

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

➡️ GitHub Ready | #урок

🧩 Как навести порядок в истории? (Git Squash)

Когда ты работаешь над фичей, в истории часто скапливается мусор: «Fix typo», «WIP», «Another fix», «Check CI». Отправлять такой хаос в основную ветку — плохой тон. Перед мержем лучше «склеить» (squash) все мелкие правки в один чистый и понятный коммит.

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

Решение:

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

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

# 2. В открывшемся редакторе ты увидишь список коммитов:
# pick a1b2c3d Сообщение 1
# pick e4f5g6h Сообщение 2
# pick i7j8k9l Сообщение 3

# 3. Замени слово 'pick' на 'squash' (или просто 's') 
# для тех коммитов, которые хочешь "влить" в предыдущий:
# pick a1b2c3d Сообщение 1
# squash e4f5g6h Сообщение 2
# squash i7j8k9l Сообщение 3

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

Почему это важно?
— Читаемость: вместо десяти правок в git log видна одна четкая задача: «Реализована авторизация через Google».
— Легкий откат: если фича сломала проект, её можно отменить одним git revert, а не выискивать все мелкие кусочки.
— Профессионализм: твой Pull Request выглядит аккуратно, что очень радует тимлидов на код-ревью.

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

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

➡️ GitHub Ready | #урок

🕵️ Как вычислить коммит, который всё сломал? (Git Bisect)

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

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

Решение:

Используем «бинарный поиск» через git bisect. Git делит историю пополам, спрашивает тебя «тут работает?», и так за считанные шаги находит виновника.

# 1. Запускаем процесс
git bisect start

# 2. Помечаем текущее состояние как "плохое" (тут баг есть)
git bisect bad

# 3. Указываем хэш коммита, когда всё точно работало (например, вчерашний)
git bisect good 7b2f3a1

# Git переключит тебя на коммит ровно посередине.
# Проверяешь код (запускаешь тесты или приложение).

# 4. Если баг остался:
git bisect bad
# Если всё работает:
git bisect good

# Повторяй, пока Git не выдаст хэш того самого коммита-преступника.
# 5. Завершаем поиск и возвращаемся в реальность:
git bisect reset

Почему это магия?
— Скорость: чтобы найти ошибку среди 1000 коммитов, тебе понадобится всего около 10 проверок.
— Точность: исключается человеческий фактор «проглядел».
— Автоматизация: если у тебя есть готовый тест (скрипт), можно запустить git bisect run ./test.sh, и Git сам найдет баг, пока ты пьешь кофе.

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

🔥 — если bisect — твой главный детектив
🤝 — если ищешь баги глазами до победного

➡️ GitHub Ready | #урок