Git: каждое обращение к мастеру происхождения вызывает слияние с сообщением

Каждый раз, когда я делаю

git pull origin master

Git открывает редактор и просит меня написать комментарий о слиянии перед фиксацией. Любая идея, почему это может произойти? Другой разработчик также работает над мастером и не сталкивался с этой проблемой.

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


git git-pull git-merge
person Studio4Development    schedule 06.03.2013    source источник
comment
Вы делаете git commit в первую очередь?   -  person bozdoz    schedule 07.03.2013
comment
Ваши pull всегда просто добавляют к тому, что было раньше, или вы тем временем commit делаете что-то еще? Возможно, вам следует вместо этого делать git pull --rebase?   -  person vonbrand    schedule 07.03.2013
comment
@bozdoz - да, я сначала делаю местный git commit. @vonbrand - я не совсем понимаю, что вы спрашиваете о pull   -  person Studio4Development    schedule 08.03.2013
comment
@Studio4Development Теперь я столкнулся с вашей проблемой, пожалуйста, предложите мне способ решить эту проблему, спасибо :)   -  person Rong Nguyen    schedule 14.03.2014
comment
вы нашли какое-нибудь решение. Я вижу это со всеми своими сверстниками только с одним репо. Не уверен, что настройка перепутана. Каждый раз, когда я тяну, с 0 изменениями на моей локальной машине, он предлагает слияние, слияние будет с теми же файлами из предыдущей фиксации.   -  person sandeep koduri    schedule 30.11.2015

Ответы (3)


arrow_upward
6
arrow_downward

git pull это git fetch, за которым следует git merge. Начиная с Git 1.7.10, git merge открывает редактор при слиянии (см. txt" rel="noreferrer">примечания к выпуску). Другой разработчик, вероятно, использует более старую версию Git.

person Richard Hansen    schedule 06.03.2013
comment
Является ли Git 1.7.10 последней версией? Я использую Git около года, и все это время я всегда обновлял свои локальные ветки, используя git pull — он никогда не делал того, что делает сейчас. Если git pull изменился, то как правильно получить изменения с исходного сервера? - person Studio4Development; 08.03.2013
comment
@Studio4Development: Git 1.7.10 был выпущен 06 апреля 2012 г., хотя дистрибутиву вашей операционной системы может потребоваться некоторое время, чтобы получить более новую версию. Поведение git pull остается таким же, как и было, за исключением того, что теперь он дает вам возможность редактировать сообщение для сгенерированного им коммита. Если вы хотите старое поведение, вы можете сделать git pull --no-edit. (Однако я рекомендую вообще избегать git pull. Это ужасная команда, и у меня есть суровые слова для любого коллеги, которого я поймаю на использовании git pull.) - person Richard Hansen; 09.03.2013
comment
Какую команду или команды вы используете для извлечения изменений из удаленного репо для ветки, над которой вы сейчас работаете? - person Studio4Development; 13.03.2013
comment
@Studio4Development: см. нижнюю часть моего ответа по адресу stackoverflow.com/questions/15316601/ - person Richard Hansen; 13.03.2013
comment
Я знаю, что это старо, но я получаю это с git версии 2.15.2 в 2018 году. Что сбивает с толку, так это отсутствие локальных изменений, и я просто хочу получить изменения от другого разработчика (1 новый коммит), и он говорит мне, что это необходимо сливаться, когда сливать нечего. Что еще более странно, так это то, что первая попытка ничего не сбрасывает, жалуется на слияние, вторая попытка тоже жалуется, но сносит комит... - person MikeyT; 12.11.2018

arrow_upward
1
arrow_downward

Я не эксперт по git, но я столкнулся с таким поведением и мне удалось вернуться в рабочее состояние, поэтому вот мои советы, все из которых работают с git версии 2.28.0 (и, вероятно, более ранние версии) . Я подозреваю, что кто-то, кто был более опытен в git, мог бы упростить этот ответ.

Это происходит со мной, когда я что-то сделал, чтобы испортить мою локальную ветку master/main, из-за чего она не синхронизируется с той, которую она должна отслеживать. Я еще не понял, что я сделал, чтобы все испортить, поскольку это случалось недостаточно часто, чтобы я мог диагностировать ошибку в своем поведении. [Обновление: я думаю, что теперь я видел одно поведение в моем собственном рабочем процессе, которое вызывает это. Я захожу на GitHub, чтобы просмотреть PR, и использую ссылку для копирования из информации о инструкциях командной строки, чтобы узнать, как получить копию PR в моей рабочей области. Первая из двух копируемых команд — git checkout -b .... Однако иногда я непреднамеренно делаю это в рабочей области, в которой уже есть ветка с таким именем (как правило, я уже пробовал более ранний черновик PR), поэтому команда не работает, я все еще нахожусь в своей главной/основной ветке. , а затем вставляется следующая команда и объединяет ветку с моим master/main. Затем мне требуется некоторое время, чтобы понять, что все запуталось].

Я замечаю, что попал в это состояние двумя способами:

  • через всплывающее окно редактора, когда я делаю git pull origin master (как указано в OP)
  • когда PR, который я отправил на GitHub, показывает коммиты в форме Merge branch 'master' of https://github.com/[myOrg]/[myRepo] into master

Вот как я исправляю это, когда это происходит:

  • First, I find the oldest merge commit with this message in my branch's history:
    • browse the log: git log
    • искать в прошлом самый старый коммит с сообщением Merge branch 'master' of https://github.com/[myOrg]/[myRepo] into master
    • найдите SHA коммита непосредственно перед этим (т. е. точку, в которой моя ветка master отклоняется от той, которую она должна отслеживать)
  • Back my branch up to that SHA: git checkout [SHA]
    • this will put your branch into 'detached HEAD' state
  • Переименуйте мою испорченную основную ветку, чтобы убрать ее с пути git branch -m master master-broken (по желанию вы можете удалить ее, но это безопаснее, и вы всегда можете удалить ее позже)
  • Переименуйте мою текущую отдельную ветку HEAD в master: git checkout -b master
  • Верните ветку туда, где она должна быть: git pull [upstream source] master (где, в случае OP, я ожидаю, что это будет git pull origin master)

Ключевым моментом для понимания этого исправления является осознание того, что в ветке master нет ничего особенного — это просто соглашение. Так что нет проблем с его удалением (или переименованием) и созданием нового с тем же именем.

person Brad    schedule 04.03.2021

arrow_upward
0
arrow_downward

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

person jperl    schedule 09.06.2021