Comments 16
Я сам-то сварщик не настоящий, но... А вот это вот всё, э, мозгоделание - оно реально нужно? Со стороны выглядит так, как будто фанат командной строки пытается заменить джиру гитом. Ну и поиграть мозговыми мышцами, конечно ("а я вон как умею! Сложно, но круто!")
Как ненастоящий сварщик ненастоящему сварщику, отвечу... Тут не мозгоделание. Если кто-то пишет код, то он его коммитит. Это также неизбежно, как восходы и закаты. Содержание статьи вкратце сводится к "раз уж нам всё равно приходится делать ветки и коммиты, так уж оформляйте описание по фиксированной форме, удобной для поиска; и убирайте за собой строительный мусор и опилки, когда сдаёте изделие".
Джира -- это для трека задач
Git -- это для трека кода
Задачи, как вы видите, разные. Наличие хорошо описанной задачи в джире не поможет вам найти коммит и его содержание (то есть комментарий коммита), где что-то сломали (никто же не ломает код просто так).
Если у вас опытная команда с единым пониманием ведёт -- подобные соглашения и так выполняются +/- без формальностей, но ни целиком опытной ни тем более когда много людей думают одинаково не бывает. Потому на помощь приходят регламенты, которые по сути своей фиксируют поведение в рамках рабочего процесса. Бонусом, кстати, упрощение онбоардинга (оно проще дать регламент по наймингу коммитов, чем словами объяснять, как тут принято)
Реально - делай хорошо, плохо не делай. И все.
Но это все максимально бесполезно если разраб хлеб, который не знает про атомарность, не расписывает коммит и вообще пользуется гитом больше как трекером задач совмешенный с инструментом заливки изменений.
Сама идея WIP хорошая, но она для структурированного и коментируемого кода. Если у вас пишут "как бог пошлет" то лучше оставлять все 1005000 коммитов процесса, просто саму работу производить ветками и потом сливать. Нужно весь отрезок - смотри ПР, нужно понять по какой причине поменяли четко это место - смотришь коммит этой точки.
Кстати, единое форматирование коммитов и хуки для упрощения этого самого - вот что дейсвительно важно при работе с git в боевом долгосрочном проекте. А так же просто политика написания развернутого коммита, а не отписки с "fix" и тд.
Мне кажется, данная статья может ввести в заблуждение новичков.
В git можно создавать папки и подпапки. Достаточно добавить
/в имени ветки и ваша ветка получит следующую структуруfolder/name.
Это не git поддерживает «папки и подпапки», а конкретные инструменты могут обрабатывать отдельные части имени ветки как названия директорий. Для самого git «/» — это просто допустимый символ в имени ветки.
Правильность сортировки задает тип ветки, который ставится в начале ее названия
Опять-таки, приведённый список соответствует префиксам коммитов, а в популярных системах управления кодом или в CI-пайплайнах скорее всего будут другие имена. Вы бы хотя бы gitflow-именование упомянули (feature, bugfix, hotfix, release). Его же скорее всего и на собесе спросят. Да и вообще, выражение «правильность сортировки задаёт тип ветки», как мне кажется, не следует говорить программисту — там же просто группировка и сортировка по алфавиту, а не какая-то особая уличная магия.
Для создания такого коммита достаточно добавить вашему сообщению к коммиту тип
WIP- и вуаля! - ваш коммит стал WIP'ом.
Аналогично, никакого специального значения «тип WIP» для git не имеет. Это просто кусочек текста коммита. Теоретически при создании пулреквеста его может использовать система управления кодом, а может и не использовать. Тогда с тем же успехом там могла быть подстрока [Do not merge] или вообще !!!НЕ МЕРЖИТЬ!!!.
Это не git поддерживает «папки и подпапки», а конкретные инструменты могут обрабатывать отдельные части имени ветки как названия директорий. Для самого git «/» — это просто допустимый символ в имени ветки.
Если вы создадите ветку с указанием / в ее имени, то в папке .git/refs/heads будет создана папка с тем именем, которое вы указали в названии ветки перед /
Опять-таки, приведённый список соответствует префиксам коммитов, а в популярных системах управления кодом или в CI-пайплайнах скорее всего будут другие имена. Вы бы хотя бы gitflow-именование упомянули (
feature,bugfix,hotfix,release). Его же скорее всего и на собесе спросят.
Как было сказано в статье, типы вы можете изменять, дополнять, объединять в зависимости от ваших предпочтений. Хотите идти по gitflow и использовать feature вместо feat, bugfix вместо fix? Не вопрос! Вас никто в этом не ограничивает. Я лишь показал то, как эта система типов может выглядеть.
Что касательно веток с названиями release, stage, main и т.д. - ветки с таким именованием создаются не от задачи, а от предпочтений к организации общих веток, которых вы придерживаетесь в команде. В статье я сосредоточился именно на именовании веток от созданных задач.
Да и вообще, выражение «правильность сортировки задаёт тип ветки», как мне кажется, не следует говорить программисту — там же просто группировка и сортировка по алфавиту, а не какая-то особая уличная магия.
Здесь речь идет про визуальную сортировку. Вам самим будет проще понимать к какому типу относится ваша ветка если вы правильно задали ей имя.
Аналогично, никакого специального значения «тип WIP» для git не имеет. Это просто кусочек текста коммита. Теоретически при создании пулреквеста его может использовать система управления кодом, а может и не использовать. Тогда с тем же успехом там могла быть подстрока
[Do not merge]или вообще!!!НЕ МЕРЖИТЬ!!!.
Тип WIP для коммита нужен исключительно для вас, что бы вы понимали, что задача еще не завершена. Вы в праве использовать любое название и тип для вашего WIP-коммита. Хоть "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn". Если, конечно, сами не запутаетесь. Главное что бы WIP-коммит с таким названием потом не попал в общую ветку.
Спасибо за статью, было интересно почитать!
Выражу своё субъективное мнение на тему именования веток / тасок. В случае, когда дело доходит до автоматизации (и такое есть), очень кашерно иметь чёткую и структурированную логику в именовании. И как правило, банального DEV-1234 бывает достаточно. Теперь касаемо того, как это было на моей практике. Коллега вводит в инструментарии описание к спринту, добавляет задачи и создаёт таски в Jira, Confluence (в ней было как описание работ для инженеров, так и описание к тому, что входит в таску/релиз и т.д.), а далее в Git просто создавались ветки.
Добрый день! Можете рассказать о методиках или может реальные кейсы работы с git репозитарием, оформленным с таким соглашением о наименовании? Ну т.е. есть репозитарий, все ветки и коммиты оформлены так, как описано в статье. Что дальше, кие преимущества это даёт?
Поясню интерес. Пару лет назад пытался внедрить принципиально похожее соглашение, но... Через год отменил за ненадобностью.
Выяснилось, что префиксы в именах веток не несут полезной информации: уже через месяц восстановить полезную информацию невозможно. Ну да, это был какой-то багфикс. А это - новая фича. Смысл решавшейся задачи все равно возможно восстановить только найдя связанную в трекере задач. Поэтому сейчас вернулись к имени ветки - номер и название задачи.
С wip тоже не понятно: если они не будут в общих ветках, такая разница как из наименовать? Лишь бы автору коммиов самому не запутаться.
В общем, если есть реальный кейс, зачем оно нужно, кроме красивой и строгой формализации(избыточной и бесполезной?) - буду рад послушать
Эти префиксы становятся полезны в рамках девопс-процессов. Например, сразу видно, что `hotfix` должен мержиться в релизную ветку, которая, собственно, как `release` помечена. Можно какие-то разные пайплайны в CI/CD запускать в зависимости от префикса (например, автоматически инкрементить минор- или патч-версию — но это не очень хорошо в общем случае).
Мне кажется, вы перепутали хабр с внутренней документацией. Сколько не видел проектов, как внутренних, так и внешних, у каждого свой взгляд на вот это все. Кто-то пользуется всеми новыми свистелками и перделками, кто-то нет.
Как-будто новичок открыл для себя хорошо-структурированный и регламентированный проект и начал проповедовать, как надо, забыв или не зная, что многое из упомянутого в статье определяют выбранные инструменты, которые во многих других проектах попросту не используются.
В одном вы правы, у каждого свой взгляд на то, как вести проект, оформлять ветки, коммиты и т.д. Я предложил свое видение этой картины. Как по мне, весьма структурированное и уменьшающее хаос в дальнейшей поддержке. Если у вас есть свое видение на то, как можно улучшить работу и вы готовы поделиться своими практиками, то я буду только рад ознакомиться с такой информацией
В некоторых публичных репах видел похожее.
На работе просто добавляем префикс номера задачи в коммите
типа
T-224: add metrics for orders
Нет. Писать в коммите что было сделано все равно что писать "увеличение на единицу" перед i++. То есть абсолютно бесполезно. Писать надо почему или зачем так было сделано - этого зачастую так не хватает!
Возникло много вопросов по формированию имени ветки и самих веток.
Работаете вы по таске 123, и в рамках этой таски вам нужно внедрить какую-то новую фичу. Создаём ветку feat/123-blah-blah. Фичу закончили, хотите документацию обновить — предлагается создавать ветку doc/123-blah-blah? В ходе работы с документацией понимаем, что нужно кое-где поправить оформление, предлагается создавать отдельную ветку style/123-blah-blah ? Или идти к PM за таской 124-style-blah и создавать уже с новым номером? Пока переделывали стиль, нашли баг и решили пофиксить — возвращаемся в ветку feat или создаём новую fix?
В общем, к чему я это всё — я не вижу смысла дробить ветки по типам, типы у нас уже есть в заголовке коммита. Скакать между ветками — то ещё удовольствие. Да, есть worktree, но если вы хотите складную структуру коммитов, то важно не забывать обновлять каждую из веток. А если ещё и не один работаете в ветках (такое бывает, да), то запутаться в этом многообразии проще некуда. Может я чего-то не понимаю, но выглядит скорее как bad practice.
Git. Руководство по оформлению веток и коммитов