Как стать автором
Обновить

Комментарии 15

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

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

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

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.
Может, масштаб мелкий.
Но та же Calefirnia.
У всех свои процессы — на мой взгляд хорошо, что вы попробовали что-то новое.
Вас ждёт ещё много интересного впереди ) Рекомендую почитать книгу «97 этюдов для программистов» — не учебник, много зрелых идей.
Спасибо за комментарий, я читаю очень много книг и учебников, чтобы нарабатывать контекст и «знать, что я не знаю». Так что для меня ваша рекомендация очень ценна.
Который Мартина или который Спинеллиса? Не ожидал, что это такое популярное название :)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.