Здравствуйте, netch80, Вы писали:

N>Меня в этой "простой и очевидной" вымораживает пример "2.0 не получилась, делаем 2.1". Какое отношение номера версий имеют к пробам сборки и тестирования, и какая религия запрещает сделать фикс и смержить его вверх?

Согласен, конкретно эта идея дурацкая. Взял первый похожий на правду результат из гугла, этого нюанса не заметил

S>> в аццкий изврат типа такого:
S>>http://yakiloo.com/getting-started-git-flow/

N>Если не относиться чрезмерно лободробительно к этой схеме, это всего лишь комплекс мер по достаточно качественной предварительной оценке изменений и защите продакшена и пользователей от непроработанных решений, при отсутствии высоких требований к разработчикам (считаем, они не в состоянии сами выпутаться из ситуации работы нескольких человек над одной веткой).

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

1. Серьёзно, зачем городить изврат с master-dev ветками? Чем оно удобнее основной ветки + отдельной ветки для каждого релиза? Понятно, что оно обязательно для форков. Для не-опенсорса зачем?

2. Зачем идиотская схема с "чиним заново тикет на релизной ветке" вместо простого бэкпорта с основной ветки (обычно примерно в половине случаев исправление уже там есть)? Какой порядок действий для нескольких релизов?

3. Какого чёрта почти все "внедренцы" требуют не мержить без явной необходимости ничего из основной ветки в feature??? Типа стрелочки на диаграмме нет — значит низзя?

В общем, может где-то и есть более-менее человеческое описание "как адаптировать gitflow к типовой энтерпрайз-разработке", но пока всё что попадалось — это именно культ карго в чистом виде

Здравствуйте, netch80, Вы писали:

N>Меня в этой "простой и очевидной" вымораживает пример "2.0 не получилась, делаем 2.1". Какое отношение номера версий имеют к пробам сборки и тестирования, и какая религия запрещает сделать фикс и смержить его вверх?

Согласен, конкретно эта идея дурацкая. Взял первый похожий на правду результат из гугла, этого нюанса не заметил

S>> в аццкий изврат типа такого:
S>>http://yakiloo.com/getting-started-git-flow/

N>Если не относиться чрезмерно лободробительно к этой схеме, это всего лишь комплекс мер по достаточно качественной предварительной оценке изменений и защите продакшена и пользователей от непроработанных решений, при отсутствии высоких требований к разработчикам (считаем, они не в состоянии сами выпутаться из ситуации работы нескольких человек над одной веткой).

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

1. Серьёзно, зачем городить изврат с master-dev ветками? Чем оно удобнее основной ветки + отдельной ветки для каждого релиза? Понятно, что оно обязательно для форков. Для не-опенсорса зачем?

2. Зачем идиотская схема с "чиним заново тикет на релизной ветке" вместо простого бэкпорта с основной ветки (обычно примерно в половине случаев исправление уже там есть)? Какой порядок действий для нескольких релизов?
UPD. Вопрос отпал. Забыл, что гит не отслеживает cherry picks. Жизнь — боль, ага.

3. Какого чёрта почти все "внедренцы" требуют не мержить без явной необходимости ничего из основной ветки в feature??? Типа стрелочки на диаграмме нет — значит низзя?

В общем, может где-то и есть более-менее человеческое описание "как адаптировать gitflow к типовой энтерпрайз-разработке", но пока всё что попадалось — это именно культ карго в чистом виде