Я не знаю, собираетесь ли вы удалить этот вопрос (как это предлагается в комментариях выше), но пока я остановлюсь на одном :
git push не может создать слияние.
При использовании git push, у вас есть мерзавец вызвать некоторый другой мерзавец (например, через SSH), после чего два Git репозиториев имеют небольшой разговор, чтобы обсудить, какие объекты вашего есть, что их нет, и какие объекты вы хотели бы им установить некоторые из своих ссылок на point-to.
Например, в вашем случае вы (или, точнее, ваш программист в своей команде) можете вызвать экземпляр git сервера и сказать «пожалуйста, измените ветку branch, чтобы указать на фиксацию 1234567...». Для того, чтобы сервер мог это сделать, сервер должен иметь совершить 1234567..., чтобы ваш git мог упаковать этот объект с любыми другими необходимыми объектами и сначала отправить их поверх.
Серверный мерзавец не делать какие-либо слияния в ходе этого процесса, он просто принимает все, что объекты нужны, а затем принимает запросы, как «установить refs/heads/branch в 1234567...». Эти запросы выполняются с помощью проверки разрешений (pre-receive и update), которые обычно выполняют такие вещи, как отказ от обновлений без пересылки или при использовании более удобных систем, таких как гитолит, проверьте, имеет ли удаленный пользователь разрешение на создание, удаление или обновление определенную ветвь. Если разрешения разрешений позволяют это, процесс git на стороне сервера просто устанавливает запрашиваемые ссылки (обычно имена ветвей, иногда теги, есть также ссылки на заметки и т. Д.).
Каждое из этих объединений происходит от стороны пользователя (не сервера) до этапа git push. Как отмечалось в комментариях выше , это связано с тем, что пользователь неоднократно исправлял существующий, но нажатый фиксатор, который копирует фиксацию на новый идентификатор. Нажатие этого нового идентификатора не будет быстрой перемоткой вперед и по умолчанию будет отказано; чтобы это произошло, пользователь предположительно выполняет дополнительные слияния.
Ну, не сам по себе, так или иначе.Используя упомянутые выше крючки, можно настроить сервер таким образом, чтобы при получении push он сохраняет любые новые фиксации, отклоняет сам push и затем запускает дополнительные отдельные команды git для создания слияний с использованием сохраненных, но -rejected commit (s). Это довольно искривленный режим работы, а не то, что люди обычно или вообще должны делать. (Кроме того, это не толкание, создающее слияние здесь, это толкание, запускающее какой-то другой скрипт, а другой скрипт, создающий слияние.)
И что произойдет, если другие программисты что-нибудь совершают? (Является ли проблема связана с «программистом» или «репозиторием»?) – Amit
Извините, забыли добавить - когда я добавляю фиксацию, все идет отлично. Это только этот пользователь в этом конкретном репозитории - я не хочу, чтобы он работал над другим только потому, что он может быть связан с его конфигурацией, и это может серьезно испортить целостность истории. –
Итак, почему вы «на грани создания нового репо»? Просто переконфигурируйте/переустановите среду этого программиста. – Amit