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

Z>·>Делаешь ты push из task в develop, а он говорит, что diverged и конфликты. Тебе надо вначале вытянуть из develop в task, разрешить конфликты, потом push. Т.е. в task оказываются рандомные коммиты из develop.
Z>Не понимаю почему ты решил учить меня гиту. Для разрешения конфликтов вливание мастера не требуется, это факт.
Ох, т.е. в таск-ветке девелопа нет? И при вливании в релиз все эти конфликты придётся снова разрешать второй раз? Мда уж.

Z>·>Было бы что терять.
Z>Ну да? Ты поэтому уже который пост придумываешь ситуации, в которых схема не сработает )))
Что значит не сработает? Эта схема привычна для старинных СВК типа cvs/svn и т.п., которые в мержи и в граф истории не умеют. Однако ими пользовались многие годы. Выбора не было. А сегодня не пользоваться современными средствами организации истории, просто неэффективно.

Z>·>Тривиально когда ты вливаешь сейчас. А через неделю уже может быть нетривиально.
Z>На практике заметной разницы чаще всего нет.
Через неделю я обычно забываю что я делал, и конфликты разрешать сложнее. Плюс сливаться приходится с бОльшим кол-вом изменений. Чем дольше растут ветки, тем больше они diverged. Это факт.

Z>·>Я обнаружил, и начал разговор с объяснений, что два мержа — это кака, мучительно, ненадёжно и никаких преимуществ.
Z>Я не понимаю, зачем ты это объясняешь тому, кто уже несколько лет применяет это на практике? Откуда эта уверенность, что твои фантазии объективнее моего опыта?
Приходилось видеть и участвовать в исправлении таких вот многолетних практик.

Z>Откуда уверенность, что твой опыт регулярного болезненного разрешения конфликтов универсален?
У меня болезненный опыт организации нормального процесса управлениями ветками.

Z>·>Видов тестирования несколько. Поэтому задавай вопрос точнее. Таски QA тестирует в девелоп бранче. И именно от девелоп бранча создаются релизные таги — релизится ровно та же sha1 ревизия, что была протестирована.
Z>Если таски QA тестируют в девелоп бранче, то проблема того, что следующая задача может повлиять на тестируемую никуда не девается. То, что ты называешь надежным, становится гораздо менее надежным моей схемы,
Судя по твоей схеме QA тоже тестируют в девелоп бранче. Внезапно.
В моей схеме потом делается фриз с помощью тега и делается QA sign-off. В таком случае никаких 3 критов в подавляющем случае тупо не будет.

Z>когда ты сильно правишь или откатываешь таски из релиза.
Это редкая редкость, это означает серьёзный факап. Может раз в год такое в худшем случае.
Ещё я забыл пунктик, что в такой ситуации можно просто отложить релиз, а особо необходимые таски замержить в виде хотфиков на прод.

Z>·>Таски тестируются уже слитыми в один бранч во время аппрува релиза. Потому что релиз релизит либо всё, либо ничего (если происходит роллбак). Неясно в чём преимущество тестирования по отдельности, если в проде будет целое.
Z>Ты же писал, что есть практика отката одной задачи? Куда она делась?
Это не повседневное практика, а разгребание последствий серьёзного факапа.

Z>·>Четыре коммита! Их можно аккуратно проверить вручную и исследовать ипакт, дав указания QA какой функционал нужно перетестировать.
Z>Серьезно? Вы смотрите в код каждого фикса и сообщаете QA, что именно стоит перетестировать в регрессе релиза?
Для коммита в три строчки — почему бы и нет?

Z>·>При таком кол-ве задач их можно тестировать в процессе спринта. Большинство критов будет пофикшено в девелопе в течение спринта. В конце спринта создаётся таг и прогоняются тесты ещё раз на теге.
Z>Ты определись, вы тестируете задачи в процессе спринта или это делают юниттесты, а QA нужны для регресса перед релизом?
Да.

Z>·>Самое большое я видел около десятка коммитов в релиз-ветке, при этом не особо больших. Обычно меньше 3.
Z>Теперь расскажи, как получается, что именно последний тестируется больше всего?
Потому что на нём прогоняются все авто-тесты, которые гоняются на девелопе, плюс всякие медленные тесты, плюс на нём гоняются ручные тесты обнаруженных критических мест и т.п. И отличается от девелопа всего на < ~3 коммитов, которые видны как на ладони.
В твоей схеме на релизной ревизии тестов гоняется очевидно меньше, чем на дев-ветке. И разница в коде в принципе неизвестна, тупо выяснить разницу между тем что тестировали в девелопе и что сейчас в релизе — очень сложно, т.к. история у них серьёзно diverged.