Перебазирование git для линейной истории

Вчера был аналогичный вопрос относительно git pull --rebase с отличным ответом от @Bert F. Предлагаю вам взглянуть на него, чтобы лучше понять, как на самом деле работает команда. stackoverflow.com/questions/78802778/… К сожалению, хотя git pull --merge соответствует git fetch + git merge, git pull --rebase не равно git fetch + git rebase.

Забудьте о git pull (вас ввели в заблуждение миллионы плохих руководств) и попытайтесь пересмотреть свое понимание Git без использования git pull. Это приносит больше вреда, чем пользы. Я использовал Git 13 лет, не запуская его git pull, ни разу. Перебазирование меняет историю ветки. Если его нажать, git push отказывается работать. Вам нужно использовать git push --force или, еще лучше, git push --force-with-lease. Прочтите документацию git push: git-scm.com/docs/git-push

Если вас устраивают параллельные линии, зачем стремиться к линейной истории? В линейной истории нет никакой добродетели.

@dani-vta Указанный пост и ответ не относятся к этому случаю.

@j6t да, извини, мне следовало расширить свой комментарий. Я поделился этой ссылкой только потому, что увидел некоторую путаницу в том, как ОП думал, что git pull --rebase работает. Это было не решение, а просто дополнительное разъяснение. @Axiac на самом деле очень хорошо заметил, что не использовал git push --force среди некоторых неправильных/отсутствующих вещей, сделанных OP.

Я согласен с оценкой ОП о том, что проблема заключалась в регулярном «git pull» удаленной функциональной ветки после «git pull --rebase origin main». Как только произошло перебазирование (из git pull --rebase), удаленная ветка больше не была действительной, и ее следовало принудительно переместить, а не вытащить. Извлечение с помощью слияния после извлечения с помощью rebase — вот что привело к созданию дубликатов коммитов.

Итак, прочитав все это, я понял, что принудительное нажатие после перебазирования - это нормально? Я правильно понял? Для меня «силовое нажатие» всегда представлялось как БОЛЬШОЕ НЕТ-НЕТ. Как тогда решить совместную работу, у всех остальных нет принудительных изменений в своих локальных ветках?

Есть ли у кого-нибудь ответ, как в этом случае получить линейную одну строку?

Привет, неожиданная история коммитов на вашем скриншоте была из ветки master или ветки feature? Я был в замешательстве, так как мог запустить git checkout feature -> git pull --rebase origin master, а затем смог запустить git push, чтобы отправить коммиты в свою feature ветку. История коммитов в моей функциональной ветке будет выглядеть так: A-B-E-C'-D'. Кажется, вы отправили коммиты с помощью коммита слияния на master. Был ли пропущен какой-либо шаг для воспроизведения проблемы?

Не могли бы вы попробовать запустить git log feature --oneline и git log origin/master --oneline, чтобы дважды проверить историю коммитов и сравнить идентификатор коммита в каждой локальной ветке перед отправкой?

С тех пор я удалил это репо, поэтому не могу точно проверить, но в названии самого последнего коммита написано: «Объединить ветку «feat....», поэтому я предполагаю, что это дерево происходит из «главной ветки».

Попробую повторить еще раз и сделать так, как вы просили.

Вы можете использовать эти git log команды для ведения записей каждой git команды, которая может изменить историю коммитов и идентификатор коммитов. Нам было бы полезно понять, как это было воспроизведено.

Итак, мое первоначальное предположение, что это изображение было из основной ветки, было неверным, на самом деле оно было в функциональной ветке. Я воспроизводил эту проблему несколько раз, и она всегда без ошибок создает такой график. У меня есть список шагов для воспроизведения, но он не подходит для «комментария», если хотите, я могу отредактировать вопрос. git log --oneline указывает на следующий порядок: A--B--C--D--E--C'--D' после git pull и git push.

Это кажется безумием... git pull полностью разрушает/повреждает цель git rebase, которую я хочу продвигать/сохранять. Коммиты C' и D' по сути будут «пустыми», потому что изменения уже были реализованы C и D... извлечение из удаленной функции (чтобы вернуться к ней - как того требует git) после перебазирования - это как если бы я только сделало обычное слияние с мастером, победив всю цель перебазирования

Невозможно перебазировать ветку объекта (т. е. иметь линейную историю) без какого-либо принудительного нажатия позже (ну, я думаю, вы могли бы удалить удаленную ветку и воссоздать ее из новой локальной). Непринудительное нажатие требует, чтобы локальная ветка добавляла только коммиты к кончику удаленной — перебазирование явно перемещает всю ветку.

Я не против обновить локальный мастер, я думал, что pull --rebase — это просто ярлык. Как обеспечить совместную работу локальных компьютеров товарища по команде, у которых есть другая копия из-за push -f? Просто попросить их удалить свои копии и вытащить? Что, если у них есть локальные коммиты (еще не отправленные), основанные на предыдущей истории, есть ли способ изменить их?