git precommit hook, чтобы убедиться, что HEAD обновлен по сравнению с мастер-репо - PullRequest
2 голосов
/ 22 октября 2010

Я перевожу мою команду из старого CVS-хранилища на использование git.Я надеялся добавить в ловушку precommit, чтобы убедиться, что перед выполнением коммита локально (и отправлено) у каждого человека есть актуальное репо.

Например, в CVS каждый будет делать cvs up передвносить изменения, а затем совершать.Я хочу заставить это сделать так, чтобы люди не могли вносить изменения, если они сначала не сделали git pull origin master (мы не будем использовать дополнительные ветви)

Есть ли простой способ сделать это?ура за любую помощь:)

Ответы [ 3 ]

5 голосов
/ 22 октября 2010

Проверьте и посмотрите, равны ли 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, затем попробуйте нажать еще раз», и все будет работать.

2 голосов
/ 22 октября 2010

Если вы отслеживаете удаленную ветвь:

git fetch
git log HEAD..origin
# or:
git diff ...origin

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

Не забывайте, что git push будет по умолчанию отклонено, если это не быстрое изменение .
Так что git pull будетспособ избежать этого сообщения в любом случае.

2 голосов
/ 22 октября 2010

Это разрушает «распределенную» природу git.Это делает каждый коммит несколько глобальным.Cvs "commit" аналогичен git "push", который взаимодействует с удаленным концом.

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

...