Перебазировка удаленных веток в Git

Я использую промежуточный репозиторий Git для зеркалирования удаленного репозитория SVN, из которого люди могут клонировать и работать. В промежуточном репозитории его основная ветвь перебазируется каждую ночь из вышестоящего SVN, и мы работаем над функциональными ветвями. Например:

remote:
  master

local:
  master
  feature

Я могу успешно перенести свою ветвь функций обратно на удаленное устройство и в итоге получить то, что ожидаю:

remote:
  master
  feature

local:
  master
  feature

Затем я переустановил ветку для отслеживания удаленного:

remote:
  master
  feature

local:
  master
  feature -> origin/feature

И все хорошо. Отсюда я хотел бы переместить ветвь функций в ветку master на удаленном компьютере, но я хотел бы сделать это с моей локальной машины. Я хотел бы иметь возможность сделать:

git checkout master
git pull
git checkout feature
git rebase master
git push origin feature

Для поддержания ветки удаленной функции в актуальном состоянии с удаленным мастером. Однако этот метод заставляет Git жаловаться:

To <remote>
 ! [rejected]        feature -> feature (non-fast-forward)
error: failed to push some refs to '<remote>'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.

git pullделает трюк, но вызывает коммит слияния, которого я хотел бы избежать. Я обеспокоен тем, что в сообщении говорится, feature -> featureа не, feature -> origin/featureно это может быть просто презентация.

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

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

Вы можете форсировать толчок после перебазировки, если это только вы:

git push origin feature -f

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

git merge master
git push origin feature

Это гарантирует, что у вас есть общая история с людьми, с которыми вы сотрудничаете.

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

Это моя статья на тему ветвления для каждой функции .

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

Приятно, что ты поднял эту тему.

Это важная вещь / концепция в git, о которой полезно знать многим пользователям git. git rebase - очень мощный инструмент, позволяющий вам объединять коммиты, удалять коммиты и т. д. Но, как и в случае с любым мощным инструментом, вам, в основном, нужно знать, что вы делаете, иначе что-то может пойти не так.

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

Вот почему важно помнить, что после того, как вы нажали коммиты, вы не должны делать это позже. Причина, по которой это важно, заключается в том, что другие люди могут использовать ваши коммиты и основывать свою работу на ваших вкладах в базу кода, и если впоследствии вы решите переместить этот контент из одного места в другое (перебазировать его) и подтолкнуть те изменения, то другие люди получат проблемы и придется перебазировать свой код. Теперь представьте, что у вас 1000 разработчиков :) Это просто вызывает много ненужных переделок.

Поскольку вы перебазировали featureповерх нового master, ваш местный featureбольше не перемотка вперед origin/feature. Так что, я думаю, в этом случае вполне нормально переопределить проверку ускоренной перемотки вперед git push origin +feature. Вы также можете указать это в вашей конфигурации

git config remote.origin.push +refs/heads/feature:refs/heads/feature

Если другие люди работают поверх origin/featureних, они будут обеспокоены этим принудительным обновлением. Вы можете избежать этого путем слияния нового masterв featureвместо перебазирования. Результат действительно будет ускоренным.

Вы можете отключить проверку (если вы действительно уверены, что знаете, что делаете), используя --forceопцию для git push.