🧪 Git Commit –amend — исправление последнего коммита

git commit --amend позволяет изменить последний коммит без создания нового.

Типичные случаи:
• забыли добавить файл;
• опечатка в сообщении;
• мелкая правка кода.

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

git add forgotten_file.js
git commit --amend

Только изменить сообщение:

git commit --amend -m "fix: correct auth flow"

Важно:
• переписывает hash коммита;
• не использовать для уже запушенных коммитов;
• идеально перед push или PR.

--amend — аккуратность вместо мусора в истории.

➡️ GitHub Ready | #урок

🧭 Git Describe — понятные версии вместо hash

git describe показывает текущий коммит через ближайший тег. Удобно для отладки, логов и версий сборок.

Базово:

git describe

Что вернёт:

v1.2.0-5-g9f3a1c2

Где:
• v1.2.0 — ближайший тег;
• 5 — количество коммитов после тега;
• g9f3a1c2 — hash коммита.

С учётом всех тегов:

git describe --tags

Использование:
• версии в CI/CD;
• отладка сборок;
• понимание «где мы находимся» без hash.

git describe — читаемый идентификатор состояния проекта.

➡️ GitHub Ready | #урок

📐 Git Range-diff — сравнение двух серий коммитов

git range-diff показывает разницу между наборами коммитов, а не файлами. Полезно после rebase, когда нужно понять, что реально изменилось.

Базовый пример:

git range-diff main..feature main..feature-rebased

Что показывает:
• какие коммиты изменились;
• какие были удалены или добавлены;
• как поменялось содержимое коммитов.

Типичный сценарий:
• сделал rebase;
• хочешь проверить, не потерял ли правки;
• сравниваешь старую и новую версию ветки.

Важно:
• работает на уровне истории;
• незаменим при код-ревью после rebase;
• читается проще, чем log + diff.

range-diff — контроль истории, а не файлов.

➡️ GitHub Ready | #урок

🧵 Git Notes — комментарии к коммитам без изменения истории

git notes позволяет добавлять заметки к коммитам, не меняя их hash и историю.

Добавить заметку:

git notes add <hash>

Просмотр заметки:

git notes show <hash>

Удаление:

git notes remove <hash>

Важно:

* заметки хранятся отдельно от коммитов;
* по умолчанию не пушатся;
* для синхронизации:

git push origin refs/notes/*

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

* пояснения к сложным коммитам;
* результаты ревью;
* внутренние комментарии команды.

git notes — контекст без переписывания истории.

➡️ GitHub Ready | #урок

🔄 Git Merge — стратегии слияния веток

При слиянии веток Git использует разные стратегии, и их выбор влияет на историю.

Основные стратегии:

1. recursive (по умолчанию)
* подходит для большинства случаев;
* умеет решать конфликты при слиянии двух веток с общим предком.

2. ours
сохраняет изменения текущей ветки;
игнорирует изменения сливаемой ветки:

git merge -s ours feature

3. octopus
для слияния более двух веток одновременно;
конфликты не решает, только простые случаи.

Советы:
чаще всего хватает стандартного recursive;
ours — для отмены чужих изменений при слиянии;
octopus — при массовом объединении веток для релиза.

Стратегия merge — инструмент контроля истории, а не магия.

➡️ GitHub Ready | #урок

🧾 .gitattributes — управление поведением файлов в Git

.gitattributes позволяет задавать правила обработки файлов: diff, merge, eol, linguist, binary — без влияния на код.

Примеры:

Пометить бинарные файлы:

*.png binary
*.zip binary

Настроить конец строк (важно для Windows/Linux):

*.sh  text eol=lf
*.bat text eol=crlf

Отключить diff для файлов:

package-lock.json -diff

Задать кастомный diff:

*.md diff=markdown

Зачем это нужно:
• меньше конфликтов;
• корректные diff;
• одинаковое поведение в команде;
• контроль без хаков.

.gitattributes — тонкая настройка Git на уровне файлов.

➡️ GitHub Ready | #урок

🧠 Git Plumbing vs Porcelain — внутренняя кухня Git

Git-команды делятся на два уровня: для людей и для машин.

Porcelain — высокоуровневые команды для ежедневной работы:
• git commit
• git merge
• git pull
• git status

Plumbing — низкоуровневые команды, из которых всё собрано:
• git hash-object
• git cat-file
• git update-index
• git write-tree

Пример:

git cat-file -p HEAD

Зачем знать:
• отладка сложных кейсов;
• понимание, как Git хранит данные;
• написание скриптов и инструментов.

Porcelain — интерфейс. Plumbing — механизм.

➡️ GitHub Ready | #урок

🧪 Git Filter-Repo — переписывание истории правильно

git filter-repo — современная замена filter-branch. Используется для очистки истории: удаление файлов, директорий, секретов.

Удалить файл из всей истории:

git filter-repo --path config.env --invert-paths

Удалить директорию:

git filter-repo --path build/ --invert-paths

Заменить e-mail автора:

git filter-repo --email-callback '
return b"user@old.com" == email and b"user@new.com" or email
'

Важно:
• полностью переписывает историю;
• после — force push;
• использовать осознанно.

filter-repo — хирургия истории без костылей.

➡️ GitHub Ready | #урок

📦 Git Bundle — перенос репозитория без интернета

git bundle упаковывает историю репозитория в один файл. Подходит для передачи кода офлайн или через закрытые контуры.

Создать bundle:

git bundle create repo.bundle --all

Создать bundle с одной веткой:

git bundle create feature.bundle feature/login

Проверить содержимое:

git bundle list-heads repo.bundle

Клонировать из bundle:

git clone repo.bundle project

Использование:
• офлайн-передача;
• air-gapped среды;
• быстрый бэкап истории.

git bundle — репозиторий в одном файле.

➡️ GitHub Ready | #урок

🧩 Git Merge — как использовать --no-ff и зачем он нужен

По умолчанию, если ветка может быть слита без конфликта, Git делает fast-forward — история остаётся линейной. Но иногда нужен merge-коммит для ясности.

Пример:

git merge --no-ff feature/login

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

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

--no-ff — контроль структуры истории без потери изменений.

➡️ GitHub Ready | #урок

📡 Git Remote — управление удалёнными репозиториями

git remote отвечает за подключённые удалённые репозитории и их адреса.

Посмотреть текущие remote:

git remote -v

Добавить новый:

git remote add upstream https://github.com/org/project.git

Переименовать:

git remote rename origin old-origin

Удалить:

git remote remove upstream

Зачем это нужно:

* работа с fork + upstream;
* миграция репозитория;
* контроль источников кода.

git remote — карта связей между репозиториями.

➡️ GitHub Ready | #урок

🧠 Git Index (Staging Area) — скрытый слой между кодом и коммитом

Index — это промежуточное состояние между рабочей директорией и коммитом. Git коммитит не файлы, а именно содержимое index.

Добавление в index:

git add file.js

Проверка состояния:

git status

Убрать файл из index, не трогая код:

git restore --staged file.js

Частичное добавление:

git add -p

Зачем нужен index:
• точечные коммиты;
• контроль содержимого;
• чистая история.

Index — причина, почему Git мощнее простых VCS.

➡️ GitHub Ready | #урок

🧯 git pull --rebase --autostash — обновление без ручного stash

При rebase Git обычно требует чистую рабочую директорию. Флаг --autostash решает это автоматически.

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

git pull --rebase --autostash

Что происходит:
• текущие изменения временно сохраняются;
• выполняется fetch + rebase;
• изменения автоматически возвращаются обратно.

Полезно, когда:
• есть незакоммиченные правки;
• нужно быстро подтянуть remote;
• не хочется вручную делать stash.

Можно включить по умолчанию:

git config --global rebase.autoStash true

autostash — меньше ручных шагов, меньше ошибок.

➡️ GitHub Ready | #урок

🧪 Git Restore — возврат файлов без влияния на историю

git restore используется для отката изменений в файлах и индексе, не трогая коммиты и ветки.

Откат файла из рабочей директории:

git restore file.js

Убрать файл из index:

git restore --staged file.js

Вернуть файл из другого коммита:

git restore --source=HEAD~1 file.js

Почему это важно:

* замена опасных checkout;
* точечный контроль;
* безопасный откат.

git restore — инструмент аккуратной работы с изменениями.

➡️ GitHub Ready | #урок

🔍 Git Log — удобные фильтры для истории коммитов

git log позволяет не просто смотреть коммиты, а фильтровать их по автору, дате, сообщению и файлам.

Примеры:
• Коммиты конкретного автора:

git log --author="Nadir"

• Коммиты за последние 7 дней:

git log --since="7 days ago"

• По ключевому слову в сообщении:

git log --grep="fix login"

• История конкретного файла:

git log -- path/to/file.js

💡 Фильтры помогают быстро найти нужный коммит без просмотра всей истории.

➡️ GitHub Ready | #урок

🧵 Git Patch — перенос изменений без merge и cherry-pick

git patch позволяет переносить изменения между репозиториями или ветками в виде файлов-патчей.

Создать патч из последнего коммита:

git format-patch -1 HEAD

Создать патчи для диапазона коммитов:

git format-patch main..feature

Применить патч:

git apply fix.patch

Или с созданием коммита:

git am fix.patch

Когда это используют:
• код-ревью по почте;
• перенос правок без доступа к remote;
• изоляция изменений.

Patch — перенос кода без привязки к репозиторию.


➡️ GitHub Ready | #урок

🧭 Git HEAD~ и ^ — навигация по истории коммитов

Git позволяет ссылаться на коммиты относительно текущего положения, без копирования hash.

Примеры:

HEAD~1   # предыдущий коммит
HEAD~3   # три коммита назад

Оператор ^:

HEAD^    # первый родитель
HEAD^2   # второй родитель (при merge)

Комбинации:

HEAD~2^

Полезно для:
• reset / checkout;
• revert;
• анализа истории без git log.

Относительные ссылки — быстрый способ перемещаться по истории Git.

➡️ GitHub Ready | #урок

📌 Git Assume-Unchanged vs Skip-Worktree — временно игнорировать изменения

Эти флаги говорят Git не обращать внимания на локальные изменения, но делают это по-разному.

Assume-unchanged

git update-index --assume-unchanged config.yml

* Git перестаёт проверять изменения файла;
* используется для ускорения status;
* небезопасен при активной разработке.

Skip-worktree

git update-index --skip-worktree config.yml

* файл считается «не для изменений»;
* безопаснее для локальных конфигов;
* часто применяют для *.env.

Сброс флагов:

git update-index --no-assume-unchanged config.yml
git update-index --no-skip-worktree config.yml

Важно:

* не замена .gitignore;
* не коммитится;
* действует только локально.

Эти флаги — для тонкого локального контроля, а не для команды.

➡️ GitHub Ready | #урок

🧩 Git Shortlog — краткая статистика по коммитам

git shortlog показывает, кто и сколько коммитов сделал, удобно для отчётов и обзора вклада команды.

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

git shortlog

Список авторов с количеством коммитов:

git shortlog -s -n

* -s — только числа;
* -n — сортировка по количеству коммитов.

Фильтр по ветке или диапазону:

git shortlog main..feature

Когда полезно:

* отчёт для менеджеров;
* подготовка релизного отчёта;
* обзор активности команды.

shortlog — быстрый взгляд на вклад каждого разработчика.

➡️ GitHub Ready | #урок

🧾 .git-blame-ignore-revs — чтобы blame был полезным

Иногда git blame показывает коммиты с форматированием или рефакторингом, которые не несут смысла. Это можно исключить.

Создай файл:

.git-blame-ignore-revs

Добавь hash-коммиты, которые нужно игнорировать:

a1b2c3d4
e5f6g7h8

Включи настройку:

git config blame.ignoreRevsFile .git-blame-ignore-revs

Что это даёт:
• blame показывает реальные изменения логики;
• форматирование не шумит;
• проще искать причины багов.

.git-blame-ignore-revs - чистый blame без мусора.

➡️ GitHub Ready | #урок

🧠 Git Rev-Parse — как Git понимает ссылки на коммиты

git rev-parse показывает, во что Git реально преобразует ссылки вроде HEAD, веток и тегов. Полезно для скриптов и отладки.

Получить hash текущего коммита:

git rev-parse HEAD

Hash ветки:

git rev-parse main

Проверка, существует ли ссылка:

git rev-parse --verify feature/login

Определить имя текущей ветки:

git rev-parse --abbrev-ref HEAD

Зачем использовать:

* shell-скрипты и CI;
* диагностика сложных кейсов;
* понимание, как Git резолвит ссылки.

rev-parse — взгляд на Git без абстракций.

➡️ GitHub Ready | #урок