Привет Хабр!
Решил поделиться вполне элементарными, но такими полезными приемами работы с гитом, которые нарушаются постоянно не только новичками или молодыми сотрудниками, но и вполне опытными синиорами.
Сколько раз я про них в том или ином виде говорил уже сосчитать сложно и каждый раз появляется момент когда опять приходится повторять.
Погнали !
1. Писать fix, update, cleanup и думать, что этого достаточно
В моменте все понятно. Ты только что правил баг, задача открыта, коллега видел обсуждение в чате, CI мигнул красным, потом зеленым.
Через полгода fix уже ничего не значит.
Проблема не в том, что сообщение короткое. Проблема в том, что оно не дает контекста.
Хорошее сообщение коммита должно отвечать хотя бы на два вопроса:
что изменилось;
зачем это было нужно.
Сравните:
fix
и:
fix(auth): reject empty token before external call
Второй вариант не идеален, но он уже полезен. По нему можно понять область изменения, причину правки и найти связанную задачу. В blame, при разборе бага или при подготовке release notes это сильно экономит время.
2. Не писать номер задачи
Есть обратная ошибка: “сообщение хорошее, номер задачи не нужен”. Нужен.
Коммит без номера задачи в рабочем проекте быстро превращается в потерянный контекст. Код показывает, что поменялось. Сообщение коммита показывает краткий смысл. А задача в трекере часто хранит то, чего нет в коде:
почему вообще понадобилось изменение;
какие варианты обсуждали;
кто согласовал поведение;
какие ограничения были у бизнеса;
какие баги или обращения пользователей стояли за правкой.
Например, можно договориться о таком формате:
fix(dialogs): keep operator assignment after client reconnect
Refs: Task-42
Так лучше: смысл коммита остается в заголовке, а номер задачи лежит в метаинформации. Для человека читается чище: сначала что и зачем поменяли, потом ссылка на внешний контекст. Для инструментов тоже удобно. Git hook на commit-msg может отдельно проверить тип, scope, короткое описание и наличие Refs: Task-42 в footer’е.
Да, номер задачи сам по себе не заменяет смысл. Но и смысл без номера задачи теряет связь с большим контекстом. В команде лучше считать номер задачи обязательным: без него потом сложнее понять, почему изменение вообще появилось.
3. Делать один огромный коммит “за всю задачу”
Один коммит на 80 файлов трудно нормально проверить.
Ревьюер открывает diff и видит одновременно миграцию, рефакторинг, новую бизнес-логику, тесты, правку форматирования и удаление старого helper’а. При таком объеме сложнее понять, где меняется поведение, где просто перенос кода, а где потенциально опасное место. Откат тоже становится грубым: если сломалась только миграция, приходится разбирать весь коммит целиком.
Лучше коммитить атомарными шагами. Один коммит - одно законченное изменение. На практике не всегда получается идеально, но почти всегда можно выделить понятные этапы:
refactor(api): extract request validation helper (Task-42)
feat(api): add client reconnect handling (Task-42)
test(api): cover reconnect without new dialog creation (Task-42)
Такую историю проще ревьюить, тестировать и откатывать. Если проблема появилась на третьем шаге, можно вернуть один-два последних коммита и оставить предыдущие изменения на месте.
4. Коммитить слишком мелкую кашу
Атомарность не означает “коммит на каждую сохраненную строку”.
История вида:
add file (Task-42)
fix import (Task-42)
fix typo (Task-42)
fix test (Task-42)
fix test again (Task-42)
really fix test (Task-42)
тоже плохо читается. Для локальной работы такие шаги нормальны. Для общей ветки - обычно нет.
Перед push полезно посмотреть на последние коммиты:
git log --oneline --decorate -10
Если в истории много промежуточных технических коммитов, перед push ее стоит привести в порядок через rebase -i, fixup или squash. Цель не в том, чтобы скрыть процесс работы, а в том, чтобы в общей истории остались понятные изменения.
5. Смешивать фичу, рефакторинг и форматирование в одном diff
Это одна из самых дорогих ошибок для ревью.
Вы поменяли бизнес-логику на 20 строк, но заодно прогнали форматирование на 2000 строк. Или переименовали метод во всем модуле и рядом изменили условие в if. Теперь ревьюеру сложнее отделить изменения без влияния на поведение от изменений в логике работы кода.
Лучше разделять:
refactor(queue): rename assignment state fields (Task-42)
feat(queue): skip closed dialogs during assignment (Task-42)
test(queue): cover closed dialog assignment filtering (Task-42)
Механические изменения должны легко проверяться отдельно. Поведенческие - быть небольшими и заметными. Когда они смешаны, баги маскируются под “просто переименовал”.
6. Коммитить локальные настройки, мусор и секреты
В каждом проекте есть файлы, которые очень хотят случайно попасть в Git:
.env
local.conf
debug.log
tmp/
credentials.json
Иногда это просто шум. Иногда - утечка. Иногда - поломанный запуск у всей команды, потому что кто-то закоммитил путь вида C:\Users\vasya\....
Хорошая команда не полагается только на внимательность:
держит аккуратный
.gitignore;проверяет секреты в CI;
использует pre-commit hooks;
не хранит реальные токены в примерах;
регулярно смотрит, что именно попадает в diff.
Git отлично хранит историю. В том числе историю ошибок с секретами. Лучше не проверять это на себе.
7. Решать конфликт “чтобы компилировалось”
Конфликт в Git - это не раздражающий экран перед продолжением работы. Это место, где столкнулись два решения.
Плохой конфликт-резолв выглядит так: взяли свою версию, прогнали тесты на минимуме, отправили дальше. Или взяли чужую, потому что “так меньше красного”.
Правильный вопрос не “как убрать маркеры конфликта”, а “какой итоговый смысл должен быть у кода после объединения”.
Если конфликт неочевидный, полезно позвать автора второго изменения и пройти merge вместе. Часто за соседним куском кода стоит контекст, которого нет ни в diff, ни в названии метода. Десять минут разговора могут сэкономить несколько часов отладки после merge.
После сложного конфликта стоит отдельно проверить:
git diff
git diff origin/master...
И почти всегда запустить релевантные тесты. Конфликт может компилироваться и при этом ломать бизнес-логику.
8. Называть ветки как придется
feature/new, test, fix, my-branch, final-final, faeture/... - все это кажется мелочью, пока не попадает в CI, ссылки, автодополнение и командные инструкции.
Имя ветки должно помогать понять:
тип работы;
номер задачи;
короткую тему;
можно ли ветку удалить после merge.
Например:
feature/AF-1234-reconnect-dialog
bugfix/AF-2345-empty-token
chore/AF-3456-cleanup-old-fixtures
Не нужно превращать naming в религию. Но если каждый называет ветки как хочет, репозиторий постепенно начинает выглядеть как общий рабочий стол без папок.
9. Не проверять историю перед push
Перед push многие проверяют тесты, но не проверяют историю. А потом в общий MR улетает:
лишний WIP-коммит;
коммит без номера задачи;
случайный merge;
временный файл;
исправление из соседней задачи;
сообщение
fix review (Task-42).
Мой короткий чеклист перед push:
git status
git diff
git diff --staged
git log --oneline --decorate -10
И несколько вопросов:
все ли коммиты относятся к этой задаче;
понятны ли сообщения без устных пояснений автора;
есть ли номер задачи;
не смешал ли я независимые изменения;
не тащу ли я в MR чужую историю;
можно ли откатить отдельный шаг, не отменяя остальные изменения.
Такая проверка занимает немного времени, но снижает риск отправить в MR лишние коммиты, временные файлы или изменения из другой задачи.
Вместо вывода
Git сам по себе не наводит порядок в команде. Он просто сохраняет все, что мы в него кладем.
Если работать в спешке и без правил, история быстро покажет это: fix, потерянные задачи, грязный index, огромные коммиты, старые ветки, случайные merge и stash, который никто уже не рискнет открыть.
Хорошая история не обязана быть стерильной. В ней нормально видеть живую разработку: уточнения, откаты, неприятные фиксы после CI, маленькие шаги вперед и назад.
Но она должна оставаться читаемой.
Потому что через полгода в этот лог придет не абстрактный “разработчик будущего”.
Скорее всего, это будете вы. Уставший. В пятницу. С багом на проде.
И вот тогда коммит fix окончательно перестанет казаться безобидным.
Если статья понравилась, то велкам в мой блог!
Безопасных Вам Релизов!