Когда вы говорите «master (по соглашению) репо», я предполагаю, что вы имеете в виду (1) есть единственное хранилище «источника правды» для проекта (которое обычно называется origin, а не master ); (2) пользователи / разработчики клонируют origin, работают в своих клонах и вносят изменения в origin.
При таком использовании взаимодействия с origin сводятся к очень немногим - и фактически записи в origin всегда должны быть push es. Такие вещи, как rebase не на самом деле происходят в origin; он просто обновляется, чтобы увидеть результат этих операций.
Если вам нужен какой-либо уровень безопасности или аудита в центральном репо, то это правильный способ его настройки. Но, это означает, что многие вещи, о которых вы говорите, вы не можете "увидеть" напрямую. Вы не будете знать (и, честно говоря, это не должно волновать), какие команды использовались для перевода локального репо пользователя в определенное состояние. Вы просто знаете, что толкается - и любые централизованно-принудительные правила должны быть описаны в терминах того, что толкается.
Это означает, что полезными инструментами являются опции конфигурации для origin и хук pre-receive (и, возможно, хук update) для origin (если только вы не находитесь в размещенной среде, предоставляющей другую модель безопасности). ).
Одна вещь, которую вы можете сделать, это глобально отказаться от переписывания истории. Тогда, если кто-то перебрасывает ветку после того, как она была сдвинута, origin просто не пойдет на нее (Пользователь все еще может работать над веткой, а затем перебазировать ее до того, как в первый раз поделится ею. С этим ничего не поделаешь, и на самом деле нет веской причины для этого.) На origin, который вы установите receive.denyNonFastForwards до true.
Вы можете применить практически любое правило с помощью хука; если вы можете разработать необходимый скрипт. Может быть, вы хотите применить правила топологии фиксации (например, «без слияний в master» в стиле gitflow) или требовать подписанных коммитов (см. Ниже), или чего-то еще.
Если правила относятся к конкретному пользователю или если вы хотите регистрировать потенциальные нарушения вместо (или в дополнение к) их блокировки, то аутентификация является проблемой. Защита доступа к репо - и аутентификация того, кто обращается к репо - это не то, к чему git действительно относится. Существует несколько серверных сред для размещения репозиториев git - таких как github, gitlab, TFS. Эти типы серверов обеспечивают параметры безопасности. Вы также можете настроить свое хранилище так, чтобы единственный способ достичь его - использовать аутентифицированные средства (должным образом аутентифицированные http или ssl).
Принятие коммитов, только если они подписаны (или только если они достижимы из подписанного тега), также является опцией, которая сообщает что-то о том, кто что сделал, но, возможно, не то, что вы хотите знать. (То, что я написал и подписал коммит, ничего не значит о том, кто переместил ссылку на указатель на этот коммит и попытался выдвинуть результат.)
Если вы можете выработать аутентификацию, но не можете записать в сценарий обнаружение каждого правила - или, возможно, не уверены, какими должны быть правила, но узнаете «плохое поведение», когда увидите его, - тогда просто регистрируйте Аутентифицированная личность со списком ссылок push-сообщения расскажет вам, вероятно, все, что вам нужно знать, чтобы разобраться «после факта».