Мои скромные наблюдения: слияние ветвей страшно.Во многих случаях изменения, сделанные разными разработчиками, являются совершенно отдельными и поэтому плавно объединяются.Но в любом загруженном проекте будут времена, когда изменения вступают в конфликт.Если вам повезет, SVN распознает конфликт и выдает ошибки во время слияния.Если вам повезет меньше, SVN не поймает его, но не скомпилирует.В любом случае, теперь кто-то должен выяснить, как соединить изменения.Иногда это очевидно и просто.Но у меня было много раз, когда мне приходилось собирать разработчиков, которые вносили изменения, чтобы мы могли понять, что делать.
Если вам очень не повезло, ни SVN, ни компилятор не видят проблемы, конфликтующие изменения переходят в рабочий процесс, и программа ведет себя некорректно.
Из этого наблюдения я прихожу к двум выводам: (а) Сделайте как можно меньше веток.Или, точнее, разработайте свою стратегию, чтобы сделать как можно меньше слияний.И (b) Делайте слияния с кодом, пока он еще находится в процессе тестирования.
Некоторое время у моей компании была стратегия ветвления, которая гласила, что у каждого проекта есть свой собственный филиал, тестирование этого филиала, и когда мы былиГотовые к развертыванию в производство, мы объединили все ветви, которые будут включены в этот выпуск, скомпилированы и развернуты.Это оказалось действительно очень плохой идеей.Кто-то попытался бы разрешить конфликты слияния за день до развертывания, и результаты слияния никогда не проверялись.Множество тонких ошибок попало в производство.
Для чего мы использовали эту стратегию: большая часть разработки выполняется в транке.Когда релиз готов к передаче группе тестирования, мы очищаем ветвь для него.Затем работа над следующим выпуском продолжается в багажнике.Любые исправления ошибок в текущем выпуске выполняются в ветке, а изменения в этой ветке периодически объединяются обратно в транк.Иногда необходимо было работать над тремя выпусками одновременно, то есть один выпуск находился в стадии тестирования, другой был близок к тому, чтобы быть готовым к тестированию, и теперь нам нужно начинать со следующего выпуска.В этом случае у нас будет тестовая ветвь, транк для текущего выпуска и ветка «pre» для следующего выпуска.Когда текущий выпуск перешел в тестовую группу, мы объединили ветку «pre» в транк, и она стала текущим выпуском.
Недавно мы начали экспериментировать с немного другой стратегией.Когда релиз находится в тестировании, мы все равно отрываем для него отдельную ветку.Но любые исправления, выходящие из тестирования, производятся в транке, а затем эти исправления объединяются из транка в тестовую ветку.Это означает, что вся разработка происходит в транке, и слияния всегда происходят из транка в другое место.Это имеет два больших преимущества: во-первых, разработчики всегда тестируют с транком, поэтому у нас больше уверенности в том, что код в транке хорош.Группа тестирования будет тестировать ветку релиза, поэтому мы уверены, что ветка релиза хороша.То есть мы уверены, что обе ветки будут проверены.Когда вы вносите изменения в ветке, а затем сливаетесь обратно в ствол.есть небольшая уверенность, что кто-нибудь проверит результаты этого слияния.Во-вторых, багажник всегда имеет полную историю «вины» каждого модуля.Когда вы сливаетесь из веток обратно в ствол.история в стволе приписывает все изменения от ветви человеку, который сделал слияние, а не человеку, который действительно сделал изменение, и комментарий имеет тенденцию быть неинформативным "слитый из brach xyz".Когда вы переходите от транка к ветке, убедитесь, что ветка теперь показывает «неправильного» человека и неинформативный комментарий, но транк имеет хорошую историю.Есть одно место, куда можно пойти за историей, вместо того, чтобы пытаться преследовать ветви.