Ну, вроде как. Но я не думаю, что вы хотите туда пойти.
Как сказал Джейсон, есть крючки, которые вы можете использовать для предотвращения определенного поведения. В этом случае мы могли бы использовать ловушку pre commit, чтобы никто не запустил «git commit». Но это проблематично по нескольким причинам:
- По разным причинам безопасности git-хуки не распространяются вместе с репозиторием, поэтому вы не можете заставить людей использовать ваши хуки в своих репозиториях. Помните, что их хранилища принадлежат им самим, а не вам решать, что они делают в своих хранилищах.
- Что происходит, когда вы выполняете вытягивание или слияние и получаете конфликты? Чтобы разрешить эти конфликты, вы должны иметь возможность использовать «git commit», который мы только что отключили.
Это просто создает больше проблем, чем решает.
Однако вы можете решить эту проблему другими способами. Вы можете создать рабочий процесс, который обеспечивает соблюдение этих принципов. Например, представьте, что у вас есть человек, отвечающий за слияние из тестовой ветви в ветку релиза. Если вы позволите только этому человеку быть в состоянии отправить изменения в центральный репозиторий (или этот репозиторий сотрудников является «центральным» репозиторием), он / она может получить изменения из тестовой ветви тестового репозитория или тестовой ветви тестер Б (используйте свое воображение).
Здесь важно осознать, что вы можете применять политику, разрабатывая способы обмена изменениями друг с другом. Не каждый должен иметь возможность отправить свои изменения в один репозиторий. Черт, им даже не нужно продвигать свои изменения вообще. Люди, участвующие в тесте, могут получать изменения от разработчиков, как только они захотят что-то протестировать, и таким образом вы можете позволить тесту решать, когда они будут готовы внести новые изменения, а не позволять разработчикам решать, когда тестировщики должны получить свои тесты. вещи. Тот же принцип.