Комментарии 15
По поводу работы с гитом.
На мой взгляд, у вас схема несколько упрощенная. Возможно, вам хватает ее для решения ваших задач, но…
Как сделано у нас.
master — в ней находится тот код, который уже установлен в прод. Пока код не на проде, в мастер не мержим. Прямые коммиты в мастер запрещены. Только мерж через пуллреквест. Который должен быть заапрувлен хотя бы одним ревьвером.
develop — ветка для синхронизации. От нее начинаются все новые релизы. Там лежит код, который уже прошел компонентное тестирование и ушел на бизнес-тест. Прямые коммиты тоже запрещены, только мерж из релизных веток с аппрувом PR хотя бы одним ревьвером.
release* — релизные ветки. Из них собираются поставки для компонентного тестирования.
feature* — рабочая ветка. в ней всегда работает один человек. Если релиз собирается из нескольких фич, то каждый разработчик пилит и тестирует свою, а потом они объединяются мержем в один релиз, который уже идет на компонентный тест.
Есть строгий стандарт на именование веток:
feature|release/MNM#nnn_JiraTaskName (плюс еще что-то может быть для фич)
где MNM — мнемоника поставки, nnn — ее номер и далее — имя задачи в Jira (то, что идет после jira.******.net/browse/).
Да, у нас установлена своя Jira и свой гит — BitBucket. И комментарий к коммиту всегда в первой строке содержит
MNM#nnn JitaTaskName
В результате в гите, что в списке коммитов, что в списке веток всегда есть прямая ссылка на задачу, по которой эта ветка делалась
После внедрения поставки на прод, девелоп (в который уже смержен релиз) мержится в мастер и удаляются все релиз и фичи ветки по данной поставке.
Не утверждаю, что это единственно правильный вариант, но нам это позволяет поддерживать хоть какой-то порядок в очень большом гите (несколько десятков проектов, в каждом от нескольких десятков до нескольких сотен репозиториев).
На мой взгляд, у вас схема несколько упрощенная. Возможно, вам хватает ее для решения ваших задач, но…
Как сделано у нас.
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 хорош свободой.
Если ветки удаляются после мерджа то нет смысла в танцах вокруг красоты их наименования.
Есть строгий стандарт на именование веток
После внедрения поставки на прод, девелоп (в который уже смержен релиз) мержится в мастер и удаляются все релиз и фичи ветки по данной поставке.
Если ветки удаляются после мерджа то нет смысла в танцах вокруг красоты их наименования.
Вообще есть. Время жизни ветки конечно, но достаточно длительно. У нас ветка может жить и несколько недель и месяц. И в одном репозитории может работать несколько человек по разным версиям поставки. И когда заходишь в репозиторий очень удобно оценить что там сейчас происходит.
Да вот даже простейший пример. получаешь задание на доработку. Мнемоника поставки понятна. Но непонятна версия поставки — видишь, что на бою последняя, скажем, 320. Но это не факт что ты можешь взять 330 (версии с новой логикой увеличиваются на 10, на 1 — это исправления дефектов без новой логики). Потому что 330 может быть уже занята, но еще не внедрена (на тестах). Смотрим в артифактори (когда поставка уходит на тест, она складывается в артифактори) — ага, там есть уже и 330. Но опять не факт — возможно, кто-то уже взял в разработку 340. Смотрим в гите — ага, ветка #340 уже есть. Значит берем себе #350.
Ну и имя задачи в жире позволяет хоть с ветки хоть с коммита перейти на нее прямо из гита. Просто посмотреть — а что там дорабатывалось-то?
В целом это схема, которую мы выстроили в течении долго времени и в наших условиях (большое количество коман д, огромный зоопарк репозиториев, много разработчиков — только на бэке больше сотни, а есть еще фронты, пега...) она успешно работает. Просто заходишь в репозиторий и можно сразу оценить что там происходит — что в тесте, что на проме, что в разработке…
Да вот даже простейший пример. получаешь задание на доработку. Мнемоника поставки понятна. Но непонятна версия поставки — видишь, что на бою последняя, скажем, 320. Но это не факт что ты можешь взять 330 (версии с новой логикой увеличиваются на 10, на 1 — это исправления дефектов без новой логики). Потому что 330 может быть уже занята, но еще не внедрена (на тестах). Смотрим в артифактори (когда поставка уходит на тест, она складывается в артифактори) — ага, там есть уже и 330. Но опять не факт — возможно, кто-то уже взял в разработку 340. Смотрим в гите — ага, ветка #340 уже есть. Значит берем себе #350.
Ну и имя задачи в жире позволяет хоть с ветки хоть с коммита перейти на нее прямо из гита. Просто посмотреть — а что там дорабатывалось-то?
В целом это схема, которую мы выстроили в течении долго времени и в наших условиях (большое количество коман д, огромный зоопарк репозиториев, много разработчиков — только на бэке больше сотни, а есть еще фронты, пега...) она успешно работает. Просто заходишь в репозиторий и можно сразу оценить что там происходит — что в тесте, что на проме, что в разработке…
Тот момент, когда рад, что есть такие истории, но ты пока всё ещё думаешь, что ну уж мой-то поезд точно ушел, я слишком туп для этого всего, есть ли какой-то совет для таких, кто еще не решился и магической истории не происходит, как понять, что с твоим поездом и с тобой в целом?
НЛО прилетело и опубликовало эту надпись здесь
К сожалению, магических историй не происходит ни с кем, в нее нужно ввязаться самому :D
Лучший совет, как понять стоит ли решаться — попробовать. Но надо понимать, что сразу ничего не получится и за пару дней новый поезд водить не научишься. Терпение и опыт решают
Я был вторым после Front-end лидера.
К сожалению, всё иногда зависит от вкусов коллег.
Он попробовал Typescript. Он поработал, но в итоге ему не понравилось.
(«Слишком много времени трачу на эти типы»)
Мне понравилось, а ему — нет.
(В результате в проекте JS+TS).
Про тесты (unit + e2e) — он мне сказал «Ну, делай, если тебе это интересно».
Ему было не интересно, абсолютно.
О каких Review речь?
В результате никто не прикрутил это к CI.
К сожалению, всё иногда зависит от вкусов коллег.
Он попробовал Typescript. Он поработал, но в итоге ему не понравилось.
(«Слишком много времени трачу на эти типы»)
Мне понравилось, а ему — нет.
(В результате в проекте JS+TS).
Про тесты (unit + e2e) — он мне сказал «Ну, делай, если тебе это интересно».
Ему было не интересно, абсолютно.
О каких Review речь?
В результате никто не прикрутил это к CI.
Может, масштаб мелкий.
Но та же Calefirnia.
Но та же Calefirnia.
Вас ждёт ещё много интересного впереди ) Рекомендую почитать книгу «97 этюдов для программистов» — не учебник, много зрелых идей.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
4 главных вещи, которые я не знал перед выходом на стажировку в разработку