Какви типове използвам в ежедневната си работа:
- постижение: Нова функция или подобрение на съществуваща функционалност. Например „feat(user): Добавете възможност за нулиране на парола.“
- корекция: Корекция на грешка или корекция на съществуваща функционалност. Например „fix(login): Коригиране на проблем, който пречи на потребителите да влизат.“
- преработване: Промени в кодовата база, които не добавят нови функции или коригират грешки, но подобряват структурата, четливостта или поддръжката на код. Например „рефакторинг(плащане): Опростете кода за обработка на плащанията.“
- стил: Промени във форматирането, стила или оформлението на кода, които не засягат функционалността на кода. Например „стил(потребител): Форматиране на страницата на потребителския профил.“
- тест: Добавяне или модифициране на тестове за съществуваща функционалност. Например „test(cart): Добавяне на тест за процеса на плащане на количката.“
- документи: Промени в документацията, като например актуализиране на README файлове или коментари на вграден код. Например „docs(auth): Актуализиране на документацията за удостоверяване.“
- скучна работа: Промени в процеса на изграждане, зависимостите или други задачи по поддръжката, които не засягат функционалността на кода. Например „chore(deps): Актуализиране на версиите на зависимостите.“

Обхвата

Обхватът не е задължителен и може да се използва, за да посочи коя част от кодовата база е била модифицирана. Например, ако сте променили функционалността за влизане, можете да използвате „auth“ като обхват.

Предметът

Темата е кратко резюме на промените, изписано в заповеден начин. Това означава, че темата трябва да започва с глагол в сегашно време и трябва да описва какво прави ангажиментът, а не какво е направил. Например, вместо да пишете „Коригирана грешка при влизане“, трябва да напишете „Коригиране на грешка при влизане“. Това прави съобщението за ангажимент по-активно и по-лесно за разбиране. Когато пиша съобщение за ангажиране, имам подсказка, когато съставям съобщение за ангажиране — „Ако приложа това ангажиране, то ще {вашето съобщение за ангажиране, което ще ангажирате}“.

✍️ Използвайте повелително наклонение в ангажимент

Ето пример за съобщение за семантичен ангажимент:

  • feat(auth): Добавете поддръжка за влизане в социални медии (#32124)
  • fix(cart): Коригиране на проблем с изчисляването на количката (#28567)
  • refactor(user): Refactor потребителски регистрационен код (#29745)
  • style(product): Форматиране на страница с подробности за продукта (#29812)
  • test(login): Добавете тест за валидиране на формата за вход (#29015)
  • docs(readme): Актуализирайте README с инструкции за инсталиране
  • chore(deps): Актуализиране на зависимостите на пакета (#30867)

Метаданните

Тази информация може да помогне за осигуряване на контекст и допълнителни подробности за направените промени. В моята компания, в която работя, SoftFormance използваме инструмента за управление на проекти Redmine и работим с билети. Винаги добавям номера на билета в метаданните. Освен това, ако направените промени не са обратно съвместими със съществуващия код, включването на бележка за това може да помогне да предупредите други разработчици за потенциални проблеми, които могат да възникнат при актуализиране на техния код.

Докато семантичните ангажименти предоставят структуриран и ясен начин за писане на съобщения за ангажименти на Git, можете също да добавите малко индивидуалност и забавление към ангажиментите си, като използвате емотикони.

Използването на емоджи в Git комити може да помогне за предаване на емоции, да добави хумор или просто да направи съобщенията ви за ангажименти по-интересни. Някои разработчици използват специфични емотикони, за да обозначат вида на промяната, която се прави, докато други ги използват като начин да добавят личен щрих към ангажиментите си.

Например, можете да използвате следните емотикони, за да представите различни типове промени:

  • 🎉 : За добавяне на нова функция или функционалност
  • 🐛 : За коригиране на грешка
  • 🔨 : За извършване на подобрения на кода или рефакторинг
  • 💄 : За извършване на козметични промени като актуализиране на потребителския интерфейс или код за форматиране

Можете също да използвате други емотикони, за да добавите хумор или индивидуалност към ангажиментите си, като например 🚀 за подобряване на производителността, 🤓 за добавяне на техническа документация или 🐢 за проблеми с бавната производителност.

Когато използвате емоджи в Git ангажименти, важно е да запомните да ги използвате умерено и да ги поддържате професионални и подходящи за контекста. Освен това не всички клиенти на Git поддържат емотикони, така че имайте предвид, че те може да не се показват правилно във всички случаи.

Като цяло използването на емотикони в Git комити може да бъде забавен и креативен начин да добавите малко индивидуалност към съобщенията си за ангажименти, като същевременно следвате най-добрите практики на семантичните комити.

Писането на семантични ангажименти може да помогне при отстраняване на грешки и сътрудничество с други разработчици в бъдеще. Когато работите по проект, наличието на ясни и описателни съобщения за ангажиране може да спести ценно време и усилия при идентифициране и коригиране на проблеми. Освен това може да улесни другите разработчици да разберат промените, направени в кодова база, което може да доведе до по-ефективно сътрудничество и комуникация.

Въпреки че може да отнеме известно усилие, за да създадете навик за писане на Semantic Commits, дългосрочните ползи го правят инвестицията си струва. Много проекти с отворен код в GitHub изискват използването на Semantic Commits, което прави важно умение за разработчиците да научат дали планират да допринесат за тези проекти или да работят съвместно с други разработчици. Като превърнат семантичните ангажименти в навик, разработчиците могат да подобрят качеството на своите Git комит съобщения и да улеснят разбирането и поддържането на техния код във времето.

P.S. Тази публикация първоначално беше публикувана на моя уебсайт — https://dmytrolitvinov.com/how-to-write-better-git-commits/