AS
Если не сквошить, то будет полная история
история-то будет, но чем это удобнее чем в хранилище все захватить? если никаких быстрых изменений нет?
Size: a a a
2021 March 17
NG
выше была прямая речь автора git flow для чего он его создавал. Если вы используете для другого то это уже методика вашего имени.
Я не думаю, что автор гит флоу писал про 1с, не передергивайте
Z
выше была прямая речь автора git flow для чего он его создавал. Если вы используете для другого то это уже методика вашего имени.
git flow был приудман тогда когда не было CI и приходилось тестировать и стабилизировать на отдельной ветке
NG
Кирилл Черненко
Щас бы 20 коммитов устранения замечаний сонара в мастер лить
Щас бы хоть кто-то исправлял замечания в сонаре, а не стал прямо в мастер :(
ПМ
Я не думаю, что автор гит флоу писал про 1с, не передергивайте
Он указал вид процессов, 1с как и веб это набор скриптов в режиме частого обновления. Никто не поддерживает 5-7 параллельных релизов.
КЧ
Щас бы хоть кто-то исправлял замечания в сонаре, а не стал прямо в мастер :(
Ну так если pr есть, чеб не поустранять, а мастер как известно протектед бранч в него хрен чё запушишь
Z
Он указал вид процессов, 1с как и веб это набор скриптов в режиме частого обновления. Никто не поддерживает 5-7 параллельных релизов.
Поддерживает
КЧ
Он указал вид процессов, 1с как и веб это набор скриптов в режиме частого обновления. Никто не поддерживает 5-7 параллельных релизов.
Платформа же, вполне себе
NG
Он указал вид процессов, 1с как и веб это набор скриптов в режиме частого обновления. Никто не поддерживает 5-7 параллельных релизов.
В вашей "прямой речи" нет ни слова про фича-бранчи длиной в месяц. Релиз бранчи да, могут жить годами.
NG
Он указал вид процессов, 1с как и веб это набор скриптов в режиме частого обновления. Никто не поддерживает 5-7 параллельных релизов.
И да, поддерживает
ПМ
И да, поддерживает
Например? Кроме ерп 2.4 2.5 и прочих частных случаев особо и нет ничено. На проектах или внутренних ит есть только одна версия текущая и патчи
IS
На самом деле если саму идею гитхаб-флоу отвязать от гита, а перенести на хранилища, то это просто по сути два хранилища: дев и мастер, сначала идут помещения в дев, там тестируются, далее принятые тестировщиком задачи переносятся в мастер хранилище и на нём уже проходят интеграционные тесты и если всё ок то из мастера конфа засасывается в прод
КЧ
Например? Кроме ерп 2.4 2.5 и прочих частных случаев особо и нет ничено. На проектах или внутренних ит есть только одна версия текущая и патчи
Бсп же
ПМ
На самом деле если саму идею гитхаб-флоу отвязать от гита, а перенести на хранилища, то это просто по сути два хранилища: дев и мастер, сначала идут помещения в дев, там тестируются, далее принятые тестировщиком задачи переносятся в мастер хранилище и на нём уже проходят интеграционные тесты и если всё ок то из мастера конфа засасывается в прод
Да и на итс оно даже описано хранилища технических проектов
КЧ
На самом деле если саму идею гитхаб-флоу отвязать от гита, а перенести на хранилища, то это просто по сути два хранилища: дев и мастер, сначала идут помещения в дев, там тестируются, далее принятые тестировщиком задачи переносятся в мастер хранилище и на нём уже проходят интеграционные тесты и если всё ок то из мастера конфа засасывается в прод
В гитхаб флоу нет девелопа
+ в чем смысл тогда вообще в использовании гита, если в итоге один коммит будет равен внесению подсистемы по итогам месяца разработки? В рамку повесить?
git это в первую очередь dvcs - в этом весь смысл
а остальное - это про методики работы.
а остальное - это про методики работы.
NG
Например? Кроме ерп 2.4 2.5 и прочих частных случаев особо и нет ничено. На проектах или внутренних ит есть только одна версия текущая и патчи
Павел, вы очень категоричны безапелляционны в своих суждениях. Отсюда и восприятие каждого вашего сообщения в этом чате в штыки :)
ПМ
Павел, вы очень категоричны безапелляционны в своих суждениях. Отсюда и восприятие каждого вашего сообщения в этом чате в штыки :)
Вы не со мной, идите к автору git flow и доказывайте что он неправ.
АМ
В вашей "прямой речи" нет ни слова про фича-бранчи длиной в месяц. Релиз бранчи да, могут жить годами.
а в чем проблема с длинными фича-бранчами? у нас иногда бывает что во время разработки функционала происходит обновление на новый типовой релиз например. В большинстве случаев ребейз проходит без проблем и разработчик фичи актуализирует свой код. Это же нормальный подход? :)
КЧ
Вы не со мной, идите к автору git flow и доказывайте что он неправ.
Он не прав в том что в 1С нет проект с параллельной поддержкой разных версий?