Java-команда слияния - PullRequest
       21

Java-команда слияния

22 голосов
/ 30 ноября 2009

Каждый раз, когда я вижу конфликт в чем-то вроде импорта или изменения сигнатуры метода (например, переименования переменных) в моем SCM, я задаюсь вопросом, существует ли что-то вроде метода diff / merge с поддержкой языка, который может обрабатывать более раздражающие небольшие изменения, которые могут случиться на совместном проекте. Есть ли что-нибудь, что обрабатывает конфликты более плавно, работая в среде Unix?

Ответы [ 5 ]

5 голосов
/ 30 ноября 2009

Я согласен, что было бы замечательно, если бы такой инструмент существовал, но я не знаю ни одного. Я считаю, что их нет, потому что алгоритм слияния для каждого SCM (будь то git, hg, bzr, svn и т. Д.) Работает с наименьшим общим знаменателем, который представляет собой простой текст. Чтобы эти инструменты SCM действительно понимали синтаксис и семантику языка, они должны включать возможность синтаксического анализа языка. Кажется, что это просто слишком большая задача для любого SCM, чтобы включить возможность разбора Java, C #, Python, Ruby, Groovy, C, C ++ и т. Д., Не говоря уже о том, что каждый из этих языков имеет разные синтаксисы между версиями (например, дженерики Java не существовали до 1.5). Таким образом, SCM должен будет включать возможность обнаружения или настройки, чтобы знать, на каком языке и версии языка написан исходный код.

Я думаю, что более вероятно, что любая функция слияния, зависящая от языка, будет найдена в стороннем инструменте слияния (например, настройка инструмента слияния> в .gitconfig и настройка слияния пользовательского интерфейса> в .hgrc). Этот инструмент можно настроить так, чтобы он знал, что любые файлы .java в вашем проекте написаны на Java 1.6, а затем использует функции синтаксического анализа в JDK для генерации AST и выполнения некоторого «глубокого» анализа того, является ли изменение было значимым в контексте этого языка.

2 голосов
/ 13 июля 2010

Я ищу точно такую ​​же вещь. Эти поставщики инструментов слияния, вероятно, должны решить проблему такого рода семантического слияния с учетом языка ... если нет, мне придется стать одним из них:)

На данный момент, как трюк бедняка, я иногда препроцессирую 3 файла (базовый, наш, их) в их «каноническую форму», передавая их через членов Eclipse Code Cleanup / Organize Imports / Order.

Несмотря на ограниченность, это работает хорошо: в прошлый раз количество конфликтов уменьшилось до ~ 200 в 2. Я планирую обернуть это в скрипт и подключить к git merge tool.

Также был написан скрипт автоматического разрешения конфликтов импорта java, который просто сохраняет обе стороны импорта и добавляет комментарии для объяснения того, что происходит и что нужно делать: «организовать импорт».

0 голосов
/ 13 марта 2018

Чтобы упростить посадку на этой странице. Этот вопрос является обманом http://stackoverflow.com/questions/523307/semantic-diff-utilities (ответ на него в основном вопросе, но не очевидный)

И текущий инструмент, о котором я знаю (ответ на квест выше) - это символическое слияние - https://www.semanticmerge.com

Существует также https://www.devart.com/codecompare, который близок к тому, что вы хотите

0 голосов
/ 26 января 2011

git rebase не решает эту проблему? любые переменные переименования будут учтены в соответствующих коммитах. Git ReBase позволяет вам оставаться в синхронизации с коммитом вверх по течению. до тех пор, пока вы часто делаете перебаз (ежедневный выпуск?), у вас не должно быть таких глупых конфликтов, а если это так, то они, вероятно, являются настоящими конфликтами и не могут быть решены синтаксическим анализатором Java.

0 голосов
/ 30 ноября 2009

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...