Git, shell и редакторы: ежедневный инструментарий

Первый урок раздела. Здесь собран инструментарий, в котором разработчик живёт каждый день: система контроля версий, терминал и редактор. Это не магия, а несколько привычек, которые экономят месяцы. Большинство людей освоили эти инструменты на уровне “пять команд по памяти” и дальше не двигались. Разница между таким человеком и тем, кто понимает модель под капотом, видна на каждой нетривиальной задаче: разрулить конфликт, найти, когда сломалось, собрать ответ из логов за минуту вместо получаса.

Идея: три модели вместо тысячи команд

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

1. Git это граф коммитов. Каждый коммит это снимок дерева плюс ссылки на родителей. Ветка это просто подвижный указатель на коммит. Почти любая операция git это перемещение указателей по графу.
2. Shell это композиция мелких программ. Каждая утилита делает одно и читает/пишет текстовые потоки. Сила не в отдельной команде, а в |, который соединяет их в конвейер.
3. Редактор это фронтенд к языковому серверу. Подсветка, переход к определению, рефактор приходят не от редактора, а от LSP. Редактор лишь рисует то, что присылает сервер.

Дальше разберём каждую модель и то, что из неё следует.

Git как граф коммитов

Три области, между которыми ходят файлы, надо понимать буквально:

• Рабочее дерево (working tree): файлы, которые ты редактируешь.
• Индекс (staging area): что попадёт в следующий коммит.
• Репозиторий: граф уже зафиксированных коммитов.

git add двигает изменение из рабочего дерева в индекс, git commit превращает индекс в новый коммит. Понимание этих трёх зон убирает почти всю путаницу новичка: git status всегда показывает, что в какой зоне, а git diff без аргументов сравнивает рабочее дерево с индексом, git diff --staged сравнивает индекс с последним коммитом.

Базовый набор, который должен работать на автопилоте:

git switch -c feature/login   # создать ветку и перейти на неё
git add -p                     # добавить изменения по кускам (hunks)
git commit -m "feat: add login form"
git push -u origin feature/login
git log --oneline --graph      # увидеть граф коммитов глазами

git add -p (patch mode) это привычка, которая отделяет аккуратную историю от свалки. Он показывает изменения кусками и спрашивает по каждому, брать его в коммит или нет. Так один коммит получается про одно.

Перемещение указателей: reset, revert, cherry-pick

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

• git reset двигает указатель ветки назад. --soft оставляет изменения в индексе, --mixed (по умолчанию) в рабочем дереве, --hard выбрасывает их совсем. --hard это единственная команда из трёх, которая теряет работу, относись к ней соответственно.
• git revert создаёт новый коммит, отменяющий старый. Историю не трогает, поэтому это правильный способ откатить то, что уже ушло в общую ветку.
• git cherry-pick <sha> копирует один коммит на текущую ветку. Полезно, когда нужен один фикс из другой ветки, а не вся она.

Stash и worktree

git stash прячет грязное рабочее дерево, чтобы быстро переключиться на другую задачу. Удобно, но если прятки затягиваются, лучше git worktree: он разворачивает вторую рабочую папку на другой ветке, и не приходится ничего прятать.

git worktree add ../proj-hotfix hotfix/urgent
# теперь в ../proj-hotfix отдельное дерево на ветке hotfix/urgent

Углублённый слой: reflog как сеть безопасности

Главная команда, которая спасает запоротую работу, это git reflog. Git почти ничего не удаляет сразу: даже после reset --hard потерянный коммит живёт в reflog недели, пока его не соберёт git gc. Нашёл нужный sha в reflog, сделал на него ветку, работа вернулась.

git rerere (reuse recorded resolution) запоминает, как ты разрулил конфликт, и применяет то же решение автоматически, когда тот же конфликт встречается снова. Незаменимо при долгих rebase, где один и тот же кусок конфликтует на каждом коммите.