Привет Хабр!
Решил поделиться вполне элементарными, но такими полезными приемами работы с гитом, которые нарушаются постоянно не только новичками или молодыми сотрудниками, но и вполне опытными синиорами.
Сколько раз я про них в том или ином виде говорил уже сосчитать сложно и каждый раз появляется момент когда опять приходится повторять.
Погнали !
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 окончательно перестанет казаться безобидным.
Если статья понравилась, то велкам в мой блог!
Безопасных Вам Релизов!
Комментарии (16)
Politura
01.06.2026 14:194. Коммитить слишком мелкую кашу
9. Не проверять историю перед push
Не понял, вы прям в мастер пушине чтоли? Если да, то вы нулевое и очень важное правило сами себе забыли написать. Если нет, то кому не плевать на историю ветки, которая автоматически будет удалена после слияния пул-реквеста?
rurikovich Автор
01.06.2026 14:19Отвечая на ваш вопрос : нет.
История ветки часто важна , как минимум во время работы над ней. И если товарищи по команде будут смотреть и если сам возвращаешься к своим же коммитам. Иногда приходится делать несколько шагов назад по ветке например.
Politura
01.06.2026 14:19Мы, возможно, о разных вещах говорим. Никто не спорит про важность истории мейна, я про другое.
Как обычно происходит работа: берешься за таску, делаешь локальную ветку и начинаешь коммитить в нее по ходу работы. Сколько там коммитов, на каждую строчку или нет, какие именно комментарии - все это совершенно не важно, все это короткоживущее и имеет смысл только для исполнителя пока работаешь над таской - часы, в крайнем случае несколько дней.
Когда все сделано - ветка пушится на ремоут сервер и создается пул-реквест, который уже оформляется по всем правилам.
Пул-реквест посмотрели другие разработчики и заапрувили - изменения мержатся в мейн, с ссылкой на тикет, с правильным комментарием, а ветка просто удаляется автоматически. Она нужна была только в контексте работы над тикетом.
Смысл в том, что пуши делаются только для этих веток работы над тасками. Никаких других пушей просто нет. В мейн (мастер) должен стоять запрет на пуш, туда изменения должны приходить только пул-реквестами. А если так, то нет никакого смысла проверять историю временной ветки перед пушем. И нет никакого смысла ограничивать себя в коммитах в эту временную ветку.
rurikovich Автор
01.06.2026 14:19тут видите зависит от специфики задачи. то что вы говорите на определенном подмножестве задач справедливо.
Иногда бывают ветки которые разрабатывают большую фичу или экспериментальный рефакторинг и по факту работа в них ведется коллективно: автор конечно есть, но по мере развития туда и остальные смотрят и больше того иногда неудачные шаги откатываются и ветка продолжается с удачного шага уже с другим подходом например.
в таком случае соблюдать правила есть смысл и в таких ветках.
В общем есть частные случаи где это применимо и где не применимо
fshp
01.06.2026 14:19Ветка удалится, но ее история то в мастере останется, если конечно вы сквошем не балуетесь.
Sap_ru
2. Совет отстал лет на пять и стал вредным? Писать номер таска в заголовке - плохая практика, о чём уже давно говорится во всех мануалах по Git и о чём регулярно напоминают его авторы! И даже очень хорошо объясняется почему. Таски нужно писать в полях метаинформации собщения и только там! Я, кстати, не полностью с этим согласен, но если уж говорить о современных "лучших практиках", то они именно такие.
3. Не все исправления можно декмопзировать, а периодический "тяжёлый" рефакторинг по-хорошему нужен любому серьёзному проекту: точно угадать структуру проекта и внутренние API с первой строчки - это из области фантастики. А искусственное/принудительное разбиение задачи иногда приводит к написанию большого количества "кода ради кода" (когда, который нужен только на период на рефакторинга). А это мало того, что в разы может увеличить трудоёмкость, но ещё и повышает вероятности ошибок.
4. "Комитить слишком мелкую кашу" Вот просто ради интереса - что делать если вы решаете какую-то задачу и увидели какую-то мерзкую опечатку или ошибку в форматировании? Или даже просто локальный бардак с white-space. Ведь вы же говорите, что комбинировать с другими тасками нельзя. Делать микрокомит из двух символов? Игнорировать? Я, вот, для себя даже не могу точный ответ дать, но обычно считаю наименьшим из зол добавление исправлений опечаток и форматирования к каким-то другим задачам. Ну или как-то их (опечатки и ошибки форматирования) комбинировать, но это в этом случае они теряются забываются и имеют тенденцию разрастаться.
5. Да, но в реальности при большом рефакторинге иногда приходится менять и форматирование, и структуру кода и даже процес сборки. И без этого нельзя получить даже минимально-компилируемую версию. Но в целом это конечно редкость. Но и когда говорят "нельзя", это тоже неправда, это же советы про которые "вполне опытные синьоры" забывают? А именно они и решают такого рода задачи, по идее. Аналогично, комбинация с предыдущим пунктом - что если при рефакторинге найдены минорные проблемы с форматированием, комментариями, опечатками? Править отдельными комитами? Но как же пункт 4?
8. Ну, какую схему бранчинга использовать это вообще сложный и местами религиозный вопрос. Как можно так однозначно говороть? Их же штук пять и у всех свои плюсы-минусы. Тем более что можно и всякие комбинации делать.
Короче, довольно странно эти рекомендации для "вполне опытных синьоров" читать, так как это в любом случае лишь общие рекомендации, которые совершенно точно будут (и должны) нарушаться в реальных проектах. Зачастую вижу людей, которые вот такие рекомендации считают неприрекаемыми правилами, высеченными в граните и унаследованными от утерянных предыдущих цивилаций, и в результате устраивающими какой-то невообразимый неподдерживаемый бардак в проектах или тратящих кучу ресурсов на бессмысленное следование каким-то рекомендациям в ущерб реальной разработке проекта.
Джунам, да, такое нужно регулярно показывать, но с оговоркой (если мы их реально учим), что это можно нарушать (как правило, не им), если есть чёткое понимание причины и последствий. Иначе вырастают "вечные джуны" которые без шаблонных практик и алгоритмов ни строчки кода написать не могут.
rurikovich Автор
"Не все исправления можно декмпозировать "
- по моей практике декомпозировать можно многое и в большинстве случаев это надо делать.
" что делать если вы решаете какую-то задачу и увидели какую-то мерзку опечатку или ошибку в форматировании? "
- в этом примере говорится о крайностях, что если одни разработчики склонны делаать один огромный коммит, то у других наблюдается обратное. и обеих крайностей лучще избегать
rurikovich Автор
"Писать номер таски" - тут акцент на то что его в принципе надо писать и связь коммита и таски в трекере крайне полезна. Очень много встречал что его не пишут ни в сообщении ни в метаинформации совсем ни где.
Но спасибо дополню, что самый правильный вариант писать номер в метаинформации
Sap_ru
А я вижу, что иногда на ранних стадиях лучше периодически тормозить разработку и приводить проект в порядок, перетряхивая внутреннюю структуру, чтобы не скатиться легаси через пол года разработки. Причём сейчас народ обычно сопротивляется и рассказывает про декомпозицию и необходимость того, чтобы всё обязательно компилировалось (им так диды завещали). В результате вязнут в неподъёмной трудоёмкости и скатываются в болото легаси, а потом, через каких-то 6 месяцев, рассказывают про "архитектурные ограничения проекта".
По мере развития и роста проекта это, само-собой, можно делать всё реже и реже - и дорого, и ошибки лишние не нужны. Разве что на уровне каких-то новых модулей.
rurikovich Автор
По моему опыту чем раньше заложить правильную структуру проекта в широком смысле тем лучше.может даже и перетряхивать не придется.
Sap_ru
Ну, это из области фантазий. Чтобы сразу угадать со всеми бизнес-требованиями, интеграциями и нагрузкой - так не бывает. Обязательно после начала коммерческой эксплутации оказывается, что в реальности всё не так, как казалось на этапе проектирования. Даже если изначальные требования были чётко прописаны и в них так же чётко попали с архитектурой, то по-моему ещё не было ни одного случая, чтобы по мере равёртывания системы эти требования три раза не менялись.
rurikovich Автор
тут на все 100% согласен.
я скорее про то что есть минимальный набор хороших практик, принятых в рамках команды и вот его надо как можно раньше.
А то что бизнес тестирует гипотезы и реальность потребностей пользователей не знают даже сами пользователи - это факт и скорее всего придется что то менять в проекте по мере обнаружения требований.
ritorichesky_echpochmak
2. Нет уж, потрудитесь написать почему это плохо) Потому что "нам не нравится, у нас это в плохо читается когда прилетает строго как plain text письмо с патчем на e-mail" - это проблемы вполне конкретных луддитов, а не всея Интернета. Остальным вполне себе норм дёргать штатные штуки гита типа
А то и вовсе прямо в GitLab открыть линк вида gitlab/project/-/compare/PREV_TAG…LAST_TAG и прямо оттуда из списка коммитов скакать в таски, даже если они ведутся не в гитлабе (минимальной интеграции через Custom Issue Tracker уже достаточно чтобы сильно упростить жизнь).
А то и вовсе вывести список "чем занимался" за последние несколько дней и прямо из списка скакать по нужным таскам и трекать время. Например таким алиасом
Опять же сильно мотивирует не лепить 100500 тасок в один коммит
@Politura ветка пушится и... команда видит все коммиты, ведь Git прекрасно хранит историю. Вы где-то забыли про squash написать или как минимум про интерактивный ребейз?
Politura
Не, мне просто без разницы если кто-то увидит промежуточные коммиты в ветке которая при мерже все равно удалится. :) За прошедшие годы никто никаких комментариев на их счет не делал, хотя там бывали коммиты с некрасивыми комментариями. :) Ну и самому мне лень смотреть такие чужие коммиты когда чей-то PR ревьюю, смотрю только конечные изменения, я полагаю большинство также делает.
Sap_ru
C метаинформацией (к которой относятся номера тасков и прочее) всё даже проще - для этого давно изобретены "commit message trailers". Вот пример прямо от самого git:
git commit -m "Fix timeout" -m "Issue-Tracker: #412" -m "Reviewed-By: Alice"git log --format="%(trailers:key=Issue-Tracker,valueonly=true)"
Именно trailers и есть сейчас рекомендуемый и удобный способ хранения дополнительной машино-читамой информации о комите.
И чтобы два раз не вставать имеет смысл сразу упомянуть notes, которые предназначены для хранения изменямой информации о комите (результат прохождения тестов, ход и результат review, примечания вида "не трогать! я отпуске и убью каждого, кто полезет в этот код своими грязыми руками до моего возвращения!" и т.п.). GitHub, кстати, активно этой фиче противится, так как она позволяет легко реализовать очень многое из того, что они через свои дополнительные API и web-интерфейс реализуют. А значит: "вещь хорошая, нужно брать".