У меня есть клиент, который настаивал на том, чтобы мы полностью отделили нашу новую разработку от основных веток на весь 2016 год. У них было 3-4 другие команды, работающие над приложением в различных областях. Многочисленные большие изменения были внесены (переключение, как делается внедрение зависимостей, очистка кода с помощью ReSharper и т. Д.). Теперь мне пришло в голову объединить main с нашей новой веткой разработчиков, чтобы подготовиться к продвижению наших изменений по цепочке.
При моем первоначальном извлечении слияния TFS сообщил о ~ 6500 файлов с разрешением конфликтов. Некоторые из них будут простыми, но некоторые из них будут намного сложнее (в частности, некоторые из контроллеров javascript, api и сервисов, поддерживающих эти контроллеры).
Есть ли подход, который я могу использовать, чтобы мне было легче?
Чтобы уточнить, я много раз выражал озабоченность этим подходом. Клиент был и знает о трудностях с этим. Поскольку они выбрали нехватку персонала QA (1 тестер на 4 разработчика, никакого автоматического тестирования, небольшое регрессионное тестирование), они настаивали на том, чтобы мы держали нашу ветвь изолированной от изменений в основной ветке под предлогом, что это уменьшит потребность в нашем тестер, чтобы знать об изменениях, вносимых в другом месте.
Одна из самых больших проблем здесь - это обновление до угловой версии и некоторых других сторонних программ - к сожалению, у нас нет хорошего способа построить это решение, пока все части не будут возвращены на место.
источник
Ответы:
Был бы простой способ отделить вашу новую разработку от основной ветки, не приводя вас к этой неудачной ситуации: любые изменения из ствола должны были бы ежедневно сливаться в вашу ветку разработки . (Был ли ваш клиент действительно настолько близоруким, что не мог предвидеть, что когда-нибудь ваш филиал должен вернуться обратно в основную линию?)
В любом случае, лучший подход - ИМХО попытаться повторить то, что должно было произойти из первых рук:
Это может сработать, когда команды строго соблюдают классические правила контроля версий («только коммитить скомпилированные, протестированные состояния» и «регистрировать рано и часто»).
После 365 повторений (или 250, если вам повезет, и вы можете связать работу для изменений выходных), вы почти закончите (почти, потому что вам нужно добавить количество изменений, которые произойдут с основной линией в течение периода интеграции ). Последний шаг - снова объединить обновленную ветку dev в ствол (чтобы вы не потеряли историю ствола). Это должно быть легко, потому что технически это должна быть только замена затронутых файлов.
И да, я серьезно, вероятно, нет ярлыка для этого. Может оказаться, что «ежедневные порции» иногда бывают слишком маленькими, но я бы не ожидал, что, скорее всего, ежедневные порции могут оказаться слишком большими. Я надеюсь, что ваш клиент платит вам очень хорошо за это, и что это настолько дорого для него, что он извлечет уроки из своей неудачи.
Я должен добавить, что вы можете попробовать это также с измененными сторонами - реинтеграция изменений из вашей ветки небольшими порциями в основную линию. Это может быть проще, когда в вашей ветке dev было гораздо меньше изменений, чем в транке, или большинство изменений произошло в новых исходных файлах, которые в настоящее время не являются частью транка. Это можно рассматривать как «портирование» функции с продукта A (ветка dev) на несколько иной продукт B (текущее состояние транка). Но если бы большинство сквозных рефакторингов было выполнено на основной линии, и они влияют на ваш новый код (коллизии слияния 6500, кажется, являются некоторым доказательством этого), возможно, будет проще, как я описал вначале.
источник
На этом этапе слияния я бы сказал, что автоматическое слияние может только усложнить процесс. У меня были похожие проблемы с филиалами, которые расходились более года, и самый эффективный метод, который у меня есть, - это сделать следующее:
В конце концов, предупреждения компилятора и различия станут вашими лучшими друзьями, продолжайте использовать unmerged diff, чтобы точно увидеть, что отличалось, и просто продолжайте. Там могут быть различные инструменты, которые вы могли бы использовать, чтобы помочь, но это будет зависеть от вас, чтобы найти, что лучше.
Ключ должен продолжать идти.
Редактировать:
Предупреждение: этот подход будет означать, что история управления версиями станет «испорченной», так как вы потеряете свидетельство слияния ветвлений с ветвями, а также историю не слитых ветвей.
Благодаря комментариям от «Джека Эйдли» и «17 из 26»
источник
Несколько лет назад у нас был клиент с одинаковыми требованиями по отделению филиалов. Так мы и сделали.
Мы никогда не сливали их филиал обратно. У них там была своя уникальная версия. Мы взяли с них дополнительную плату за изменения, так как по существу у нас было два главных ствола вместо одного основного ствола и ответвлений.
Мы попытались слиться с багажником, но через 2 недели мы решили отказаться от этих усилий, так как это тянуло часы времени без ощутимых преимуществ.
Так что, не сливай это обратно. Дальнейшее слияние критических исправлений с этой клиентской ветвью по мере необходимости и любые усовершенствования будут оплачиваться специально для этого клиента.
источник
Это не будет весело, но насколько болезненным это будет, зависит от характера изменений и от того, насколько они изолированы.
Я предлагаю вам попытаться максимально приблизить ветви путем рефакторинга, прежде чем вы сделаете фактическое слияние.
Инструмент слияния довольно тупой, потому что он смотрит только на текстовые различия и никак не понимает код. Если основная ветвь изменила имя класса, используемого в приложении, и ветвь функции использует старое имя в каком-то новом коде, тогда инструмент слияния не поймет, что имя класса также следует изменить в новом коде. Но если вы выполните рефакторинг в ветви B, чтобы переименовать класс, как в ветви A, он будет работать как в старом, так и в новом коде, и слияние пройдет гладко.
Во-вторых, вы должны проверить, насколько локализованы изменения в ветке разработки. Если изменения в ветви функций локализованы в нескольких областях, вам не нужно объединять незатронутый код, вы можете просто скопировать и перезаписать из основной ветви.
В тех областях кода, где произошли нетривиальные изменения в обеих ветвях, вы должны тщательно проверить код и решить, как его переписать.
источник