Перебазирование Git постоянно завершается сбоем и требует ручного вмешательства при слиянии

Question

У меня возникла проблема с перебазированием с master на ветку "deploy" в одном из моих репозиториев.

Мое репо настроено следующим образом:

master - of course, the main branch
deploy - a branch created where files like Capfile, deploy.rb etc are created and configured - these changes will NEVER be merged back into Master

Как правило, мой рабочий процесс таков:

1. Выполняйте разработку в главной ветке...проверяйте, улыбайтесь, берите на себя обязательства.
2. Оформить заказ deploy филиал
3. Выполнить git rebase master в ветке развертывания - раньше это работало без проблем
4. Нажмите на пульт дистанционного управления, а затем выполните cap deploy
5. Расслабься

Проблема, с которой я сейчас сталкиваюсь, заключается в том, что когда я выполняю git rebase master в ветке deploy появляется ошибка, требующая 3-стороннего слияния / ручного слияния (я не думаю, что сообщение об ошибке действительно достаточно общее для публикации).Git говорит мне выполнить слияние, а затем использовать git rebase --continue закончить - что никогда не срабатывает.

То, что, как я обнаружил, "делает" работу, запущено git rebase master --interactive, очищаю список выбора (в этом списке есть около 5 повторяющихся "коммитов", но с разными ссылочными номерами (одно и то же сообщение), поэтому я выберу один из них), а затем вручную выполняю слияние.Как только я сделаю это для каждого коммита, я смогу продолжить перебазирование, и все будет хорошо...

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

Итак, кто-нибудь знает, что может быть счастливым?Проект на самом деле не является "секретным", поэтому при необходимости я могу публиковать сообщения, журналы, графики ответвлений и т.д.

Спасибо

Answer 1

Похоже, что это может происходить из-за того, что вы изменили историю фиксаций этих "повторяющихся" коммитов таким образом, что у них другой sha1.Каждый sha1 уникален не только для коммита, но и для истории коммитов.Следовательно, невозможно (ну, крайне маловероятно, чтобы это произошло в течение жизни вселенной) иметь два идентичных sha1 в одной и той же истории или даже иметь два sha1 в двух разных историях.Если вы измените что-либо в своем коммите, например, с помощью изменения или интерактивной перебазировки, то вы измените sha1.Таким образом, два коммита, которые могут выглядеть одинаково, на самом деле обрабатываются по-разному.

Таким образом, очень вероятно, что вы выполнили ребазинг из другой ветки, выполнили какой-то тип интерактивного перебазирования или внесли изменения в коммиты, продолжили комментировать еще какой-то код, который изменил ту же часть кода, затем при следующем перебазировании у вас возникли конфликты, потому что коммиты, которые у вас есть в вашей локальной ветке, которые отличаются от ветки, из которой вы перебазируетесь, удаляются из ветки, подключается восходящий поток, включая тот коммит, который вы уже подключили и изменили sha1, а затем, когда коммиты воспроизводятся в ветке, вы сталкиваетесь с конфликтом, потому что состояние кода изменилось по сравнению с ожидаемым коммитом, потому что первоначально он был создан на основе истории, отличной от той, что сейчас есть в вашей ветке.Ух ты, это было длинное предложение...

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

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

Чтобы определить, какие файлы имеют конфликты слияния, выполните следующие действия:

git status

или

git ls-files -u

Как только вы узнаете, какие файлы конфликтуют, если у вас есть настройка mergetool, вы можете сделать:

git mergetool <file>

Если вы предпочитаете объединить вручную, вы можете найти маркеры и линии слияния, выполнив следующие действия:

grep -Hnr '^=\{7\}\|^<\{7\}\|^>\{7\}' *

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

git add <file>

чтобы добавить файл, добавьте его в индекс и снимите флажок unmerged.Когда вы закончите разрешать все несвязанные файлы, выполните

git rebase --continue

Чтобы завершить перебазирование.

Answer 2

Чтобы получить git rebase --continue для работы вам нужно фактически объединить конфликтующие файлы (отредактировать их, выбрать нужные части между маркерами конфликта “<<<<<<<”, “=======”, “>>>>>>>”) а потом git add их в индекс (в индексе они записываются как конфликтующие, добавление файла очищает его конфликтное состояние).Проверьте текущую разницу с помощью git diff --cached, тогда git rebase --continue если это выглядит правильно.

Прежде чем пытаться выполнить перебазирование (или после прерывания проблемного процесса), ознакомьтесь git log -p master..deploy чтобы просмотреть коммиты, которые вы пытаетесь перебазировать.Это один из них, который противоречит всему, что у вас есть в мастер.

Те коммиты, которые вы удаляете, удаляя их строки ‘выбора’ в git rebase -i могут быть не совсем одинаковыми (даже если у них одна и та же "тема" в сообщении о фиксации).Тот факт, что вы считаете, что должен быть только один из них, указывает на то, что с вашим развернуть филиал.Являются ли эти ‘дублирующие’ коммиты на кончике развернуть или после них есть другие коммиты?Может быть, увидев содержание этих ‘подозрительных’ коммитов (log -p, выше) даст вам ключ к разгадке их источника.

Answer 3

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

Пример менеджера слияний приведен в разделе это ТАКОЙ ответ.

Другое были обсуждены стратегии, но ключ остается:всегда рассматривайте слияние как "слияние в масштабах всего проекта", а не как объединение на основе файлов.Отсюда и атрибуты для уточнения этого объединения в масштабах всего проекта, когда дело доходит до некоторых "специальных" файлов.