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

·>Делаешь ты push из task в develop, а он говорит, что diverged и конфликты. Тебе надо вначале вытянуть из develop в task, разрешить конфликты, потом push. Т.е. в task оказываются рандомные коммиты из develop.

Не понимаю почему ты решил учить меня гиту. Для разрешения конфликтов вливание мастера не требуется, это факт.

·>Было бы что терять.

Ну да? Ты поэтому уже который пост придумываешь ситуации, в которых схема не сработает )))

·>Тривиально когда ты вливаешь сейчас. А через неделю уже может быть нетривиально.

На практике заметной разницы чаще всего нет.

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

Я не понимаю, зачем ты это объясняешь тому, кто уже несколько лет применяет это на практике? Откуда эта уверенность, что твои фантазии объективнее моего опыта? Откуда уверенность, что твой опыт регулярного болезненного разрешения конфликтов универсален?

·>Видов тестирования несколько. Поэтому задавай вопрос точнее. Таски QA тестирует в девелоп бранче. И именно от девелоп бранча создаются релизные таги — релизится ровно та же sha1 ревизия, что была протестирована.

Если таски QA тестируют в девелоп бранче, то проблема того, что следующая задача может повлиять на тестируемую никуда не девается. То, что ты называешь надежным, становится гораздо менее надежным моей схемы, когда ты сильно правишь или откатываешь таски из релиза.

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

Ты же писал, что есть практика отката одной задачи? Куда она делась?

·>Четыре коммита! Их можно аккуратно проверить вручную и исследовать ипакт, дав указания QA какой функционал нужно перетестировать.

Серьезно? Вы смотрите в код каждого фикса и сообщаете QA, что именно стоит перетестировать в регрессе релиза?

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

Ты определись, вы тестируете задачи в процессе спринта или это делают юниттесты, а QA нужны для регресса перед релизом?

·>Самое большое я видел около десятка коммитов в релиз-ветке, при этом не особо больших. Обычно меньше 3.

Теперь расскажи, как получается, что именно последний тестируется больше всего?