Многие предположения об использовании основной модели исходят из среды, в которой выпуски удаляются относительно редко (два раза в год) и исправляются только для критических ошибок, поэтому изменения, которые должны переходить от одного выпуска к другому, как правило, скорее исключение, чем правило. В этой модели подавляющее большинство слияний происходит просто из новейшего релиза (например, пока релиз стабилизируется, что происходит в момент цикла, когда в предшествующем релизе очень мало активности) или из ветки разработки. обратно в основную ветку, а из основной ветки обратно в ветки разработки (поскольку ветки разработки в основном работают над новыми функциями, предназначенными для основной ветки, а не каких-либо выпускных веток). Изменения переходят из основной ветки в ветку релиза только в том случае, если они отбираются вручную для устранения критической ошибки (что случается редко), и никогда прямо из ветки разработки в ветку релиза. Немного неловко выбирать исправление из старой ветки релиза до нескольких веток более поздних релизов, но в этой модели это происходит очень редко, поэтому неловкость не имеет большого значения.
Если вы очень активно работаете над несколькими релизами одновременно, основная модель имеет меньшее значение, поскольку вам нужно:
- слияние между родственными/двоюродными ветвями (что в основном работает нормально, но может стать неудобным, если было много рефакторинга)
- тщательно выбирать изменения в основную ветку и из нее, чтобы обеспечить правильный поток изменений (что делает слияния более чистыми, но немного более ручным отслеживанием)
Ортодоксальная рекомендация здесь, вероятно, будет состоять в том, чтобы переосмыслить вашу методологию/политику выпуска, чтобы не требовать такого большого водопада, но я предполагаю, что у вас есть бизнес-причины требовать, чтобы это работало таким образом. Учитывая это ограничение, я думаю, вы, вероятно, вообще не хотите использовать концепцию различных типов потоков и потоков, поскольку в них есть предположения о встроенной модели основной линии, а то, что вы делаете, принципиально не является моделью разработки основной линии.
Чтобы реализовать неосновную модель в потоках (которая все еще имеет некоторую ценность без руководств по управлению потоком, поскольку она поможет вам управлять представлениями клиентов и еще чем-то), вы, вероятно, захотите использовать некоторую комбинацию:
- сделать каждый поток после начальной основной линии потоком
development (я думаю, это наиболее допустимый)
- установите параметр
mergeany в каждом потоке (что позволяет объединяться во всех направлениях, а не пытаться обеспечить жесткость, которая является концепцией основной модели)
- используйте параметр
-F при слиянии, чтобы игнорировать направление потока (я думаю, что mergeany делает это ненужным, если вы используете его последовательно)
person
Samwise
schedule
05.12.2020
