Постановка задачи:
У меня есть пользовательская история US1, и с ней связаны определенные задачи. Допустим, T1, T2, T3 и T4. У US1 есть ветвь, называемая branch_US1 . Когда я начинаю работать с US1, я выбираю T1, затем заканчиваю и затем фиксирую код в branch_T1 .
Теперь мне нужно создать pull-запрос для слияния из branch_T1 в branch_US1 , скажем, этот pull-запрос T1_US1 . Теперь так же, как я завершаю задачу T2 и фиксирую работу в branch_T2 и создаю запрос на извлечение для слияния с branch_US1, допустим, что этот запрос извлечения T2_US1 .
Теперь я не могу продолжать работу над задачей T3, потому что T3 зависит от T2 (у них есть зависимость от кода) так что до тех пор, пока мой запрос на получение не будет утвержден и слияние, я не смогу продолжить. Теперь все мои запросы находятся в стадии рассмотрения (открыто), потому что рецензент занят другой работой. В этой проблеме есть ветви, связанные с Задачами.
Какой может быть лучший подход для преодоления этой проблемы?
То, что я уже пробовал: допустим, Подход A
Я всегда регистрирую свой T1, T2 на branch_US1, чтобы я мог работать без блокировщика, потому что здесь это только одна ветвь, а T1 T2 .. .. не имеет никаких ветвей. T1 T2 .. .. просто логическое задание для меня.
Проблема с подходом A:
Пример: если тестировщик хочет проверить функциональность T1, то тестировщик должен проверить branch_US1 , и он также получает работу (код) T2 и может быть кодом T3 также потому, что разработчик постоянно передает код в одном ветка.
Здесь инженер по тестированию должен загрузить только ветвь пользовательской истории, т.е. branch_US1, и проверить логическую задачу над ней. Этот подход фиксирует задачу инкрементным способом.
Expectation:
Есть ли лучшая практика, которая может помочь в решении вышеуказанной проблемы. Нужна стратегия коммитов, слияний и рецензий, чтобы тестировщик мог тестировать только коммиты, связанные с задачей, а разработчик мог без проблем работать над задачами.