ОБНОВЛЕНО - вопрос был изменен, чтобы указать, что проблема связана с состоянием нескольких функций, а не нескольких проектов, как было первоначально заявлено.Оригинальный ответ сохраняется ниже.
Существует множество конкурирующих рабочих процессов, которые работают для разных команд / проектов.Один довольно популярный рабочий процесс - это gitflow;вероятно, он лучше подходит для больших проектов, так как может показаться излишним для небольших / простых проектов, но опять же, для него есть достойная инструментальная поддержка.
В gitflow master - это "то, что было выпущено"и develop - это «то, что потенциально может быть выпущено прямо сейчас, если бы мы сделали релиз прямо сейчас» - так что вы не объедините функцию с develop до тех пор, пока она не пройдет тестирование QA.
Этоподнимает вопросы о том, как выполнить наилучшее тестированиеОчевидно, вам нужно будет протестировать версию develop после объединения функций в / перед выпуском, и вполне возможно, что эти тесты не пройдут, и вам придется либо удержать релиз для исправления, либо откатить одну или несколько функцийназад.Цель состоит в том, чтобы свести к минимуму частоту этого.
С хорошей инфраструктурой вы могли бы потенциально развернуть данную ветвь функции в среде QA, когда будете готовы протестировать эту функцию.Чтобы получить наилучший возможный тест, вы можете либо объединить разработку в функцию до теста (возможно, затем отменить объединение позже), либо переместить функцию на develop перед тестом (если вы не возражаете против регулярного переписывания ветвей функций),Итак, если «все высвобождаемое плюс эта дополнительная функция» проходит тестирование, одна дополнительная функция становится «чем-то высвобождаемой», и вы можете объединить ее с develop.
На практике в большинстве проектов, которые я видел, компромиссв некотором смысле, полагаясь на предположение, что функции не будут мешать друг другу (что, конечно, чрезмерно оптимистично, но все же может работать в большинстве случаев).
Стандарт вGit должен поместить каждый проект в свой собственный репозиторий (несмотря на недавнюю, и даже ошибочную, тенденцию «monorepos»). Ситуация, которую вы описываете, является отличным примером того, почему.
Это не значит, чтоВы не могли разработать какую-либо стратегию ветвления, которая дает тот же эффект от одного репо, но то, что вы, скорее всего, получите, это отдельные «логические репо», каждый из которых содержит свой собственный отдельный набор ветвей,в пределах «одного репо».