Есть ли предпочтительная практика ограничения передачи кода репозиториями Git?
Я изучаю методы защиты репозиториев Git от случайных подталкиваний кода от разработчика в командной среде. В настоящее время у меня больше вопросов, чем ответов от исследований. Я использовал проверки элементов управления политикой TFS и VSTS, но я не вижу этого в Git или его нелегко найти.
Есть ли у кого-нибудь хороший опыт, которым они готовы поделиться?
Также обратите внимание на использование файла с именем ".gitignore", чтобы случайно не вернуть файлы, которые вы хотите пропустить, например, большие двоичные, временные или другие файлы. См .: github.com/github/gitignore
Ответы 1
Традиционно в Git это достигается за счет управления разрешениями на уровне репозитория. Разработчики без разрешения на отправку могут делать запросы на вытягивание или отправлять исправления.
Однако есть способ получить более детальный контроль доступа. В Git это достигается с помощью хука pre-receive. Этот скрипт выполняется на вашем сервере Git всякий раз, когда кто-то нажимает на него, если скрипт завершается с ненулевым статусом, push будет отклонен. Вы можете использовать это для обеспечения любого типа контроля доступа, который вы хотите. Однако написать ловушку pre-receive для обеспечения контроля доступа нетривиально, поэтому для управления доступом чаще используется какое-то программное обеспечение вместе с Git, например GitHub, GitLab, Gerrit или Gitolite.
GitHub позволяет ограничить пользователей, которые могут отправлять сообщения в определенные ветки. См .: https://help.github.com/articles/enables-branch-restrictions/
GitLab позволяет аналогичным образом защищать ветки. См .: https://docs.gitlab.com/ee/user/project/protected_branches.html
Gitolite позволяет настраивать разрешения. См .: http://gitolite.com/gitolite/conf/
Gerrit позволяет вам принудительно проходить проверку кода перед объединением коммитов. См .: https://www.gerritcodereview.com/
Создайте «главный» репозиторий для своего кода. Затем создайте отдельный репозиторий из «главного» для разработчиков, которых вы хотите ограничить. Затем заставьте их выполнять запросы на включение, чтобы код был объединен с «мастером». Если они сделали что-то не так, откажитесь от пиара. Сам Git не управляет пользователями.