Git push and pull не может быть «ускоренной перемоткой вперед» на git-сервере bonobo

Question

У меня есть сервер Bonobo Git , который должен "обрабатывать синхронизацию" как минимум на двух компьютерах.

Все работало нормально, но в последнее время я столкнулся с однимбольшая проблема с ним и связанная вторая с самим git:

1. Я не могу просто протолкнуть в него каждого клиента, не получив увядшую проблему «не-перемотки вперед», и* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Следующее не является копией, но это команда, которую я использую при получении.проблема и, насколько я помню, предупреждение должно быть очень похоже на это:

   git push -u "server"
   ! [rejected]        server/master     -> master  (non-fast-forward)
   

2. Сегодня я также не могу даже получить из одного клиента в другого, не получив"не-быстрая перемотка вперед"Затем я попытался перенести его на сервер с помощью опции зеркала, которая является единственной, которая работает для вставки на сервер из-за проблемы # 1 и извлечения с сервера на моей машине.К моему удивлению, это сработало!Но теперь, пытаясь получить или извлечь из другой машины, проблема не устранена.Моя проблема здесь: почему?!

   Это просто копия и вставка из Git Extensions :

   git fetch --progress "client" 
   Done
   From \\\CLIENT\project\git
   ! [rejected]        master     -> client/master  (non-fast-forward)
   

   Я на самом деле это исправил с использованием git fetch -f "client", но я до сих пор не знаю, что произошло.

Отказ от ответственности: Теперь я уже собираюсь git-scm.com чтобы попытаться узнать подробно, как работает этот адский мерзавец.Может быть, мне даже не стоит пытаться "полностью синхронизировать все" ...

-

edit : Помимо очевидной проблемы "не тянуть раньше"Я нашел две причины, по которым это могло бы произойти, но ни одна из них не помогла исправить в моем случае: использование rebase для редактирования прошлых коммитов, которые уже были реплицированы в другом месте, или с одинаковыми ветвями под разными именами , чтодолжно произойти для master по крайней мере.Это позже имеет большой смысл, за исключением того, что оно работает несколько раз и после некоторых нажатий перестает работать.Плюс, на стороне извлечения, используя fetch -f, он не сломал никаких ветвей.Так что это было не так.

Answer 1

Вам нужно либо обновить клиента перед нажатием (например, git pull), либо использовать принудительное принудительное нажатие (git push --force), но в этом случае фиксации в случае могут быть потеряны на удаленной стороне и инициировать сообщения non-fast-forward на других клиентах.

Answer 2

Столько, сколько я прочитал ресурсы , как я и обещал, я все еще далек от 100% уверенности в отношении каждого аспекта git. Тем не менее, я наконец-то смог найти решение своих проблем здесь, и оно стабильно не менее 1 месяца.

Для 1-го выпуска (без ускоренной перемотки вперед) Я обнаружил 3 причины.

Я в основном буду копировать с форумов бонобо :

1. git commit --ammend

   Я использую это время от времени, и я почти уверен, что если вы нажмете на коммит, то измените его и попытаетесь повторить, он не будет принят. Единственный способ, который я нашел в этой проблеме, это перезаписать пуш с git push --mirror

2. извлечение старых коммитов

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

3. конфликты

   Как говорили многие , слияние . Если одна и та же ветка (обычно ведущая) находится в разных местах, потому что одна машина выдвинула ее на сервер, не объединяя сначала, тогда другая машина должна вытянуть, объединить , и тогда она сможет выдвигать просто отлично .

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

Для 2-го выпуска это была, скорее всего, одна из этих трех причин.