Каковы преимущества ветвления "Лестница"?

Question

Я столкнулся с проектом, в котором мы используем разветвление лестницы. Для пояснения, это подход, при котором код разветвляется для разработки, и когда разработка завершается, а не сокращается до магистральной / основной линии, ветвь dev обозначается как живой кодовый набор, и из него берется новая ветвь. Это продолжается до бесконечности.

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

Спасибо, Том

Answer 1

Этот метод укусит вас в тот момент, когда вы захотите создать несколько веток и одновременно развить их. Слияние со стволом позволяет вам иметь параллельные ветви и легко объединять их по одной ветви за раз.

Answer 2

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

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

Answer 3

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

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

Answer 4

У этого подхода есть пара (потенциально незначительных) преимуществ.

Наиболее убедительные преимущества возникают из-за отсутствия необходимости объединять изменения обратно в основную ветку. Это позволяет легко сохранить ветку (старый «ствол») для версии, в которой вы выполняли ветвление, а также не требует усилий для продолжения в ветке dev. В действительности это ничем не отличается от наличия одного живого ствола и пометки или ветвления для релиза, за исключением того, что вы «перемещаете» свою разработку вместо того, чтобы перемещать свою помеченную ветку. Это может упростить поддержание чистых веток с меньшими усилиями, поскольку нет необходимости «отмечать» новую ветку для каждого выпуска - это просто происходит автоматически. Это небольшая экономия времени.

По моему опыту, есть один потенциальный недостаток. Я часто обнаруживал, что такой подход часто облегчает разработчикам случайное нарушение бинарной совместимости в библиотеках, так как вы всегда работаете над копией разработки, и каждый «выпуск» является отдельной веткой от этого. Поскольку для объединения обратно в магистраль не требуется никаких усилий, можно легко случайно сломать API. Это не главная проблема IMO, но об этом следует знать, поскольку в процессе слияния не предпринимается никаких усилий (что, по-видимому, часто обнаруживает большинство этих ошибок).