Comments 14
По поводу работы с гитом.

На мой взгляд, у вас схема несколько упрощенная. Возможно, вам хватает ее для решения ваших задач, но…

Как сделано у нас.

master — в ней находится тот код, который уже установлен в прод. Пока код не на проде, в мастер не мержим. Прямые коммиты в мастер запрещены. Только мерж через пуллреквест. Который должен быть заапрувлен хотя бы одним ревьвером.

develop — ветка для синхронизации. От нее начинаются все новые релизы. Там лежит код, который уже прошел компонентное тестирование и ушел на бизнес-тест. Прямые коммиты тоже запрещены, только мерж из релизных веток с аппрувом PR хотя бы одним ревьвером.

release* — релизные ветки. Из них собираются поставки для компонентного тестирования.

feature* — рабочая ветка. в ней всегда работает один человек. Если релиз собирается из нескольких фич, то каждый разработчик пилит и тестирует свою, а потом они объединяются мержем в один релиз, который уже идет на компонентный тест.

Есть строгий стандарт на именование веток:

feature|release/MNM#nnn_JiraTaskName (плюс еще что-то может быть для фич)

где MNM — мнемоника поставки, nnn — ее номер и далее — имя задачи в Jira (то, что идет после jira.******.net/browse/).

Да, у нас установлена своя Jira и свой гит — BitBucket. И комментарий к коммиту всегда в первой строке содержит

MNM#nnn JitaTaskName

В результате в гите, что в списке коммитов, что в списке веток всегда есть прямая ссылка на задачу, по которой эта ветка делалась

После внедрения поставки на прод, девелоп (в который уже смержен релиз) мержится в мастер и удаляются все релиз и фичи ветки по данной поставке.

Не утверждаю, что это единственно правильный вариант, но нам это позволяет поддерживать хоть какой-то порядок в очень большом гите (несколько десятков проектов, в каждом от нескольких десятков до нескольких сотен репозиториев).

Вы абсолютно правы. У нас тоже используются ветки feature и release, и мы указываем в названии ветки id задачи, чтобы иметь привязку и через MR всегда можно было перейти в задачу и посмотреть на ревью, что все сделано согласно ТЗ.
В статье это не указал, так как посчитал слишком сложным описывать все ветвление абстрактному неподготовленному человеку. Но спасибо за ваш комментарий — он будет многим полезен)
Лучше указывать сразу. Потому что как вы описали, выглядит… Ну не знаю. Несерьезно как-то :-) Для личного репозитория ничего, а когда много народа можетв нем работать, уже нужен какой-то порядок и взаимные договоренности по поводу общих правил игры.
Можно просто написать git flow и дать ссылку на какую-нибудь статью на Хабре ))
git хорош свободой.

Есть строгий стандарт на именование веток

После внедрения поставки на прод, девелоп (в который уже смержен релиз) мержится в мастер и удаляются все релиз и фичи ветки по данной поставке.


Если ветки удаляются после мерджа то нет смысла в танцах вокруг красоты их наименования.
Вообще есть. Время жизни ветки конечно, но достаточно длительно. У нас ветка может жить и несколько недель и месяц. И в одном репозитории может работать несколько человек по разным версиям поставки. И когда заходишь в репозиторий очень удобно оценить что там сейчас происходит.

Да вот даже простейший пример. получаешь задание на доработку. Мнемоника поставки понятна. Но непонятна версия поставки — видишь, что на бою последняя, скажем, 320. Но это не факт что ты можешь взять 330 (версии с новой логикой увеличиваются на 10, на 1 — это исправления дефектов без новой логики). Потому что 330 может быть уже занята, но еще не внедрена (на тестах). Смотрим в артифактори (когда поставка уходит на тест, она складывается в артифактори) — ага, там есть уже и 330. Но опять не факт — возможно, кто-то уже взял в разработку 340. Смотрим в гите — ага, ветка #340 уже есть. Значит берем себе #350.

Ну и имя задачи в жире позволяет хоть с ветки хоть с коммита перейти на нее прямо из гита. Просто посмотреть — а что там дорабатывалось-то?

В целом это схема, которую мы выстроили в течении долго времени и в наших условиях (большое количество коман д, огромный зоопарк репозиториев, много разработчиков — только на бэке больше сотни, а есть еще фронты, пега...) она успешно работает. Просто заходишь в репозиторий и можно сразу оценить что там происходит — что в тесте, что на проме, что в разработке…
Тот момент, когда рад, что есть такие истории, но ты пока всё ещё думаешь, что ну уж мой-то поезд точно ушел, я слишком туп для этого всего, есть ли какой-то совет для таких, кто еще не решился и магической истории не происходит, как понять, что с твоим поездом и с тобой в целом?

К сожалению, магических историй не происходит ни с кем, в нее нужно ввязаться самому :D


Лучший совет, как понять стоит ли решаться — попробовать. Но надо понимать, что сразу ничего не получится и за пару дней новый поезд водить не научишься. Терпение и опыт решают

Я был вторым после Front-end лидера.
К сожалению, всё иногда зависит от вкусов коллег.

Он попробовал Typescript. Он поработал, но в итоге ему не понравилось.
(«Слишком много времени трачу на эти типы»)
Мне понравилось, а ему — нет.
(В результате в проекте JS+TS).

Про тесты (unit + e2e) — он мне сказал «Ну, делай, если тебе это интересно».
Ему было не интересно, абсолютно.
О каких Review речь?
В результате никто не прикрутил это к CI.
У всех свои процессы — на мой взгляд хорошо, что вы попробовали что-то новое.
Вас ждёт ещё много интересного впереди ) Рекомендую почитать книгу «97 этюдов для программистов» — не учебник, много зрелых идей.
Спасибо за комментарий, я читаю очень много книг и учебников, чтобы нарабатывать контекст и «знать, что я не знаю». Так что для меня ваша рекомендация очень ценна.
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

13 October 2009

Location

Германия

Employees

501–1,000 employees

Registered

9 October