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

Question

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

remote:
  master

local:
  master
  feature

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

remote:
  master
  feature

local:
  master
  feature

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

remote:
  master
  feature

local:
  master
  feature -> origin/feature

и все хорошо.Отсюда я бы хотел переназначить ветку 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, но это может быть просто презентацией.

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

Answer 1

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

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

git push origin feature -f

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

git merge master
git push origin feature

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

Answer 4

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