Блог

Итак, у нас есть проект, в котором одновременно обрабатывается несколько «основных» ветвей. Итак, есть 1.0.0, 2.0.0 и 3.0.0. Вещи, которые входят в 2.0.0, Не могут входить в 1.0.0 и т. Д. Каждая ветвь объединяется вперед, 1.0.0> 2.0.0> 3.0.0.

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

Итак, я думаю, мой вопрос в том, есть ли правильный способ настроить потоки для чего-то подобного?

Спасибо

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

Если вы очень активно работаете над несколькими выпусками одновременно, основная модель имеет меньшую ценность, поскольку вам нужно либо:

• слияние между родственными / двоюродными ветвями (что в основном работает нормально, но может стать неудобным, если было много рефакторинга)
• тщательно выбирайте изменения в основной строке и из нее, чтобы обеспечить правильный поток изменений (что обеспечивает более чистые слияния, но немного больше ручного отслеживания)

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

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

• сделайте каждый поток после начальной магистрали development потоком (я думаю, это самый разрешительный)
• установите mergeany параметр в каждом потоке (который позволяет объединять во всех направлениях, а не пытаться обеспечить «твердость», которая является концепцией основной модели)
• используйте -F опцию при слиянии, чтобы игнорировать направление потока (я думаю mergeany , это делает ненужным, если вы используете его последовательно)