Полезно ли использовать ветки для поддержки разных версий одного и того же программного обеспечения?

У нас есть продукт, который имеет несколько разных изданий. Различия незначительны: разные строки здесь и там, очень мало дополнительной логики в одном, очень мало различий в логике в другом. Когда программное обеспечение разрабатывается, большинство изменений необходимо добавлять в каждую редакцию; однако, есть некоторые, которые этого не делают, и некоторые, которые должны отличаться. Допустимо ли использование веток, если у меня есть ветки release-editionA и release-editionB (..etc)? Есть ли какие-нибудь ошибки? Хорошая практика?

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

Это зависит от величины изменений, но я не считаю это хорошей практикой для различий, которые вы описали.

Как правило, вы хотите, чтобы ветка Git была чем-то, что будет объединено в будущем или сохранено только для чтения для справки. Ветви Git, которые сосуществуют бесконечно, означают работу для всех: изменения необходимо распространять и объединять, разрешать конфликты, все самое интересное. Если не что иное, каждый разработчик должен помнить, чтобы внести изменения в пять репозиториев вместо одного.

Если у вас есть небольшие изменения, все усилия по слиянию и ветвлению кажутся излишними по сравнению с проблемой. Используйте свой препроцессор или систему сборки, чтобы различать версии. Простой #ifdefделает свое дело? Тогда не решайте проблемы с git, это излишне.

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

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

В конце концов, вы хотите сохранить «единый источник правды»; с ветвями вы будете дублировать некоторый код, но не весь, и некоторые слияния фактически нарушат вашу настройку.

Как указали люди, одно решение - настроить систему сборки для поддержки разных выпусков.

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

Посмотрите на этом сайте.

Я думаю, что это хорошая идея, если вы не можете сделать это в одной ветви, не разбирая много кода.
Я бы предпочел иметь возможность хранить его в одной ветке и использовать локализованные и конфигурационные файлы, особенно если вы говорите, что различия незначительны.
Другим способом могут быть разные сборки, например, ваш файл сборки содержит разные файлы для разных клиентов, но я также вижу инструмент сборки, проверяющий разные ветви. Поскольку вы используете git, я бы сказал, что нет настоящих ошибок. Одной из стратегий ветвления может быть разработка в разных ветвях для разных задач, регистрация в основной ветке и слияние с главной на редакцию X и Y.

Это больше похоже на работу для разных конфигураций сборки. Ответ Титона идет в этом направлении, но я бы взял его гораздо дальше #ifdef:

Используйте разные цели сборки для создания разных выпусков программного обеспечения. Цели могут отличаться

• конфигурация, которую они включают,
• объект или исходные файлы, которые они включают, или
• предварительная обработка исходного кода.

Эта предварительная обработка, очевидно, может включать в себя классический препроцессор C, но может также включать использование собственного препроцессора, механизма шаблонов для создания пользовательских представлений,…

Таким образом, вам не нужно активно выдвигать каждое изменение в несколько веток, что нарушает DRY (конечно, это тоже можно автоматизировать, но я не вижу преимущества).

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

Если вы выпускаете их как разные продукты, то рекомендуется иметь несколько веток. Если нет, то все равно рекомендуется использовать что-то вроде транка или мастер-ветви.

Кроме того, я думаю, что это будет зависеть от процесса разработки, в частности, от развертывания. Если у вас есть процесс, который разрешает развертывание только одной ветви в производство, и ветви обрабатываются как «инкрементные сборки», то есть выпуск B не может быть развернут в производство, если только выпуск A не был развернут первым, учитывая, что все изменения A уже находятся в B, тогда есть несколько ветвей. Это будет работать, если у вас есть команды, разбросанные по всему земному шару, и у вас обычно есть изменения, упорядоченные по приоритету.

Решение с тремя разными отраслями (для производства, разработки и функций) работает очень хорошо. Допустим, вы обнаружили какую-то ошибку в своем производственном коде, затем вы можете применить к ней патч, а затем выпустить его. Просто убедитесь, что вы не вносите никаких дополнений в производственную ветку и не вносите каких-либо серьезных изменений в производственную ветку. Вы и ваша команда должны будете соблюдать самодисциплину, чтобы не вносить существенных изменений в свою производственную ветвь. В производственной ветке должны быть исправлены незначительные ошибки, которые не гарантируют серьезных изменений в вашей производственной кодовой базе.