Топ 7 вещей, которые нужно знать про Git

Три состояния файла

пока это не уложилось, всё остальное выглядит магией

Файл может быть изменён в рабочем каталоге, добавлен в индекс и зафиксирован в истории. Команда git add перемещает из первого во второе, git commit — из второго в третье.

Зачем нужен индекс. Он позволяет собрать коммит из части изменений: поправили три вещи, а зафиксировать хотите пока одну. git add -p предлагает изменения по кускам и спрашивает про каждый — это лучший способ разбить кашу правок на осмысленные коммиты.

git status показывает всю картину и подсказывает команды. Смотрите в него постоянно, особенно первое время.

• Объясняет поведение всех остальных команд
• git add -p делает историю читаемой
• git status всегда подскажет, что дальше

• Индекс — лишняя сущность по сравнению с другими системами
• Первое время про него забывают

база · оценка 9,5

Ветка — это просто указатель

и от этого перестаёт быть страшно

Ветка не копирует проект. Это метка, указывающая на коммит, и создание ветки — операция мгновенная независимо от размера репозитория.

Рабочая привычка. Отдельная ветка на каждую задачу: git switch -c имя-задачи. Эксперимент не жалко бросить, а основная ветка всегда остаётся рабочей.

Про современные команды. Раньше всё делали через git checkout, и он до сих пор работает. Но git switch для веток и git restore для файлов понятнее и безопаснее: одна команда — одно назначение.

• Создание ветки ничего не стоит
• Эксперименты не трогают основную ветку
• switch и restore понятнее старого checkout

• Множество заброшенных веток со временем засоряет репозиторий
• В старых руководствах везде checkout

каждый день · оценка 9,4

Как отменять — четыре разных случая

именно здесь ломают проект чаще всего

Отменить правки в файле, ещё не добавленном в индекс: git restore файл. Изменения теряются безвозвратно — это единственная по-настоящему опасная отмена.

Убрать файл из индекса, сохранив правки: git restore --staged файл.

Переделать последний коммит: git commit --amend. Только если он ещё не отправлен в общий репозиторий.

Отменить уже отправленный коммит: git revert хеш — он создаёт новый коммит, отменяющий изменения. Именно так это делают в общей ветке, а не через reset с последующей принудительной отправкой.

• На каждый случай есть безопасный вариант
• revert не переписывает общую историю
• Почти всё обратимо

• Команды легко перепутать
• restore без --staged стирает правки насовсем

регулярно · оценка 9,3

git log и git blame — чтение истории

половина работы с чужим кодом происходит здесь

git log --oneline --graph --all — компактная история в виде дерева: сразу видно, кто от чего ответвился и что куда влилось.

git blame файл — показывает, кто и в каком коммите написал каждую строку. Название неудачное: пользуются им не чтобы найти виноватого, а чтобы найти коммит и прочитать, зачем строка появилась.

git log -p файл — вся история изменений конкретного файла с диффами. Лучший способ понять, как код дошёл до текущего состояния.

• Отвечает на вопрос «зачем это здесь»
• Ищет по автору, дате и тексту сообщения
• Ничего не меняет — безопасно

• Бесполезен, если сообщения коммитов написаны кое-как
• Массовое переформатирование кода ломает blame

при чтении кода · оценка 9,2

Конфликты слияния

не поломка, а нормальная часть работы

Конфликт возникает, когда двое поменяли одни и те же строки. Git честно признаётся, что не может решить сам, и помечает спорные места прямо в файле.

Что делать. Открыть файл, оставить правильный вариант, удалить маркеры, добавить файл в индекс и завершить слияние. Никакой магии — вы просто редактируете текст.

Как их уменьшить. Чаще подтягивать основную ветку в свою и держать задачи маленькими. Ветка, живущая три недели, гарантирует болезненное слияние. И если запутались — git merge --abort возвращает всё как было.

• Всегда есть путь назад через --abort
• Git показывает оба варианта явно
• Частые слияния делают конфликты мелкими

• Пугают новичков сильнее всего
• Легко случайно оставить маркеры в коде
• В сгенерированных файлах разрешать бессмысленно — их проще пересобрать

неизбежно · оценка 8,9

git stash — отложить работу

спасает в ситуации «надо срочно посмотреть другую ветку»

git stash убирает текущие незавершённые правки в сторону и возвращает чистое рабочее состояние. git stash pop достаёт их обратно.

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

Осторожно. Отложенное легко забыть: git stash list иногда показывает залежи полугодовой давности. Лучше использовать stash на минуты, а не на дни — для долгого лучше сделать черновой коммит в своей ветке.

• Мгновенно освобождает рабочий каталог
• Не засоряет историю мусорными коммитами
• Можно отложить несколько раз подряд

• Про отложенное легко забыть
• Новые файлы без -u не попадают в stash
• Конфликты при возврате никуда не деваются

по ситуации · оценка 8,7

git reflog — страховка от всего

команда, которая однажды спасёт вам день

git reflog показывает историю перемещений вашей ветки — включая те коммиты, которые вы «потеряли» неудачным reset или переключением. Оттуда можно вернуться в любое состояние.

Как это выглядит на практике. Сделали жёсткий сброс не туда, коммитов не видно нигде. Смотрите reflog, находите хеш нужного состояния, делаете git reset --hard хеш — и всё на месте.

Что важно понимать. Записи хранятся ограниченное время и только локально. Но этого почти всегда хватает: катастрофу обнаруживают в тот же день.

• Возвращает то, что казалось потерянным
• Работает после reset, rebase и переключений
• Ничего не нужно настраивать заранее

• Только локально и ограниченное время
• Не поможет для правок, которые не были закоммичены
• Про неё вспоминают, только когда уже поздно

аварийная · оценка 9,1