Чтобы понять, когда нужно выполнить ветвление, спросите себя, почему вы в первую очередь разветвляетесь.
Есть три основные причины, по которым вам нужно ветвиться:
У вас есть несколько версий вашего продукта, и более старая версия имеет дефект. В этом случае вы создаете ветку с более старой версией и фиксируете ее на ветке. В противном случае вы должны включить весь новый код, который вы добавили с момента выпуска.
У вас есть несколько десятков программистов, работающих над проектом в Выпуске 1.0. Когда проект приближается к точке релиза, вы хотите прекратить добавлять функции и исправлять ошибки. Тем не менее, это оставляет большинству ваших программистов нечем заняться, кроме как крутить пальцы, в то время как два или три программиста, ответственные за выпуск, работают над завершением выпуска. Там просто не хватает работы для всех. В этом случае вы ветвите Выпуск 1.0 и делаете свой выпуск вне ветви. Тем временем остальные разработчики могут продолжить работу над выпуском 2.0. \
Обычно все разработчики работают над выпуском и вносят небольшие изменения. Тем не менее, есть крупный проект, который собирается изменить структуру вашего продукта. Если у вас есть разработчики, работающие над этим, проверяющие свой код в соединительном модуле с другими разработчиками, вы не сможете скомпилировать сборку и протестировать изменения. Вместо этого вы разветвляете этот специальный проект в собственную строку кода. Таким образом, реструктуризация бэкэнда выполняется на боковой ветви, в то время как остальная часть команды разработчиков может продолжить работу над стволом.
В последнем случае команда, работающая с основной магистралью, должна убедиться, что ее код не отстает от того, что происходит в магистрали. Они должны продолжать объединять изменения в стволе с их боковой ветвью. В противном случае различия в коде между боковой ветвью и транком станут слишком велики, чтобы выполнить простое объединение.
Вопрос в том, почему Дело № 3 намного сложнее, чем в двух других случаях. Ответ заключается в том, расходятся ли ветви друг от друга или сходятся друг к другу. В случае № 1 и № 2 ветви расходятся. В случае № 2 код версии 1.0 будет отличаться от кода версии 2.0, а код версии 1.0 будет еще более отличаться от кода версии 3.0. Фактически, когда-нибудь в будущем код в ветке Release 1.0 будет неактуальным.
Между тем, в случае № 3 ветви сильно сходятся друг с другом. Это означает, что вы должны держать их в синхронизации. Это требует усилий и контроля. Требуется много энергии, чтобы убедиться, что ответвления, которые в конечном итоге должны объединиться, должны оставаться синхронизированными.
Именно поэтому большинство сайтов теперь делают ветвления, когда это необходимо, и не используют старую систему функций или ветвей разработки. Это добавляет много сложности. Каждое отделение должно быть управляемым, и каждое объединение должно быть тщательно рассмотрено.
Кстати, это одна из причин того, что распределенные системы контроля версий не всегда лучше, чем централизованные. Я видел слишком много мест, где использовался Git, и тогда все разработчики работали над своим небольшим репозиторием и никогда не разговаривали друг с другом. За неделю до релиза мы получили десятки патчей, а затем поспешили объединить весь код в готовую версию.
Централизованное хранилище заставляет всех работать над одним и тем же набором файлов. Добавьте непрерывный процесс сборки, и вы можете быть уверены, что в этом выпуске не будет сюрпризов. Если все равно придется работать с централизованным репозиторием, распределенная система управления версиями на самом деле не так уж много добавляет к миксу и может вызвать проблемы, если вы позволите разработчикам жить в своих маленьких пещерах.