У нас здесь большая проблема. Для каждого спринта имеется несколько историй пользователей, а новая ветвь создается для разработки для каждой истории пользователя.Как управлять и просматривать несколько больших ветвей git большого размера?
В середине разработки разработчик замечает, что им нужен код/метод или что-то из другой ветки. Они слияния с этой веткой. Иногда они делают выбор вишни и даже иногда создают патч и обменивают его друг с другом. Независимо от того, что они делают, в конце спринта рецензенты имеют проблемы, потому что они видят один и тот же код в нескольких запросах на растяжение.
К сожалению, наши истории пользователей являются большими как по размеру, так и по количеству (количество США за спринт), и это решение для руководства; мы ничего не можем с этим поделать.
Из-за размера PR и количества PR, рецензенты могут не помнить, проверен ли код, который они рассматривали, в других ветвях или нет, и что он может быть не таким же рецензентом.
Итак, вопрос в том, как управлять этими отраслями и что является лучшей практикой? Есть ли способ избежать дублирования кода в филиалах?
Есть ли инструмент, который может разумно определить слияния, чтобы мы могли просматривать в правильном порядке?
Или, возможно, инструмент обзора, чтобы отображать, откуда происходит изменение, чтобы рецензент знал, что изменения происходят из другого PR, который не связан с его? В настоящее время мы используем BitBucket, который не предлагает такой объект.
Я голосую свой комментарий и спасибо за это, но это не то, что я после, потому что я хотел сделать это во время просмотра. – xbmono