Я пытаюсь установить Git Server на RedHat 6.5,
следуя этим руководствам:1,2,3, и, честно говоря, чем больше я читаю, тем больше вещей становится непонятными.
Если я создам пользователя git, который будет владельцем основных репозиториев, а также будет отвечать за выполнение коммитов, как мне запретить разработчику отправлять плохой код (gitolite, есть что-то поновее?)? Какова самая
простая конфигурация для сервера git (я бы с удовольствием использовал gitlab, но мой босс этого не разрешит), при этом разработчику разрешается отправлять только после проверки кода и получения разрешения на отправку.
Примечание: Все разработчики имеют доступ к серверу по SSH, и я собрал их ключи SSH.PUB.
решение1
Чтобы ответить на ваш вопрос:
Если я создам пользователя git, который будет владельцем основных репозиториев, а также будет отвечать за выполнение коммитов, как мне помешать разработчику отправить плохой код?
Ответ не в том, чтобы создать пользователя git. Вы можете контролировать права доступа к удаленному репозиторию с помощью стандартных пользователей и групп UNIX. Поскольку git push работает через SSH, пока вы можете подключиться по SSH к серверу, на котором размещен репозиторий, и у вас есть доступ на чтение к репозиторию через вашу учетную запись на сервере, вы можете читать, клонировать и извлекать из репозиториев. Если у вас также есть права на запись в репозиторий, вы также можете push коммиты.
решение2
Одна из функций, включенных в git по умолчанию:
git push --force
В обычных случаях вам всегда следует отключать это в репозитории с помощью:
git config --system receive.denyNonFastForwards true
Проблема может возникнуть в сценарии рабочего процесса слияния, когда у вас может быть много запросов на извлечение, но всегда лучшим решением будет иметь хорошее слияние и разделенные задачи разработки, где разработчики действительно могут понять git и не делать так много коммитов (в основном потому, что они не понимают природу контроля версий), и если это нормально, у вас будет меньше конфликтов. Хорошее обучение и понимание всегда лучше всего. Также вы можете предотвратить это с помощью локального перемещения коммитов. Второй альтернативой может быть Github. В этом сценарии вы не позволяете более чем одному сопровождающему отправлять изменения в важные ветки в авторитетном репозитории