Во-первых, некоторые из них, мы находимся в процессе перехода всех наших проектных команд на использование git и разрабатываем рекомендации по организации репозиториев, чтобы можно было отслеживать определенные ветви для непрерывной интеграции и автоматическое развертывание на серверах тестирования. В настоящее время разрабатываются две модели:
Большое влияние оказала статья nvie.com об успешном ветвлении с основной ветвью, представляющей наиболее стабильный код, ветвь разработки для передового кода и ветвь интеграции для кода, который готов для тестирования качества.
Альтернативная модель, в которой главная ветвь представляет передовой код разработки, интеграционную ветвь для кода, готового для тестирования QA, и производственную ветвь для стабильного кода, готового к развертыванию.
На данный момент это частично вопрос семантики в отношении того, что представляет собой основная ветвь, но делает ли активная разработка в основной ветке действительно хорошую практику или это не так уж и важно?
Ответы:
Единственная реальная определяющая особенность
masterветви - это то, что она используется по умолчанию для некоторых операций. Кроме того, имена ветвей имеют значение только в определенном хранилище. Мойmasterможет указать на вашdevelopment, например. Кроме того,masterветка даже не требуется, поэтому, если есть какая-то путаница относительно того, какой ветвью она должна быть, я советую вообще ее исключить.Тем не менее, по моему мнению, лучший способ думать об этом - это использование по умолчанию. Большинство онлайн-учебников, которые читают ваши разработчики, предполагают это. Таким образом, имеет смысл иметь
masterлюбую ветвь, к которой чаще всего подталкивают. Некоторые люди думают об этом как о нетронутой копии, которую нельзя коснуться разработчикам, кроме как после самого строгого изучения, но использование этого способа удаляет многие полезные настройки по умолчанию, которые предоставляет git. Если вам нужна такая нетронутая ветка, я бы поместил ее в совершенно отдельный репозиторий, в который могут писать только некоторые люди.источник
Нет, это не рекомендуется, даже в начале, прежде чем вы пошли в QA. В качестве наилучшей практики схема развития должна быть последовательной от начала до конца. Ваша основная ветка должна начинаться с нуля, вы должны разветвлять свою ветку разработки и начинать добавлять файлы, сливаться с вашей веткой интеграции, а затем со своей главной.
Хотя во время разработки никто не может заботиться о том, что основная ветвь не создается, на раннем этапе она поддается вредным привычкам. Мастер должен всегда собираться, и для выпусков основных функций также было бы неплохо иметь заархивированные ветки основных сборок, чтобы при необходимости можно было вернуться к стабильным точкам выпуска.
источник