Сообщение Re[2]: Политика гитования от 08.07.2023 0:34
Изменено 08.07.2023 0:50 尿컙拋㕪⬎⤇Ǥ꧃푙刾ꄔ
Re[2]: Политика гитования
зачем так переусложнять?
Есть мастер, есть релизы бранчи. Все остальное short-lived branches, включая feature, hotfix, bugfix etc. Создаются и уничтожаются по факту мержа либо в мастер либо в релиз. hotfix/bugfix могут мержится в несколько мест (см. черрипикинг), если проблема в релиз бранче — но самое простое и чистое решение мержить фиксы в релиз и перед отдачей релиза/по мере необходимости мержить весь релиз в мастер.
Чем больше бранчей, тем больше проблем, количество параллельно поддерживаемых бранчей — главный источник сложности, зачем их плодить? За 10 лет я не видел нужды в develop бранче/где бы это использовалось.
по поводу политик — мне нравится как сделано в GitLab — protected branches, защищенные бранчи — в них нельзя мержить напрямую, обычно это мастер, иногда релизы. Соответственно, для изменения кода необходимо создавать бранч и проходить через процедуру ревью и проверок перед мержем (например запуск тестов и код кавераджа). На практике этого хватает, усложнить, конечно, можно, но зачем?
релиз бранчи формируются и поддерживаются релиз инженером или равноправным лицом, это немного другая работа, нежели непосредственно разработка, но все решается в рамках скрума или для частных случаев митингами.
Есть мастер, есть релизы бранчи. Все остальное short-lived branches, включая feature, hotfix, bugfix etc. Создаются и уничтожаются по факту мержа либо в мастер либо в релиз. hotfix/bugfix могут мержится в несколько мест (см. черрипикинг), если проблема в релиз бранче — но самое простое и чистое решение мержить фиксы в релиз и перед отдачей релиза/по мере необходимости мержить весь релиз в мастер.
Чем больше бранчей, тем больше проблем, количество параллельно поддерживаемых бранчей — главный источник сложности, зачем их плодить? За 10 лет я не видел нужды в develop бранче/где бы это использовалось.
по поводу политик — мне нравится как сделано в GitLab — protected branches, защищенные бранчи — в них нельзя мержить напрямую, обычно это мастер, иногда релизы. Соответственно, для изменения кода необходимо создавать бранч и проходить через процедуру ревью и проверок перед мержем (например запуск тестов и код кавераджа). На практике этого хватает, усложнить, конечно, можно, но зачем?
релиз бранчи формируются и поддерживаются релиз инженером или равноправным лицом, это немного другая работа, нежели непосредственно разработка, но все решается в рамках скрума или для частных случаев митингами.
Re[2]: Политика гитования
зачем так переусложнять?
Есть мастер, есть релизы бранчи. Все остальное short-lived branches, включая feature, hotfix, bugfix etc. Создаются и уничтожаются по факту мержа либо в мастер либо в релиз. hotfix/bugfix могут мержится в несколько мест (см. черрипикинг), если проблема в релиз бранче — но самое простое и чистое решение мержить фиксы в релиз и перед отдачей релиза/по мере необходимости мержить весь релиз в мастер (естественно, для этого есть какое то opportunity window, которое со временем закрывается).
Чем больше бранчей, тем больше проблем, количество параллельно поддерживаемых бранчей — главный источник сложности, зачем их плодить? За 10 лет я не видел нужды в develop бранче/где бы это использовалось.
по поводу политик — мне нравится как сделано в GitLab — protected branches, защищенные бранчи — в них нельзя мержить напрямую (или можно, но не всем), обычно это мастер, иногда релизы. Соответственно, для изменения кода необходимо создавать бранч и проходить через процедуру ревью и проверок перед мержем (например запуск тестов и код кавераджа). На практике этого хватает, усложнить, конечно, можно, но зачем?
релиз бранчи формируются и поддерживаются релиз инженером или равноправным лицом, это немного другая работа, нежели непосредственно разработка, но все решается в рамках скрума или для частных случаев митингами.
Есть мастер, есть релизы бранчи. Все остальное short-lived branches, включая feature, hotfix, bugfix etc. Создаются и уничтожаются по факту мержа либо в мастер либо в релиз. hotfix/bugfix могут мержится в несколько мест (см. черрипикинг), если проблема в релиз бранче — но самое простое и чистое решение мержить фиксы в релиз и перед отдачей релиза/по мере необходимости мержить весь релиз в мастер (естественно, для этого есть какое то opportunity window, которое со временем закрывается).
Чем больше бранчей, тем больше проблем, количество параллельно поддерживаемых бранчей — главный источник сложности, зачем их плодить? За 10 лет я не видел нужды в develop бранче/где бы это использовалось.
по поводу политик — мне нравится как сделано в GitLab — protected branches, защищенные бранчи — в них нельзя мержить напрямую (или можно, но не всем), обычно это мастер, иногда релизы. Соответственно, для изменения кода необходимо создавать бранч и проходить через процедуру ревью и проверок перед мержем (например запуск тестов и код кавераджа). На практике этого хватает, усложнить, конечно, можно, но зачем?
релиз бранчи формируются и поддерживаются релиз инженером или равноправным лицом, это немного другая работа, нежели непосредственно разработка, но все решается в рамках скрума или для частных случаев митингами.