Вы столкнулись с проблемой слияния из ветки dev для тестирования слияния в svn и подсказках, необходимых для механизма мгновенного выпуска

Question

У нас было десять разработчиков, которые делали коммиты в ветке dev.Через неделю, как только все задачи будут выполнены, мне нужно объединить все коммиты, чтобы проверить ветвь для перебазирования, прежде чем я добавлю теги и объединю релизы в транк.При объединении ряда ревизий я поражен и отнимаю много времени, чтобы разрешить конфликты SVN.Когда я получаю конфликт: я обычно делал следующее:

1. Я всегда рассматриваю файл латентной ревизии, например: .r500 - последняя ревизия, которая мне нужна, и удаляю расширение, которое он генерируетнапример, filename.java.rev500, и удаление оставшихся, таких как мой, базовый файл и файлы предыдущих версий, которые он генерирует при возникновении конфликтов.Это лучшая практика и рекомендуется. Я всегда использую diff в журнале и проверяю файл последней версии вручную, рассматривая ревизию, когда получаю конфликт.

2. При объединении большинства конфликтующих, обновленные файлы я получаю эти символы, <<<<<<< .working </strong> и >>>>>>> .merge-right.r500. Нужно ли нам вручнуюудалите это в файлах, когда мы выполняем релизы.Даже иногда эти символы влияют на мою сборку и разрешаются после того, как я вручную удалил их.

3. Желательно ли объединять от 15 до 20 ревизий за раз, например, для включения 70 файлов в целомрелиз, лучше ли объединять 4-5 ревизий, разрешать конфликты и двигаться дальше с оставшимися ревизиями, но если я объединяю несколько ревизий и снова после оставшихся ревизий, это занимает много времени.Всякий раз, когда я делаю слияние, я должен всегда редактировать вручную, или любые лучшие методы и практики, которым я должен следовать.

Answer 1

Чтобы избежать многих конфликтов, вам нужно иметь только одну активную ветку разработки или хотя бы одну ветку разработки на каждое поддерево хранилища (например, project1, project2).

Из того, что вы пишете, я вижу, что ветки test / trunk также имеют много изменений. Вот почему у вас так много конфликтов. Вам нужно объединить изменения обратно из тестовой и внешней ветки в dev. Это уменьшит количество конфликтов.

В общем, вы должны стараться избегать множества параллельных активных веток, которые работают на одной и той же кодовой базе, иначе вы не сможете избежать многих конфликтов.

Также вы можете заняться разработчиками. Если они исправят что-то в тестовой ветке, их задача также должна состоять в том, чтобы объединить это с веткой dev. Это снова уменьшит количество конфликтов.