Всем привет, меня зовут Сергей Прощаев. Я руковожу направлением Java‑разработки в FinTech, а ещё помогаю начинающим специалистам осваивать тонкости профессии на курсах Отус. Сегодня поговорим о Git. Точнее, о том, как перестать его бояться и начать использовать так, чтобы коллеги (и вы сами) не краснели, глядя на историю ваших изменений.
Почему я решил написать эту статью? На любом курсе по разработке в Отус есть блок вебинаров по работе с Git. И в большинстве случаев основная сложность начинается здесь. Ветки называются «asdasd», коммиты — «правки», «ы», «апдейт», а в пулл‑реквесте висит 50 файлов с изменениями, половина из которых — случайно попавший туда мусор. И самое грустное, что многие даже не понимают, в чём проблема. «Ну работает же, чего вы придираетесь?»
Но в реальной команде такой подход приведёт к хаосу. Представьте, что вам нужно откатить изменение, которое сломало тесты, а все коммиты подписаны «fix» — попробуй найди нужный. Или вы мержите ветку, а там конфликты, которые не распутать, потому что никто не заботился об актуальности своей ветки. Git — это не просто хранилище кода, это инструмент коммуникации. И сегодня я покажу, как сделать эту коммуникацию эффективной.
Git — это не страшно, это просто граф
Прежде чем лезть в консоль, давайте договоримся о терминах. Git хранит историю проекта как граф коммитов. Каждый коммит — это снапшот состояния файлов, у него есть автор, дата, уникальный хэш и сообщение. Ветка — это просто указатель на конкретный коммит. Когда вы делаете новый коммит, указатель ветки автоматически перемещается на него.
Посмотрите на эту схему (я специально нарисовал её в Mermaid, чтобы вы могли вставить код в любой редактор и увидеть живой граф):
На рисунке 1 изображен пример графа коммитов: на main сделан начальный коммит, от него отходит ветка feature/login, в ней два коммита, затем на main добавлен ещё один коммит (исправление опечатки) и выполнено слияние feature/login.
Здесь всё просто: main (или master) — основная ветка, с которой обычно работают пользователи. feature/login — ветка для разработки новой функциональности. После того как фича готова, её вливают обратно в main. Именно так выглядит изолированная работа: вы не мешаете другим, другие не мешают вам.
Какими бывают ветки
В учебных проектах или на небольших задачах часто хватает одной основной ветки и нескольких тематических. Но в серьёзной разработке сложились модели ветвления, самая известная из которых — Git Flow. Она предписывает иметь долгоживущие ветки main и develop, а также временные: feature/*, release/*, hotfix/*.
main — всегда содержит стабильный, готовый к выкладке код
develop — ветка интеграции, куда сливаются все новые фичи
feature/* — каждая новая функциональность разрабатывается в своей ветке от develop
release/* — подготовка к релизу (исправление багов, документация)
hotfix/* — срочные исправления на main
Звучит сложно, но на практике для новичка главное понять разницу между долгоживущей(main, develop) и временной веткой (ваша задача). Временная ветка живёт ровно столько, сколько вы делаете задачу. Как только её вмержили, ветку можно (и нужно) удалить — и локально, и на сервере.
На курсах «OTUS» мы обычно используем упрощённый вариант: есть main и от неё отходят ветки для домашних заданий с префиксом homework/. Например: homework/lesson1-git-basics. Это сразу говорит, что в ветке, и облегчает жизнь ментору.
Создаём ветку: от слов к делу
Давайте сделаем небольшую тренировку и пройдемся по основным шагам, через которые проходит любой начинающий разработчик на курсах OTUS.
Допустим, вы клонировали репозиторий курса. Убедитесь, что вы находитесь на актуальном main:
git checkout main git pull origin main
Теперь создаём новую ветку для своего задания. Рекомендую сразу переключиться на неё:
git checkout -b homework/lesson1-git-basics
Флаг -b создаёт ветку и переключает на неё. Если хотите сделать то же самое по шагам:
git branch homework/lesson1-git-basics # создали ветку git checkout homework/lesson1-git-basics # переключились
Современный Git (версии 2.23+) предлагает более понятные команды:
git switch -c homework/lesson1-git-basics
Как назвать ветку — вопрос договорённости в команде. Встречал разные стили: feature/JIRA-123, bugfix/issue-description, username/task-name.
Главные правила: никаких кириллицы и пробелов, используйте дефисы или слеши для разделения слов. Например: feature/add-user-service, hotfix/fix-npe, homework/03-junit-tests.
Коммиты: каждый шаг должен быть осмыслен
Итак, вы написали код для своего задания. Например, простой класс User:
package ru.otus; public class User { private String name; private String email; public User(String name, String email) { this.name = name; this.email = email; } // ... }
Как сохранить изменения в Git? Сначала добавляем файлы в индекс (staging area):
git add src/main/java/ru/otus/User.java
Можно добавить все изменённые файлы сразу:
git add .
но будьте осторожны — так вы можете случайно захватить временные файлы или мусор. Лучше явно перечислить то, что должно попасть в коммит.
Теперь создаём коммит:
git commit -m "Add User class with name and email"
Но давайте остановимся и подумаем: хорошее ли это сообщение? Оно отвечает на вопрос «Что сделано?» — добавлен класс User. Но не отвечает на вопрос «Почему?». Если коммит маленький и очевидный, можно ограничиться одной строкой. Но представьте, что вы возвращаетесь к этому коду через полгода и видите сообщение «Add User class». Вы уже не вспомните, зачем понадобился этот класс и почему поля именно такие.
Поэтому в сообщениях коммитов придерживайтесь best practices:
Заголовок (первая строка) — не длиннее 50 символов, пишется в повелительном наклонении («Add», «Fix», «Update»), без точки в конце. Это как тема письма.
Если нужно больше деталей, после пустой строки идёт тело сообщения. В нём можно описать мотивацию изменений, ссылки на задачи, важные технические нюансы. Ширина строки тела — до 72 символов для удобства чтения в консоли.
Хороший тон — привязывать коммит к задаче в трекере (например, JIRA-123: Add validation for email).
Пример хорошего сообщения (вводится через git commit без флага -m, чтобы открылся редактор):
Add User class for authentication module - User stores name and email - Email must be unique in the system (will be enforced by DB) - This class is part of the new login flow described in #TASK-456 The previous implementation used a separate profile class, but we need a single entry point for user data.
Есть и более формальный подход — Conventional Commits. Он предписывает использовать префиксы типа feat:, fix:, docs:, style:, refactor:, test:, chore:. Это особенно полезно, если вы потом автоматически генерируете changelog. Для домашнего задания это может быть избыточно, но на работе такой стиль часто входит в стандарт команды.
Основная идея: сообщение коммита начинается с префикса, который обозначает тип изменения, затем двоеточие и пробел, а после – краткое описание. Иногда можно добавить область (scope) в скобках после типа, например feat(api): add new endpoint.
Вот расшифровка самых частых префиксов и примеры к ним:
Префикс |
Когда использовать |
Пример сообщения |
feat: |
Добавление новой функциональности для пользователя (новая фича, новый модуль, новый метод в публичном API) |
feat: add password recovery by email |
fix: |
Исправление ошибки (бага). |
fix: handle division by zero in calculator |
docs: |
Изменения только в документации (README, Javadoc, комментарии в коде). |
docs: update project setup guide |
style: |
Правки форматирования, отступов, лишних пробелов, точек с запятой – всё, что не меняет логику кода. |
style: reformat code according to google style guide |
refactor: |
Изменение кода, которое не исправляет ошибку и не добавляет новую функциональность (например, переименование переменной, выделение метода). |
refactor: extract email validation to separate method |
test: |
Добавление или изменение тестов (юнит-тесты, интеграционные тесты). |
test: add negative scenarios for login |
chore: |
Обновление вспомогательных инструментов, зависимостей, конфигурации сборки – всё, что не относится напрямую к коду приложения. |
chore: update maven compiler plugin to 3.8.1 |
Эти префиксы – ядро, но есть и другие: perf: (улучшение производительности), ci:(изменения в CI/CD), build: (изменения в системе сборки), revert: (откат коммита). Для начала достаточно освоить основные семь.
Как это выглядит на практике?
Допустим, вы пишете домашнее задание и добавляете класс User. Логично сделать коммит типа feat. Но если вы потом заметили, что забыли обработать пустой email, и исправляете – это fix. А если просто перенесли метод в другой класс без изменения логики – refactor.
git commit -m "feat: add User class with name and email" git commit -m "fix: validate email format in User constructor" git commit -m "refactor: move email validation to EmailUtils"
Теперь, взглянув на историю, любой сразу поймёт, что происходило. А если подключить инструмент вроде standard-version, он на основе этих префиксов автоматически увеличит версию и сгенерирует красивый changelog.
Однажды потратил полдня, разбираясь, почему упал билд после мержа. Оказалось, коллега сделал коммит с сообщением «правки» и случайно удалил важную зависимость в pom.xml. Если бы он написал «Remove unused dependency», я бы даже не открывал тот коммит, потому что «unused» не должно ломать сборку. А так пришлось вручную перебирать все «правки». С тех пор я требую от команды осмысленных сообщений.
Pull Request: как показать результат
Вы сделали несколько коммитов в своей ветке, всё проверили локально. Теперь нужно отправить задание на проверку преподавателю. Для этого вы пушите ветку в удалённый репозиторий:
git push origin homework/lesson1-git-basics
Если ветки на сервере ещё нет, Git создаст её. Теперь идём на сайт GitHub (или GitLab, Bitbucket) и видим красивую кнопку «Create pull request», как показано на рисунке 2 и нажимаем.
Важно! Перед созданием PR убедитесь, что ваша ветка не отстала от основной. Пока вы писали код, в main могли добавиться новые коммиты. Если не подтянуть их, после мержа могут возникнуть конфликты. Поэтому я всегда делаю перед пушем:
git fetch origin git rebase origin/main
Эта команда переставляет ваши коммиты поверх последних изменений в main. Если есть конфликты, вы решаете их локально, а не в PR. Это правило профессионалов.
Теперь заполняем описание PR. Оно должно быть информативным: что сделано, как проверить, есть ли особенности. Пример:
Название PR: Homework 1: Git basics (User class)
Описание:
Реализован класс User с полями name, email.
Добавлены тесты (если были).
Задание выполнено согласно требованиям: ...
Как проверить:
Запустить тесты: mvn test
Убедиться, что код компилируется.
В PR вы можете указать ревьюера (преподавателя), добавить метки, прикрепить скриншоты. Главное — не оставляйте описание пустым.
Что еще запомнить?
Перед коммитом всегда проверяй, что попадает в индекс (git status).
Не забывай про .gitignore — туда нужно добавить папки IDE, результаты сборки (target/, build/), логи.
Описание PR должно быть понятным, чтобы ревьюеру не приходилось гадать, что ты хотел сделать.
И главное: ревью — это не критика, а помощь. Комментарии преподавателя делают код лучше.
Git — это не просто команды, это культура разработки.
Что дальше? Конфликты, rebase, работа в команде
В этой статье затронул лишь базу, но её достаточно, чтобы начать уверенно выполнять домашние задания и не пугать коллег. Однако в реальной работе вас ждут и конфликты при слиянии, и перебазирование, и работа с несколькими удалёнными репозиториями, и многое другое.
На курсе «Автоматизация тестирования на Java. Базовый уровень» как раз разбирается база: Java, автотесты для интерфейса и API, ключевые шаблоны и инструменты, с которыми тестирование становится воспроизводимым и внятным. Для знакомства с форматом обучения и экспертами приходите на бесплатные уроки:
19 марта, 20:00. «Основы многопоточности в Java. Асинхронные методы». Записаться
23 марта, 20:00. «ИИ в автотестах: помощник или угроза?». Записаться
Полный список бесплатных уроков марта по всем ИТ-направлениям смотрите в дайджесте.
Комментарии (16)
Emelian
12.03.2026 18:23Git для новичков
Недавно, была опубликована похожая статья: «Гид по Git – глазами бывшего джуна» в https://habr.com/ru/companies/surfstudio/articles/973304/ .
Ни там, ни здесь я так и не понял, нужен ли Git для разработки индивидуальных пет-проектов? «Там» доказывали – что нужен, но, когда возражал, что «лично мне – нет», почему-то обижались, естественно, с минусованием, как же без него доказать свою правоту?
По крайней мере, я использую альтернативу – «итерационно-модульное» программирование, которое меня вполне устраивает. Если бы я увидел нормальные аргументы в пользу Гит, то мог бы поэкспериментировать в этом направлении, но, пока, таких аргументов нет, поэтому, остаемся все, при своем собственном мнении, как всегда.
Alex_Pvk
12.03.2026 18:23Привет!
Я думаю тут вопрос больше должен ставиться так: подразумевает ли твой пет проект дальнейшее использование совместно с кем-то. Ведь Git берет свое начало именно с этого)
Но думаю не будет лишним делать через Git, как минимум для возможности отката до определенного состояния своего изначального кода или экспериментов или тестов в другой ветке, плюс используя удаленные репозитории ты можешь значительно облегчить себе жизнь, если тебе надо быстро перенести свои наработки на другую машину.
«Итерационно-модульное программирование» - это же, по сути, и есть то, что Git формализует: итерации = коммиты, модули = ветки. Только Git ещё и запоминает каждый шаг
Рекомендую все-таки изучить такой инструмент как Git(кстати придумал его гениальный человек), там найдешь много интересного, например git revert.
УдачиEmelian
12.03.2026 18:23Привет!
Привет! Спасибо, за подробное изложение своей точки зрения.
Я думаю тут вопрос больше должен ставиться так: подразумевает ли твой пет проект дальнейшее использование совместно с кем-то. Ведь Git берет свое начало именно с этого)
Скорее, нет, чем да. Но, даже если, вдруг, такая необходимость возникнет, то, опять же, предпочел бы собственный путь.
На примере моей обучающей программы, реализованной, с большим трудом, в первой версии, при определении ее архитектуры для второй версии, которой я начал заниматься, я предполагаю использовать следующее:
Допускаем наличие архитектора ПО и членов команды программистов.
Архитектор создает прототип проекта, в котором разрабатываемые модули (по сути,, классы) имеют чисто формальные реализации., т.е., набор публичных функций с пустым телом. При этом, вызовы этих публичных функций в главном модуле приложения (для проектов на C++ / WTL это будет CMainFrame), за разработку которого отвечает архитектор, должны быть зафиксированы явно (скажем, в обработчиках сообщений либо в функциях потоков).
Этот проект, с «пустыми» модулями (классами) компилируется, но, по сути, ничего, особо не делает. Только отображение главного окна, его полного меню, но без реальной работы (разве что, просто вывод мессаджбокса с указанием выбранного пункта меню), тулбара и статусбара.
Этот прототип проекта раздается всем членам команды, с указанием, кому, какой модуль (класс) развивать, т.е., заменять пустые тела функций их реальным содержимым. При необходимости, программисты-исполнители могут добавлять приватные функции и данные, на свое собственное усмотрение.
При завершении работы над модулем, программист отправляет архитектору (это может быть и удаленная работа) свою полную реализацию класса, за который он ответственен.
Архитектор, делает замену формального модуля на реальный и осуществляет общее тестирование. При необходимости, вносит изменения в работу команды.
Принятый, в первом приближении, реальный модуль может стать доступным для всех членов команды и тестировщиков.
Если реальный модуль обновляется, то его новая версия замещает старую, путем простой замены файлов.
Задача архитектора состоит в том, чтобы эта схема, либо аналогичная, принятая всеми членами команды, работала.
Как-то так.
Соответственно, если эксперимент по имитации командной работы, при создании второй версии моей программы, покажет свою эффективность, то продолжу использовать этот метод, иначе буду смотреть в сторону Гита либо еще чего-то в этом роде.
Но думаю не будет лишним делать через Git, как минимум для возможности отката до определенного состояния своего изначального кода или экспериментов или тестов в другой ветке, плюс используя удаленные репозитории ты можешь значительно облегчить себе жизнь, если тебе надо быстро перенести свои наработки на другую машину.
Но, у меня и так проблем не возникало. Например, при создании графической обертки для консольного загрузчика любимых видосиков с «народного» видеохостинга ( https://habr.com/ru/articles/955838/ ), у меня получилось 24 итерации для, в принципе, не слишком сложной программы. Поэтому, «откатываться» можно куда угодно, причем логически, а не по временным меткам.
«Удаленные репозитории» для меня – экзотика, с которой не хочется иметь дело, только локальные, только хардкор!
Перенос с машины на машину тоже не проблема. На работе у меня была одна операционная система и версия VS C++, дома – другие, однако, спокойно, переносил каждый день с помощью «флэшнет», пока была в этом необходимость.
«Итерационно-модульное программирование» - это же, по сути, и есть то, что Git формализует: итерации = коммиты, модули = ветки. Только Git ещё и запоминает каждый шаг
У меня нет необходимости запоминать «каждый шаг». Думаю, это лишнее. Я делаю упор на программную логику, а там важнее не шаги, а изменения состояния работы программы.
Рекомендую все-таки изучить такой инструмент как Git(кстати придумал его гениальный человек), там найдешь много интересного, например git revert.
Верю, что «гениальный»! Только мне этого мало, куда, важнее, смысл. Пока, смысла в Гите я, для себя, лично, откровенного говоря, не вижу.
Удачи
Взаимно! :)
Tony-Sol
12.03.2026 18:23А что тогда используете для версионирования и/или обеспечения переносимости своих пет-проектов если не гит?
Emelian
12.03.2026 18:23Для версионирования – итерации. Беру прототип и добавляю туда какой-то локальный функционал. Работает? Хорошо! Делаю копию проекта и работаю уже с ней. В предыдущей итерации описываю в doc-файле, что там реализовано, какие возникли проблемы и что собираюсь делать дальше. И так, небольшими порциями, логически изменяемого функционала, двигаюсь от одной итерации к другой. Если возникает «затык», что бывает регулярно, просто возвращаюсь к предыдущей, рабочей версии проекта и начинаю все заново.
Переносимость обеспечиваю настройкой файлов проекта для Visual Studio C++ (с использованием WTL). Предпочитаю старые версии «Студии», как более привычные и легкие (на недостаток функциональности не жалуюсь). На работе была 2010-я, дома – 2013-я. В самом проекте присутствуют обе версии конфигурационных файлов, которые запускаю, в зависимости от ситуации.
Если на Гитхабе либо codeproject.com (сейчас этот сайт, после аварии на своих серверах – «лежит») имеется подходящий прототип на более высокой версии VS C++, то, стараюсь адаптировать этот код так, чтобы он работал, хотя бы на 2013-й версии. Чего, нередко, удается добиться. Если же нет, не страшно, ищу другой прототип.
Таки образом, без Гита я вполне обходился и обхожусь и, пока, не уверен, что он мне вообще когда-нибудь понадобится.
Tony-Sol
12.03.2026 18:23Делаю копию проекта и работаю уже с ней. В предыдущей итерации описываю в doc-файле, что там реализовано, какие возникли проблемы и что собираюсь делать дальше <...> Если возникает «затык», что бывает регулярно, просто возвращаюсь к предыдущей, рабочей версии проекта и начинаю все заново.
Ну то есть я правильно понимаю, что вместо нормального контроля версий, все держится на собственной памяти и директориях вида "Проект", "Проект (1)", "Проект (2)" и т.д.?
Emelian
12.03.2026 18:23Проект – один, итерации разные. В каждой из них есть doc-файл, с описанием изменений. Просматриваю эти файлы и выбираю нужную итерацию либо для рефакторинга, либо как прототип для другого проекта.
Как по мне – вполне нормально. Вы можете использовать Гит, кто вам мешает? А мне нравится мой вариант. Я, ведь, таким образом, написал уже не одну программу, но, необходимости что-либо менять здесь – не вижу.
Кроме того, для каждой итерации скомпилированы бинарники. Иногда, проще запустить и посмотреть их, чем читать текст в описаниях.
jlllk
12.03.2026 18:23Со стороны выглядит как "свой велосипед на квадратных колесах"
Emelian
12.03.2026 18:23Со стороны выглядит как "свой велосипед на квадратных колесах"
И что из этого следует? Устыдиться и бежать бегом делать «как все»? Тогда будет похоже на манипулирование. Достаточно сказать «фи» или «фу» и всё, товарищ начинает плясать под твою дудку. Классная, между прочим, идея. Иногда работает.
Однако, на серьезных людей такая аргументация не действует. А другой, похоже, у вас нет.
NoSkill24
12.03.2026 18:23Это просто неудобно. Для вас это удобно, потому, что вы привыкли к своему велосипеду. Git держит все эти ваши копии проекта и итерации в одной базе данных, и в одной рабочей директории. В ней вы сами документируете все изменения. В любой момент можете откатиться назад, посмотреть как работало, вернуться вперёд. Можете вести несколько экспериментов или итераций паралельно, и затем код объединить. И ещё много чего можно. Самая большая ошибка - предполагать, что Git нужен исключительно для совместной разработки. Профессиональное владение Git-ом сильно упрощает процесс управления кодом проекта, независимо от количества программистов вовлечённых в проект.
Emelian
12.03.2026 18:23Ну, хорошо! Посмотрим на это дело вашими глазами. Вот вы говорите: «Git держит все эти ваши копии проекта и итерации в одной базе данных». В какой? Хотя, лучше спросить: Зачем мне хранить итерации проекта в базе данных? Что это мне дает? Я понимаю, базе можно послать любой запрос и она даст «любой» ответ. Но, это будут только куски кода или весь проект целиком? В первом случае мне это неудобно, ибо привык воспринимать файлы с программами целиком. А, во втором – бессмысленно, я и так вижу свои итерации в отдельных каталогах.
Потом, как это влияет на оформление кода и как происходит взаимодействие с инструментами разработки? Т.е., добавляются ли метаданные в код? Меняется ли мой стиль оформления, поскольку, судя, по опенсорсу на Гитхабе, все используют «неправильную» стилизацию программного текста. Точнее, она мне просто не нравится. Ни в С++, ни в Питоне. Поэтому, предпочитаю собственное оформление.
В том же VS C++ как нужно устанавливать взаимодействие с Гитом? А в Питоне, особенно, когда я не использую никакие IDE для него? Как там с компиляцией и запуском на выполнение?
А есть еще расширения под старые версии Хрома, поскольку только там можно обходить современные ограничения для доступа к сайтам (классика: затруднение работы блокировшиков рекламы, загрузи данных с сайтов и т.п.). Как туда «прилепить» Гит? И нужно ли, когда сами скрипты, например, по обходу капчи, помещаются на экране целиком?
Далее, вот я сейчас экспериментирую с модульной структурой проекта. По сути, использую собственную концепцию. На первое место здесь встают вопросы архитектуры приложения, что сильно влияет на сам процесс программирования. Это уже не просто версии, откаты и «накаты», это постоянные изменения всей структуры проекта. Поможет ли мне здесь Гит? Не уверен, скорее, он просто будет путаться под ногами, мешая программированию.
Да, вы можете сказать, что на все вопросы дают ответы Ютуб, Интернет-1.0 или Интренет-2.0 (то бишь, ИИ-сервисы) плюс документация. Согласен, дают! Но, какой у меня стимул изучать все это? Только потому, что:
Профессиональное владение Git-ом сильно упрощает процесс управления кодом проекта, независимо от количества программистов вовлечённых в проект.
Возможно, но у меня и так нет сложностей в «процессе управления кодом проекта». Все отлично управляется и без Гита! А вот, если такие сложности возникнут, то тогда – да, появится стимул смотреть в его сторону. Как, например, появился интерес начать осваивать Питон, не потому, что он «моден», а потому, что для подготовки и обработки данных, в которых появилась острая необходимость, он гораздо лучше, того же С++.
А так, я не отрицаю пользы систем контроля версий. Но, в этом Мире есть много хороших инструментов, однако, если можно ограничиться минимумом из них, то зачем осваивать максимум? Впрок? Только, может и не пригодится. Я много что делал впрок в молодости, но, пригодились только считанные проценты.
sproshchaev Автор
12.03.2026 18:23Git для пет-проектов нужен не потому что «так принято», а потому что он избавляет от ручного копирования папок. С ним можно спокойно экспериментировать в ветках и возвращаться к рабочей версии за секунду. Ну и бэкап на Гитхабе бесплатный — если ноут упадёт - код не пропадёт. А когда привыкнете, потом в команде не придётся учиться с нуля.
Alex_Pvk
12.03.2026 18:23Сергей, благодарю за статью! Оставлю немного своих мыслей на подумать:
standard-version как инструмент устарел, рекомендую что-нибудь поновее, например release-please
Когда вы говорите про rebase на main, стоит упомянуть, что далее всегда нужен force push, иначе будет ошибка. Новичкам рекомендую git push --force-with-lease либо делать это через IDE
При первом пуше лучше привязывать локальную ветку к удалённой через git push -u. IDE делают это под капотом, но раз в статье всё руками — стоит показать
Модель Git Flow подана сжато — лучше почитать про неё отдельно (например тут)
В энтерпрайзе 50 символов для заголовка часто мало. Обычно формат такой: feat(ABC-123): описание из задачи — это упрощает поиск старых правок и сборку карт влияния
Ещё хотелось бы добавить: пишите footer в коммитах. Вам не сложно, а лиду приятно, особенно в аварийных ситуациях. Формат: Refs: #42 (ссылка на задачу) или Closes #42 (автоматическое закрытие issue)
Всем удобочитаемых комментариев и аккуратно оформленных ПР(или МР - как хотите=) )!
WebSerGe
12.03.2026 18:23Спасибо за статью, да, лучше бы картинку было показать, было бы более наглядно.
Git Flow как бы подходит только для проектов, где нужно версионирование. Если это сайт, то тут уже другое дело и не рекоммендуется. Vincent Driessen (создатель Git Flow) сам про это написал.
Но не смотря на это, я использовал его для веб девелопмента, так как он себя хорошо показал.
Единственный минус - новичкам трудно дается, поэтому новички читали в документации вводного боевого курса в нашу команды Git Flow/SourceTree или аналога/как писать коммиты/ссылка на баг-трекер/и т.п.
dproshchaeva
12.03.2026 18:23Сергей, тема просто огонь! Больно знакомая ситуация: видеть в логах «фикс» или «123» вместо внятного описания — это действительно стыдно, особенно в финтехе, где важна каждая деталь.
DmitryOlkhovoi
Ну тикет еще в название ветки или комита, чтобы с джирой синхронилось)