Я полагаю вы уже знакомы с git. Чтобы не привело вас сюда, добро пожаловать и надеюсь найдете все, что вам необходимо знать.
Кратко о Git
У нас есть большие проекты, в которые мы коммитим, Git помогает разработчикам управлять различными коммитами и объединять их в единое целое. Он также помогает контролировать версии проектов, являясь системой контроля версий. Это странное определение, но это лучший способ, которым я мог объяснить Git.
Обычно когда говорят о Git имеют в виду DevOps инструмент для управления исходным кодом. Это бесплатная, с открытым исходным кодом система контроля версий для маленьких и очень больших проектов.
Прежде чем продолжить, я рекомендую вам немного ознакомиться с рабочим процессом git здесь
Git коммиты
Коммиты Git представляют собой снимок (snapshot) текущего этапа/состояния кода проекта. Это позволяет системе поэтапно сохранять изменения.
Коммиты используются для отслеживания изменений в проекте во времени, а также помогают выделить основные стадии проекта. Коммиты можно применить для отслеживания производительности и KPI команды.
Промышленный стандарт коммитов Git
Я предпочитаю называть это как git коммиты. Они не должны фиксировать сообщения с очень сложными терминами, должны быть читаемыми и понятными людям, которые незнакомы с кодом.
Почему важно стандартизировать коммиты
Важность заключается в том, чтобы по вашему комментарию к коммиту можно было понять, какие изменения были сделаны. Это также должно помочь новым участникам проекта лучше понять смысл коммитов. Вы должны знать зачем человек его сделал и какие последствия это вызовет.
Ваш комментарий к коммиту должен быть:
Понятным
Достаточным
Однозначным
Прежде чем создать комментарий к коммиту, вы должны подумать:
Зачем я добавил этот коммит
Какие изменения вносит коммит
Необходимы ли изменения
Решают ли изменения какую-либо проблему или он ссылается на какие-либо внешние ссылки или часть кода
Промышленный стандарт написания комментария к коммиту, который мы будем рассматривать:
<type>[optional scope]: <description>
[optional body]
[optional footer]
Различные стандартизированные типы коммитов представлены ниже:
fix: коммит, который устраняет баг
feat: коммит, который содержит новый функционал
chore: коммит, который не устраняет баг и не вносит новый функционал, а модифицирует или обновляет зависимости
refactor: этот коммит содержит рефакторинг, который включает рефакторинг кода или изменения
docs: этот коммит изменяет документацию, readme.md или markdown файлы.
style: коммит, который вносит изменения в оформление кода
test: коммит, который изменяет тестовый файл, включая изменения
perf: коммит, в котором улучшается производительность
ci: коммит, в котором содержатся изменения в интеграции CI в файлах или скриптах
build: это файлы, которые включают файлы сборки и зависимости
revert: коммит, который сигнализирует об откате к предыдущему коммиту
Например:
feat: Добавление кнопки вывода средств на домашней странице
Вы также можете добавлять в коммиты разные эмодзи, которые относятся к определенным типам. Подробно здесь.
????: Исправлена контактная форма
✨: Добавление кнопки вывода средств на домашней странице
Заключение
Умение полученное в этой статье прокачают вас и сделают вашу кодовую базу более организованной. Это важно для фиксации и отслеживания изменений, которые вы вносите.
Когда ваш код становится легаси кодом и новый разработчик работает с ним, комментарий к коммиту облегчит ему задачу понимания кодовой базы, даже когда вас нет рядом.
Если у вас есть предложения как улучшить коммиты, прошу поделиться в комментариях ниже.
Я надеюсь мы все узнали что-то из этой статьи, как улучшить наши комментарии к git коммитам.
Комментарии (15)
AndyPike
24.06.2022 22:42+4На практике, по крайней мере у меня, не работает.
Из опыта в последних двух компаниях:
1. На прошлой: Когда ты работаешь со своей веткой, то сам себе выбираешь формат, который понятен именно тебе. Там может быть и помодульно, и тупо 'rebase' или 'daily fix', этого ни кто не увидит. В процессе можешь откатится куда угодно. Когда закончил работу, сквошишь всё в один коммит с названием тикета.
2. На текущей: Название коммита - по шаблону `{ticketName} - {ticketTitle}`. Коммиты накатываются через git commit --amend (хотя squash тоже работает).
В обоих случаях - есть принятые правила в компании. Всех промежуточных коммиты, по окончанию работы, нигде больше не будет, никого не интересует твой личный информационный мусор.
black1277
24.06.2022 23:49Тоже чаще всего работаю по первому варианту. Через --amend - только если для себя что-то делаю.
gxcreator
25.06.2022 01:59Обычно так же, свободный формат до пуша мерж реквеста, перед пушем что-то типа git rebase -i HEAD~4 и squash с более цивильным описанием.
hrozhek
27.06.2022 10:01Согласен с вашим комментарием. Хочу дополнить, что в неидеальном мире иногда не создаются сабтаски под мелкий рефакторинг, например, и встречается такая структура иногда `{ticketName} - {ticketTitle} // {whatWasDone}`. Либо задача бьется на сабтаски, а в процессе выясняется что они сильно связаны (либо просты, чтобы тратить время на переключение контекста) и делают их де-факто в одной ветке. Опять же, это костыль о разумности, балансе и управлении разделением на подзадачи, который в идеальном мире вроде как не нужен.
QuAzI
24.06.2022 22:52+9Немного притомило это бездумное повторение Conventional Commits, которое плохо приживается в командах, потому что внезапно выясняется, что коммит делает какую-то фичу которая например размазана на кучу скоупов, да ещё этот бесполезный "fix:" говорящий что масло-то, оказывается, масляное, после чего читаешь всякую фигню типа "[fix] small fix on orders view", "fix: orders controller fix" и прочее ехал фиксик через фиксик. А заголовок коммита очень сильно ограничен, туда и просто текст "что делал" нормально не влезает. Ну и, конечно, все почему-то ленятся написать что круто было бы где-то и номер задачи тоже писать (половина тоже любит делать это впереди). А потом ещё как-то нужно отсматривать всю эту портянку, а то что написано в тушке далеко не всегда удобно читать (--oneline или всякие гит-клиенты с гуями схлопнут это). Ну и, конечно, текст такого коммита (его ПОЛЕЗНАЯ и СОДЕРЖАТЕЛЬНАЯ часть) будет не видна во всяких полуклиентах встроенных в IDE, потому что там места ещё меньше.
Поэтому в первую очередь пишется, а что вообще вы там делали, плюс номер задачи в трекере. И только потом всякие ваши хотелки, костыли, полутеги и прочий жир.
И такие коммиты, где написано что делалось и нафига (номер таски) отлично потом выгружаются вполне себе штатными командами типа `git shortlog --no-merges HEAD --not ${prev_tag}` в красивый change log к релизу, без лишних скриптов, костылей и мусора. И номера тасок в этом красивом чейнджлоге, внезапно, превращаются во всяких гитхабах в классные прямые ссылки на таски.
Вместо того чтобы костылить эти ужасы, лучше освоить штатные фичи гита или хотя бы поставить git-клиент, например GitExtensions, который умеет в кучу интеграций (в т.ч. переходы по номеру таски прямо в трекер, причём в любой, в т.ч. в жиру) и в котором сразу будет понятно, почему лапша в тасках - это не для людей, а раз это не для людей, то внедрять и пользоваться этим будет боль, страдания и сопротивление
gxcreator
МГИМО финишд?
black1277
Как тебя зовут Булат Булагур?
Булат Булагур!