Как разрешить конфликты в EGit

Ответ 1

Используете ли вы представление Team Synchronize? Если так, то проблема. Разрешение конфликтов в представлении Team Synchronize не работает с EGit. Вместо этого вам нужно использовать представление Git Repository.

Откройте перспективу Git. В представлении Git Repository перейдите в раздел "Филиалы" → "Локальные" → "Основные" и щелкните правой кнопкой мыши → Объединить

Следует автоматически выбрать Remote Tracking → origin/master. Нажмите Merge.

Это должно показать result:conflict.

Откройте конфликтующие файлы. У них должен быть старый sk000l >>>> ===== <<<< конфликт слияния стиля в файлах. Отредактируйте файл, чтобы разрешить конфликт, и сохраните.

Теперь в представлении "Git Staging" он должен показать измененный файл в "Unstaged Changes". Щелкните правой кнопкой мыши и " Добавить в индекс "

Повторите для всех оставшихся файлов.

Теперь из представления "git staging" сделайте коммит и нажмите. Поскольку Git/Eclipse теперь знает, что вы слили изменения удаленного источника в ваш мастер, вам следует избегать ошибки, не связанной с перемоткой вперед.

Ответ 2

Я также сбиваю с толку разрешение конфликтов слияния в EGit. Когда я готов внести некоторые изменения в общий репозиторий, шаги, которые я узнал, следующие:

• Щелкните правой кнопкой мыши по проекту и выберите команду: Commit....
• Просмотрите мои изменения, чтобы проверить, что я не совершаю никаких изменений. Я сделал случайно или несвязанные изменения, о которых я забыл. Запишите сообщение фиксации во время просмотра изменений.
• Я настроен оптимистично, поэтому начинаю с нажатия кнопки Commit и Push. Если никто другой не внес каких-либо изменений, я закончу. Если у кого-то есть, то фиксация завершается успешно, а нажатие отклоняется.
• Щелкните правой кнопкой мыши по проекту и выберите команду: Pull. Если конфликтов нет, выберите команду "Нажать вверх", и я закончил.
• Если есть конфликты, просмотрите проводник пакетов, чтобы увидеть, какие файлы конфликтуют. Щелкните правой кнопкой мыши по каждому конфликтующему файлу и выберите команду "Команда: инструмент слияния". Он отобразит все изменения в обеих версиях файла, при этом любые конфликты будут показаны красным цветом. Нажмите на кнопку, чтобы объединить все неконфликтные изменения, а затем отредактировать любые красные секции вручную. Также есть кнопка, показывающая трехстороннее слияние, включающее общий предок.
• Сохраните изменения в файле. Если вы хотите, вы можете сравнить его с HEAD, чтобы узнать, какие изменения вы делаете поверх изменений, которые вы только что вытащили.
• Щелкните правой кнопкой мыши файл и выберите команду: Добавить в индекс, чтобы сообщить EGit, что вы закончили слияние этого файла. Для меня это наименее интуитивный шаг, но в командной строке git также используется команда add, чтобы показать, что слияние завершено.
• Повторите для любых других конфликтующих файлов.
• Когда все файлы объединены, щелкните правой кнопкой мыши по проекту и выберите команду: Rebase: Continue Rebase. Если есть более противоречивые коммиты, вернитесь к конфликтам.
• Когда переполнение будет завершено, запустите свои тесты, чтобы убедиться, что rebase ничего не сломал.
• Щелкните правой кнопкой мыши проект и выберите команду "Нажать вверх".

Ответ 3

Это руководство было полезно для меня http://wiki.eclipse.org/EGit/User_Guide#Resolving_a_merge_conflict.

ОБНОВЛЕНО Просто примечание о моей процедуре, вот как я продолжаю:

1. Передать Мое изменение
2. Fetch (Синхронизировать рабочее пространство)
3. Тянуть
4. Управление конфликтами с помощью инструмента слияния (Team-> Инструмент слияния) и сохранения
5. Добавить каждый файл на сцену (Команда → Добавить в индекс)
6. Теперь сообщение коммита в окне рабочей области предварительно заполнено "Объединено XXX". Вы можете оставить как есть или изменить сообщение коммита
7. Совершить и нажать

В некоторых случаях это опасно, но очень полезно избегать использования внешних инструментов, таких как Git Extension или Source Tree

Ответ 4

Я знаю, что это более старая статья, но я просто попал с подобной проблемой и смог ее разрешить, поэтому я решил поделиться ею.

( Обновление. Как отмечено в комментариях ниже, этот ответ был до включения функции e2 для "git stash" ).

Что я сделал:

• Скопируйте локальную копию конфликтующего файла, который может или не может иметь никаких изменений в версии на восходящем потоке.
• Внутри Eclipse "Вернуть" файл в версию прямо перед конфликтом.
• Запустите "Pull" из удаленного репозитория, позволяя всем изменениям синхронизироваться с локальным рабочим каталогом. Это должно очистить обновления, поступающие в вашу файловую систему, оставив только то, что вам осталось нажать.
• Проверьте текущую версию конфликтующего файла в рабочем каталоге с копией, которую вы скопировали. Если есть какие-либо различия, выполните правильное слияние файлов и зафиксируйте эту версию файла в рабочем каталоге.
• Теперь "Нажимайте" свои изменения.

Надеюсь, что это поможет.

Ответ 5

Просто щелкните правой кнопкой мыши конфликтующий файл и добавьте его в индекс после разрешения конфликтов.

Ответ 6

Чтобы разрешить конфликты, используйте Git stash, чтобы сохранить ваши незафиксированные изменения; затем разверните набор изменений удаленного репозитория; затем откройте свой локальный тайник, чтобы повторно применить незафиксированные изменения.

В Eclipse v4.5 (Mars) для сохранения изменений (относительно недавнего добавления, не было в предыдущем EGit) я делаю это: щелкните правой кнопкой мыши по проекту Eclipse верхнего уровня, который в Git control, выберите Team, выберите Stashes, выберите Шкатулка Изменений; Откроется диалоговое окно для запроса сообщения коммита тайника.

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

Ответ 7

Этот подход аналогичен решению "stash", но я думаю, что это может быть более понятно:

• Ваш текущий локальный филиал является "мастером", и у вас есть локальные изменения.
• После синхронизации появляются входящие изменения, и некоторые файлы необходимо объединить.
• Итак, первым шагом является переход на новую локальную ветвь (например, my_changes):
  • Команда → Switch To → Новая ветка
    • Имя ветки: my_changes (например)
• После переключения на новую ветку все незавершенные локальные изменения все еще существуют. Итак, скопируйте все свои локальные незафиксированные изменения в новую ветку my_changes:
• Вернитесь к локальной ветке "master" :
  • Команда → Switch To → master
• Теперь, когда вы выбираете Team → Synchronize Workspace, не ожидается появления файлов слияния.
• Выберите команду → Pull
  • Теперь локальная ветвь "master" обновлена ​​относительно удаленной ветки "master" .
• Теперь есть два варианта:
  • Вариант 1:
    • Выберите команду → Объединить, чтобы объединить исходные локальные изменения с локальной ветвью "my_changes" в локальную ветвь "master" .
    • Теперь скопируйте входящие изменения с предыдущего шага в локальную ветвь "master" и нажмите их на удаленную ветвь "master" .
  • Вариант 2:
    • Переключитесь снова на локальную ветвь my_changes.
    • Объединить обновления из локальной ветки "master" в ветку "my_changes".
    • Продолжить текущую задачу в ветке my_changes.
    • Когда задача выполнена, используйте параметр 1 выше, чтобы обновить как локальную "ведущую" ветвь, так и удаленную.

Ответ 8

Поскольку это проблема, с которой мы сталкиваемся более часто, ниже приведены шаги по ее решению.

1. Откройте перспективу Git. В представлении Git Repository перейдите в раздел "Филиалы" → "Локальные" → "Основные" и щелкните правой кнопкой мыши → Объединить

2. Следует автоматически выбрать Удаленное отслеживание → * origin/master. Нажмите Merge.

3. Запустить сцену в Eclipse.

4. Дважды щелкните файлы, которые изначально показывали конфликт

5. В представлении слияния конфликтов, выбрав стрелку влево для всех изменений без конфликтов + конфликт слева направо, вы можете разрешить все конфликты.

6. Сохраните объединенный файл.

7. Сделать команду → вытащить из Затмения снова.

У вас все настроено :)

Ответ 9

Более ранний процесс разрешения конфликтов (через промежуточное представление) в Eclipse казался намного более интуитивным несколько лет назад, поэтому либо инструмент больше не функционирует так, как я привык, либо я вспоминаю процесс разрешения конфликтов слияния в SVN хранилища. Несмотря на это, при щелчке правой кнопкой мыши по конфликтующему файлу появилась изящная опция меню "Пометить как объединенное".

Перейдя к 2019 году, я использую представление " Git Staging " в Eclipse (v4.11). На самом деле я использую STS (Spring Tool Suite 3.9.8), но я думаю, что представление Git Staging - это стандартный плагин Eclipse для работы с проектами на основе Java/Spring. Я разделяю следующий подход на случай, если он кому-нибудь поможет, и потому что я устаю или разрешаю конфликты слияний из командной строки GIT. ;-)

Поскольку функция, которую я помню, теперь утрачена (или, возможно, сделана по-другому с текущей версией GIT и Eclipse), вот текущие шаги, которые я сейчас следую, чтобы разрешить конфликты слияния через Eclipse с помощью репозитория GIT. Это кажется наиболее интуитивным для меня. Очевидно, из числа полученных ответов ясно, что существует много способов разрешения конфликтов слияния. Возможно, мне просто нужно переключиться на JetBrains IntelliJ с их трехсторонним инструментом слияния.

1. Дважды щелкните по файлу-нарушителю.
2. Появится интерфейс "Сравнение текста" с параллельными представлениями конфликтующих коммитов.
3. Определите, какое представление является локальным состоянием файла или самой последней фиксацией.
4. Внесите изменения в локальное окно, добавив или отредактировав изменения из оскорбительного коммита.
5. Когда требуемый набор изменений будет рассмотрен и обновлен, щелкните правой кнопкой мыши на файле без метки.
6. Нажмите кнопку "Добавить в индекс", и ваш файл будет добавлен в промежуточные изменения.
7. Это также удаляет конфликтующий файл из списка без тегов, что указывает на то, что он был "помечен как объединенный".
8. Продолжайте этот процесс с каждым дополнительным файлом в конфликте.
9. После повторного просмотра всех конфликтующих файлов убедитесь, что все нужные файлы (включая дополнительные изменения) находятся в стадии подготовки.
10. Добавьте соответствующее сообщение коммита.
11. Зафиксируйте и отправьте "объединенные" файлы в исходный репозиторий, и это официально помечает ваши файлы как объединенные.

ПРИМЕЧАНИЕ. Поскольку пункты меню не являются интуитивно понятными, некоторые вещи могут вводить в заблуждение. Например, если вы сохранили какие-либо обновления локально и попытаетесь повторно открыть конфликтующий файл, чтобы подтвердить, что сделанные вами изменения сохранились, это может привести к путанице, поскольку исходное состояние конфликта открыто... а не ваши изменения.

Но как только вы добавите файл в индекс, вы увидите ваши изменения там.

Я также рекомендую при внесении изменений, которые приводят к конфликту слияний, сначала "прятать" локальные изменения, а затем снова вносить изменения. По крайней мере, с GIT, как защита, вам не разрешат извлекать внешние изменения, пока вы не отмените свои изменения или не сохраните их. Откажитесь и вернитесь в состояние HEAD, если изменения не важны, но сохраните их в противном случае.

Наконец, если у вас изменяется только один или два файла, рассмотрите возможность их перетаскивания в отдельные текстовые файлы в качестве ссылки, затем вернитесь к HEAD и затем вручную обновите файл (-ы) при переносе изменений.

Ответ 10

GIT имеет самый раздражающий способ разрешения конфликтов (в отличие от svn, где вы можете просто сравнить и внести изменения). Я чувствую, что у Git сложный процесс разрешения конфликтов. Если бы я решил, я бы просто взял другой код из GIT как свежий, добавил свои изменения и зафиксировал их. Это просто и не очень ориентировано на процесс.