Существует множество распространенных подходов к ветвлению, и какой из них вы используете, зависит от ваших потребностей.
Если вы используете свой собственный исходный код, вам может подойти одна основная ветвь (например, master). В такой модели вы создаете PR и получаете все необходимые согласования. Затем вы развертываете вне своей системы ветвления с помощью отдельного инструмента развертывания, такого как бот, и объединяетесь с основной веткой, когда ваш код стабилен. GitHub использует эту систему.
Вы также можете использовать sh многоуровневую модель ветвления, в которой PR объединяется в последовательность ветвей, сначала ветвь разработки, затем ветвь QA, промежуточную ветвь и производственный филиал. Последний может называться, а может и не называться master.
Если вы работаете над проектом, основанным на выпуске, у вас может быть одна ветвь разработки, в которую сливается большая часть кода, и одна или несколько ветвей выпуска, в которых исправляются при необходимости соберите вишню. Это модель, которую используют многие проекты с открытым исходным кодом, например Git LFS. Git использует аналогичную стратегию, но с дополнительными ветвями, где изменения «готовятся» до тех пор, пока они не будут считаться стабильными.
Существуют и другие, более сложные рабочие процессы, такие как Git Flow, которые могут или многие не подходят твои нужды. При использовании стратегии ветвления следует учитывать одну вещь: если у вас несколько ветвей, то как вы собираетесь проходить код через этапы. Возможно, вам захочется иметь бота или инструмент, который проведет все через этапы после первоначального PR или ответвления, поскольку в противном случае что-то легко потеряется.
Важно, чтобы вы четко документировали свой рабочий процесс, чтобы все знали как это работает, и что вы готовы пересмотреть свой рабочий процесс, если он больше не соответствует вашим потребностям. Вы можете обнаружить, что некоторые части вашего рабочего процесса, помимо стратегии ветвления, могут нуждаться в изменении, если что-то не работает для вас, и эти изменения можно внести, если они лучше подходят для вашего проекта или организации.
Но в целом, трудно дать универсальную рекомендацию