🔄 Как быстро переименовать локальную ветку?

Иногда в спешке создаешь ветку с опечаткой или понимаешь, что название fix-1 совсем не отражает суть задачи. В Git можно легко переименовать ветку, не удаляя её.

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

Решение:

Для этого используется флаг -m (move):

# Переименовать текущую ветку, на которой ты находишься
git branch -m новое-название

# Переименовать любую другую ветку
git branch -m старое-название новое-название

Если ветка уже улетела на сервер (push):
— Переименуй её локально (как показано выше).
— Удали старую ветку на сервере: git push origin --delete старое-название.
— Запушь новую ветку и свяжи её с удаленной: git push origin -u новое-название.

Почему это важно?
— Порядок: понятные названия веток облегчают навигацию.
— Командная работа: коллегам проще ориентироваться в Pull Request, когда название ветки соответствует задаче.
— Автоматизация: многие CI/CD системы опираются на префиксы в названиях (например, feature/ или hotfix/).

🔥 — если всегда даешь веткам осмысленные имена
🤝 — если до сих пор работаешь в task-123

➡️ GitHub Ready | #урок

🔍 Как посмотреть разницу между коммитами? (Git Diff)

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

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

Решение:

Используем git diff с различными параметрами:

# Посмотреть изменения в рабочей директории (те, что еще не добавлены в индекс)
git diff

# Посмотреть изменения, которые уже добавлены в индекс (после git add)
git diff --staged

# Сравнить две ветки между собой
git diff branch1..branch2

# Посмотреть изменения в конкретном файле между двумя коммитами
git diff hash1 hash2 -- path/to/file.js

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

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

🔥 — если всегда проверяешь diff перед коммитом
🤝 — если доверяешь своей памяти и git status

➡️ GitHub Ready | #урок

🌍 Как клонировать только одну ветку? (Git Clone --single-branch)

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

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

Решение:

Используем комбинацию флагов --single-branch и -b (указывает имя ветки):

# Клонировать только ветку main без истории остальных веток
git clone --single-branch -b main https://github.com/user/repo.git

# Клонировать только одну ветку и только последний коммит (максимальная скорость)
git clone --depth 1 --single-branch -b main https://github.com/user/repo.git

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

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

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

➡️ GitHub Ready | #урок

gdown

gdown — это инструмент для загрузки публичных файлов и папок с Google Drive, особенно полезный в случаях, когда стандартные утилиты, такие как curl или wget, не справляются с задачей.

Он позволяет обходить предупреждения безопасности при загрузке больших файлов, поддерживает рекурсивную загрузку содержимого папок (до 50 файлов в папке) и предоставляет возможность выбора формата загрузки для документов Google (например, PDF, XML, CSV).

Дополнительно, gdown может использоваться как альтернатива curl или wget для загрузки файлов из других источников, а также поддерживает загрузку с использованием прокси-серверов и продолжение прерванных загрузок.

➡️ GitHub Ready | #урок

♻️ Как вернуть случайно удаленную ветку? (Git Reflog)

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

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

Решение:

На помощь приходит «бортовой самописец» Git — команда reflog. Она записывает каждое движение указателя HEAD, даже если коммиты больше не принадлежат ни одной ветке.

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

# В списке ищем строку вида: 
# a1b2c3d HEAD@{5}: commit: Fixed critical bug
# Где a1b2c3d — это хэш последнего коммита в твоей ветке

# 2. Восстанавливаем ветку по этому хэшу
git checkout -b название-ветки a1b2c3d

Почему это спасает жизнь?
— Надежность: reflog хранит данные обычно 30–90 дней.
— Всемогущество: можно отменить неудачный rebase, reset --hard или просто найти потерянный код.
— Спокойствие: ты знаешь, что любая ошибка в терминале обратима.

Главное помнить — reflog работает только локально. Если ты удалил ветку, которую никогда не пушил, восстановить её можно только на той же машине.

🔥 — если reflog уже спасал твой проект
🤝 — если еще не приходилось воскрешать ветки

——————————————————————-

Кстати, этот же метод помогает найти коммиты, которые ты потерял при неудачном слиянии конфликтов.

➡️ GitHub Ready | #урок

📦 Как извлечь один файл из другого коммита? (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 | #урок