Схемы ветвления контроля версий для внутренних приложений

Question

Я привык к схеме ветвления управления исходным кодом, в которой ветки создаются для каждой основной версии продукта. Возможно, я упускаю из виду некоторые скрытые преимущества этой модели, но я думаю, что главное преимущество заключается в том, что это позволяет устанавливать патчи вне диапазона.

Похоже, что эта модель слишком сложна для продуктов, в которых никогда не будет исправлений для чего-либо, кроме самого последнего выпуска (например, веб-сайтов и внутренних приложений).

Я рассматриваю вопрос о переносе наших внутренних приложений на модель с двумя ветвями: development и production. Ветвь development предназначена для работы со следующей версией продукта, а ветвь production - для исправления текущей версии продукта.

Я упрощаю или упускаю какое-то другое преимущество версионной ветвящейся структуры? Что другие люди успешно использовали для внутренних приложений и веб-сайтов?

Answer 1

Моя команда разработчиков использует аналогичную стратегию, за исключением того, что мы также используем третью ветвь для тестирования. У нас небольшая команда, и она работает очень хорошо, потому что мы не теряем много времени на слияние, рабочие копии и другие бесполезные хлопоты. Я не думаю, что это хорошо масштабировалось бы, если бы мы внезапно удвоили или утроили размер нашей команды, но в этом случае у нас было бы гораздо больше поводов для беспокойства, чем ветвление подрывной деятельности.

Я не думаю, что вы действительно не упустите много важных преимуществ, обрезая свои ветви. Если ваша команда мала и / или у всех есть четко определенные задачи, которые не мешают чьей-либо работе, избавьте себя от необходимости поддерживать раздутый репозиторий. Однако чем больше людей над этим работает, тем больше вероятность того, что им придется разбираться с конфликтами слияний.