Проверьте и посмотрите, равны ли SHA от git ls-remote origin HEAD
(удаленный наконечник) и git rev-parse HEAD
(локальный наконечник)?
Обратите внимание, что при этом вы отбрасываете LOT гибкости Git - подумайте, действительно ли это , что вы хотите сделать. Часть силы git pull
в том, что даже если вы фиксируете вещи, которые расходятся с основной копией, при извлечении из основной копии ваши изменения могут быть объединены (и в большинстве случаев процесс полностью автоматический).
Если ваша цель - иметь линейную историю коммитов (которая имеет свои собственные компромиссы), я бы посоветовал взглянуть на команду rebase
вместо того, чтобы заставлять ваших разработчиков никогда не фиксировать за origin / master.
Редактировать
На самом деле, если вы делаете просто git pull
(вместо перебазировки), вы не сможете сравнивать головы, потому что pull будет выполнять коммиты слияния. Вместо этого вам нужно сравнить git ls-remote origin HEAD
с git merge-base origin/HEAD HEAD
.
Некоторые другие комментарии
Почему вы используете Git, а потом вообще не используете дополнительные ветки? Это все равно что покупать автомобиль, но никогда не использовать двигатель (а вместо этого просто толкать его везде). Ветви дешевые в Git, быстрые в настройке и практически без усилий объединяющиеся. Вы оказываете себе медвежью услугу, если не пользуетесь ими.
Почему вы заботитесь о том, чтобы все были в курсе, прежде чем вносить изменения? Это не CVS, разрешение конфликтов не страшно - Git автоматически разрешит 95% конфликтов для вас без необходимости что-либо делать, поэтому не важно, будете ли вы git pull
до или после внесения изменений. - вам просто нужно потянуть, прежде чем нажать, и все будет в порядке.
Относится к предыдущему пункту: поскольку толчки без ускоренной перемотки по умолчанию отклоняются, вам на самом деле не требуется ловушка. Просто скажите вашим разработчикам: «если ваш толчок отклонен как не-перемотка вперед, сделайте git pull
, затем попробуйте нажать еще раз», и все будет работать.