🧠 Зачем нужен git blame и как читать его правильно

git blame показывает, какой коммит и какой автор последний раз менял каждую строку файла. Инструмент для понимания контекста, а не для поиска виноватых.

Базовое использование:

git blame app.js

Полезные флаги:
• Игнорировать переносы строк и форматирование:

git blame -w app.js

• Показать историю конкретного диапазона строк:

git blame -L 20,40 app.js

Переход к коммиту строки:
• копируешь hash;
• смотришь изменения:

git show <hash>

git blame отвечает на три вопроса: что изменили, когда и зачем.

➡️ GitHub Ready | #урок

🔀 Merge commit vs Fast-forward — в чём разница

При слиянии веток Git может использовать разные стратегии. Понимание разницы важно для чистой истории.

Fast-forward merge
Происходит, если основная ветка не менялась.
• Git просто сдвигает указатель ветки;
• история остаётся линейной;

git merge feature

Merge commit
Создаётся отдельный коммит слияния.
• сохраняет факт объединения веток;
• полезно для больших фич;

git merge --no-ff feature

Когда что использовать:
• fast-forward — мелкие правки, простые фичи;
• merge commit — командная работа, долгие ветки.

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

➡️ GitHub Ready | #урок

🧪 Git Bisect — поиск бага бинарным поиском

git bisect помогает найти коммит, в котором появился баг, без ручного перебора истории. Git сам делит диапазон коммитов пополам.

Запуск:

git bisect start
git bisect bad        # текущий коммит с багом
git bisect good v1.2  # версия, где всё работало

Дальше Git:
• переключает коммиты;
• ты проверяешь баг;
• помечаешь результат:

git bisect good
git bisect bad

Завершение:

git bisect reset

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

➡️ GitHub Ready | #урок

🔐 Подпись коммитов в Git — зачем и как использовать

Подписанные коммиты подтверждают, что изменения действительно сделаны автором, а не подменены. Часто требуются в open-source и корпоративных репозиториях.

Проверка подписи коммита:

git log --show-signature

Подпись каждого коммита:

git config --global commit.gpgsign true

Одноразовая подпись:

git commit -S -m "fix: auth logic"

Что это даёт:
• подтверждение авторства;
• защита от подмены;
• доверие к истории репозитория.

Подпись коммитов — это не паранойя, а контроль целостности кода.

➡️ GitHub Ready | #урок

📦 Git Submodule — подключение одного репозитория к другому

git submodule позволяет использовать внешний репозиторий как часть основного проекта, фиксируя конкретную версию кода.

Добавление сабмодуля:

git submodule add https://github.com/lib/example.git libs/example

Инициализация и загрузка:

git submodule update --init --recursive

Обновление сабмодулей:

git submodule update --remote

Важно помнить:
• сабмодуль — это отдельный Git-репозиторий;
• в основном проекте хранится ссылка на конкретный коммит;
• изменения в сабмодуле нужно коммитить отдельно.

Submodule — инструмент для строгого контроля зависимостей, а не для удобства.

➡️ GitHub Ready | #урок

📊 Git Cherry-pick — перенос одного коммита без всей ветки

git cherry-pick позволяет взять конкретный коммит и применить его в другой ветке, не делая merge или rebase всей истории.

Базовое использование:

git cherry-pick <hash>

Перенос диапазона коммитов:

git cherry-pick <hash1>..<hash2>

Если возник конфликт:

git cherry-pick --continue

Отмена операции:

git cherry-pick --abort

Когда полезно:
• срочный хотфикс в main;
• перенос одной фичи без лишних изменений;
• аккуратная работа с релизными ветками.

cherry-pick — точный инструмент, требует аккуратности.

➡️ GitHub Ready | #урок

⚙️ Git Hooks — автоматизация до и после команд Git

Git hooks — это скрипты, которые автоматически запускаются при определённых действиях: коммит, push, merge и т.д. Используются для контроля качества и автоматизации.

Где находятся:

.git/hooks/

Примеры хуков:
• pre-commit — запуск линтера, тестов;
• commit-msg — проверка формата сообщения;
• pre-push — блокировка push при ошибках.

Простейший pre-commit:

#!/bin/sh
npm test || exit 1

Важно:
• хуки не коммитятся по умолчанию;
• для команды используют шаблоны или husky;
• экономят время и ловят ошибки раньше CI.

Git hooks — локальный CI до настоящего CI.

➡️ GitHub Ready | #урок

🧬 Detached HEAD — что это и почему это нормально

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

Пример:

git checkout a1b2c3d

Что происходит:
• HEAD указывает прямо на коммит;
• новые коммиты не принадлежат ни одной ветке;
• при переключении ветки они могут «потеряться».

Как сохранить работу:

git switch -c fix-from-old-commit

Когда это полезно:
• анализ старого состояния проекта;
• тестирование прошлых версий;
• быстрые эксперименты без влияния на ветки.

Detached HEAD — это режим просмотра и экспериментов, а не ошибка.

➡️ GitHub Ready | #урок

📈 Git Squash — объединение коммитов перед merge

Squash позволяет превратить несколько рабочих коммитов в один аккуратный перед добавлением в основную ветку.

Через интерактивный rebase:

git rebase -i HEAD~3

В списке:
• первый коммит — pick;
• остальные меняешь на squash или s.

После этого:
• объединяются изменения;
• редактируется одно итоговое сообщение коммита;
• история становится чище.

Когда использовать:
• много мелких «fix», «wip»;
• подготовка PR;
• требования к чистой истории.

Squash — порядок в истории без потери смысла изменений.

➡️ GitHub Ready | #урок

🧾 Conventional Commits — зачем нужен единый формат коммитов

Conventional Commits — соглашение о структуре сообщений коммитов, которое упрощает навигацию по истории и автоматизацию релизов.

Формат:

type(scope): краткое описание

Примеры:

feat(auth): add token refresh
fix(ui): fix modal closing bug
refactor(api): simplify handlers

Что это даёт:
• читаемая история;
• автоматический changelog;
• корректный semver;
• проще код-ревью.

Conventional Commits — фундамент для масштабируемой разработки.

➡️ GitHub Ready | #урок

🗂 Git Worktree — несколько рабочих копий одного репозитория

git worktree позволяет иметь несколько рабочих директорий для одного репозитория без лишних clone.

Добавить новую рабочую копию:

git worktree add ../hotfix main

Список worktree:

git worktree list

Удаление:

git worktree remove ../hotfix

Когда полезно:
• параллельная работа над фичей и хотфиксом;
• тестирование разных веток одновременно;
• экономия места и времени.

worktree — альтернатива постоянным stash и переключениям веток.

➡️ GitHub Ready | #урок

🧭 Git HEAD — что это и как он управляет репозиторием

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

Проверить, куда указывает HEAD:

cat .git/HEAD

Типичные случаи:
• HEAD -> main — нормальная работа;
• HEAD -> feature — работа в фиче-ветке;
• HEAD detached — HEAD указывает прямо на коммит.

Перемещение HEAD:

git checkout HEAD~1

Важно:
• коммиты всегда создаются там, куда указывает HEAD;
• понимание HEAD = меньше «магии» в Git;
• большинство ошибок — это потерянный контекст HEAD.

Git становится простым, когда ясно, куда смотрит HEAD.

➡️ GitHub Ready | #урок

🧩 Git Reset — чем отличаются --soft, --mixed, --hard

git reset перемещает HEAD и по-разному влияет на индекс и рабочую директорию. Ошибки здесь самые дорогие, поэтому важно понимать разницу.

--soft

git reset --soft HEAD~1

• сдвигает HEAD;
• индекс и файлы не трогает;
• коммит «отменён», изменения готовы к новому коммиту.

--mixed (по умолчанию)

git reset HEAD~1

• сдвигает HEAD;
• очищает индекс;
• файлы остаются изменёнными.

--hard

git reset --hard HEAD~1

• сдвигает HEAD;
• очищает индекс;
• удаляет изменения в файлах.

reset — инструмент контроля, а не отката «наугад».

➡️ GitHub Ready | #урок

💡 Git Diff — сравниваем изменения на лету

git diff показывает, что изменилось между коммитами, ветками или рабочей директорией.

Примеры использования:
• Изменения в рабочей директории перед коммитом:

git diff

• Изменения между индексом и последним коммитом:

git diff --cached

• Сравнение двух веток:

git diff main..feature

• Конкретного файла:

git diff HEAD~1 README.md

💡 Полезно для проверки работы перед коммитом и анализа истории без открытия внешних инструментов.

➡️ GitHub Ready | #урок

🧠 Git Config — управление поведением Git

git config отвечает за настройки Git: от имени автора до стратегий слияния. Понимание уровней конфигурации избавляет от неожиданных эффектов.

Уровни конфигурации:
• --system — для всей системы;
• --global — для пользователя;
• --local — для конкретного репозитория.

Примеры:

git config --global user.name "Nadir"
git config --global user.email "mail@example.com"

Посмотреть все активные настройки:

git config --list --show-origin

Удалить параметр:

git config --unset user.name

git config — это не разовая команда, а фундамент стабильной работы с Git.

➡️ GitHub Ready | #урок

За это видео мне заплатили 20.000 рублей, но его сделало ИИ 😎

Никакого волшебства. Достаточно владеть ИИшками хотя бы на 6/10, чтобы превратить это в полноценный источник дохода.

Так что если хочешь разобраться, занять место в свежей нише и делать там от 250к в месяц — тебе в Tech Lab

Тут авторы реально шарят за IT-стартапы и ИИ-разработки, так что сохраняйте — будет куча интересного, даже если ни разу не пользовались ИИ: @TechLab

🔄 Git Pull — fetch + merge или fetch + rebase

git pull обновляет вашу ветку с удалённого репозитория, но стратегия слияния влияет на историю.

По умолчанию:

git pull

• делает fetch + merge;
• создаёт merge-коммит, если есть новые изменения.

Чтобы сохранить линейную историю:

git pull --rebase

• переносит ваши коммиты поверх удалённых;
• история остаётся чистой.

Можно настроить по умолчанию:

git config --global pull.rebase true

💡 Понимание стратегии pull помогает избежать «грязных» merge-коммитов и конфликтов в команде.

➡️ GitHub Ready | #урок

🏷 Git Tag — фиксация релизов и важных состояний

git tag используется для пометки конкретных коммитов: релизы, версии, контрольные точки.

Типы тегов:
• lightweight — простой указатель;
• annotated — полноценный объект с описанием и автором.

Создание:

git tag v1.0.0
git tag -a v1.1.0 -m "release 1.1.0"

Просмотр тегов:

git tag
git show v1.0.0

Отправка тегов в remote:

git push origin v1.0.0
git push origin --tags

Использование:
• релизы и hotfix;
• CI/CD;
• точная навигация по версиям.

Теги — это якоря стабильности в истории Git.

➡️ GitHub Ready | #урок

📂 Git Archive — экспорт проекта без .git

git archive позволяет собрать архив из репозитория без истории и служебных файлов. Удобно для передачи кода или деплоя.

Создание архива:

git archive --format=zip HEAD > project.zip

Экспорт конкретной ветки:

git archive --format=tar main | gzip > main.tar.gz

Экспорт поддиректории:

git archive HEAD src/ > src.tar

Особенности:
• без папки .git;
• ровно то состояние, что в коммите;
• подходит для CI и релизов.

git archive — чистый код без лишнего контекста.

➡️ GitHub Ready | #урок

🧪 Git Show — просмотр одного коммита без шума

git show позволяет быстро посмотреть содержимое конкретного коммита: изменения, автора и сообщение.

Базовое использование:

git show <hash>

Полезные варианты:
• Только изменения файлов:

git show --stat <hash>

• Конкретный файл из коммита:

git show <hash>:src/app.js

• Без diff, только сообщение:

git show --no-patch <hash>

Когда использовать:
• анализ правок;
• код-ревью;
• быстрый контекст без git log.

git show — минимализм для работы с историей.

➡️ GitHub Ready | #урок

🧷 Git Alias — короткие команды вместо длинных

git alias позволяет создавать свои сокращения для часто используемых команд.

Примеры:

git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.st status

Более полезные алиасы:

git config --global alias.lg "log --oneline --graph --all"
git config --global alias.unstage "reset HEAD --"

Просмотр всех алиасов:

git config --get-regexp alias

Alias — ускорение работы без плагинов и магии.

➡️ GitHub Ready | #урок