Рекомендации по нескольким линиям выпуска и git-flow, для git-не-гуру

Question

Наша линейка программных продуктов требует разработки и поддержки нескольких версий программного обеспечения одновременно. Мы относительные новички в Git и недавно приняли Git Flow, чтобы воспользоваться преимуществами модели ветвления Дриссена. У нас очень небольшая команда разработчиков программного обеспечения с несколькими преданными разработчиками (мы все носим много шляп) и без "гуру интеграции".

В результате многих поисков оказалось мало конкретных советов о том, как адаптировать Git и Git Flow к нашим потребностям. Выяснилось, что Git Flow не очень подходит для одновременной поддержки нескольких версий. В одном связанном обсуждении SO есть ответы, указывающие на то, что отдельные имена веток необходимо использовать для отслеживания истории отдельных версий. Эта и связанные с ней стратегии исключают Git Flow, если он не модифицирован; см. ограничения нашей команды выше по причине, почему это не практично для нас.

Ключевой вопрос заключается в том, что, по мнению других, является хорошим подходом для максимально точной реализации модели ветвления Дриссена при поддержке нескольких линий выпуска?

ОБНОВЛЕНИЕ:

Изучение приведенных ниже ответов (в частности, @Rasmus') с более целенаправленным поиском и внутренними обсуждениями нескольких вариантов приводит к следующему решению, которое мы реализуем и которое я предлагаю в качестве одного из подходов, которые могут иметь отношение к аналогичным группам в аналогичных условиях.

Мы не будем продолжать использовать Git Flow. Вместо этого мы применим модель Дриссена к каждой отдельной строке релиза в репо, предварительно связав каждое имя ветви с предполагаемой строкой релиза, например:

r1.5/develop

Все версии проекта содержатся в репозитории Git. Запуск новой версии проекта состоит в создании небольшого набора новых долгоживущих веток с предваряющей строкой релиза (например, r1.6/develop и, в нашем случае, r1.6/release; нет master с его влиянием единственного текущего хорошего строимого состояния).

Мы устанавливаем один центральный публичный репозиторий для каждого проекта на сервере, который будет основным каналом для обмена кодом через локальное репо remote ссылки. Толчок в этот репозиторий означает код, который готов к использованию другими. сращивание RX.Y/develop в и затем толкая RX.Y/release ветвь означает код, который предназначен для выпуска. feature, hotfixи др. и др. ветви обрабатываются аналогично. История слияния / принятия веток для данной строки релиза является чистой и понятной. Мы не хотим типичной стратегии распределенного репо Git, чтобы избежать сложности объединения таких репо, которые со временем, вероятно, будут расходиться по структуре.

В некоторых графических интерфейсах Git (например, SourceTree) эта структура ветвей распознается и отображается как иерархическая, что помогает понять историю проекта верхнего уровня из структуры ветвей.

Извинения за то, что не проголосовали за любые ответы; моя репутация на SO еще не является минимально необходимым для этого.

Answer 1

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

Мы разделили его так, что у нас есть начальный ref, такой как refs/heads/platformX.Y/, затем мы строим его

Таким образом, в зависимости от того, что вам нужно сделать, вы извлекаете платформу X.Y/development и начинаете работать с этой точки в функциональной ветви, и вы возвращаетесь к разработке, когда закончите.

Это работает для нас, и мы можем следовать модели nvie.

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

Answer 2

Наш обычный процесс разработки хорошо вписывается в рабочий процесс Дриссена, но иногда нам нужно разработать ветку с несколькими функциями для специализированного выпуска, где мы не хотим, чтобы основная часть текущей разработки была включена. Мы нашли способ сделать это в потоке, используя существующие инструменты, всего за пару дополнительных шагов. (Мы работаем в Mercurial, но опции для git flow и hg flow одинаковы.)

Например, наша следующая нормальная версия -23.0, а наша специальная "песочница" -22.4.2. Для этих случаев мы:

1. В самом начале, перед созданием новых функций, создайте ветку релиза 22.4.2 для специального релиза от Develop. Хорошо, если некоторые функции были запущены ранее, если они не появляются после какой-либо работы над разработкой, которую мы хотим исключить.
2. Сделайте там тег для удобства (start-22.4.2)
3. Запустите каждую новую функцию 22.4.2 с start-22.4.2 (набор изменений при разработке) в качестве ее родителя / базы. Это предотвращает утечку любой работы, которая будет скомпонована для разработки, в ветку релиза. И командная строка, и Sourcetree поддерживают выбор родителя помимо подсказки для git flow feature start,
4. При желании объединяйте вручную из кончика ветви 22.4.2 с объектом и так часто, как это требуется, чтобы получить все законченные объекты из ветви. Это позволяет нам справляться с любыми проблемами взаимодействия между новыми функциями 22.4.2 в ветви.
5. git flow feature finish особенность, которая объединяет его, чтобы развиваться как обычно. (Для нас эти функции должны быть включены в будущие выпуски. Мы защищаем только 22.4.2 от менее проверенной работы.)
6. После finishмы вручную объединяем последний набор изменений перед закрытием объекта в ветке 22.4.2.

Answer 3

Одним из решений является изменение переменной конфигурации gitflow.branch.develop, Вы создаете ветку в своей выпущенной версии и используете эту ветку как свою новую ветку разработки. Оттуда вы используете обычные команды git-flow. Если вы хотите автоматически объединить эту работу с исходной веткой разработки, измените gitflow.branch.develop переменная перед командой завершения git-flow.