Git: как лучше настроить пользовательскую модель на «внутреннем сервере»

Question

У меня очень специфический вопрос по модели пользователя. (Я предполагаю, что задание этого вопроса предаст мое невежество, но эй, я просто хочу знать!)

У меня есть простой сервер Ubuntu, в котором будет хранилище нашего проекта, из которого около 6 человек будут клонировать проект. У каждого есть своя учетная запись на этом хосте. Репозиторий проекта находится по пути / home / git / project-name.git . Я мог бы создать группу для записи этих пользователей и пользователя git.

Когда пользователи-разработчики нажимают на этот удаленный репозиторий, я не хочу, чтобы они делали все от одного и того же пользователя (скажем, пользователь 'git' или что-то в этом роде), поскольку я хочу знать, кто что сделал.

Если я сделаю так, чтобы все добавили ключ id_rsa.pub.name на путь / home / git / .ssh / , то добавьте себя в * / home / git / .ssh / authorized_keys *, я Я не собираюсь выяснять, кто что сделал, верно?

Следовательно, предоставляю ли я полный доступ к / home / git / project-name.git каждой группе, к которой относятся учетные записи разработчиков на этом хосте?

Любой совет будет тепло приветствоваться.

Спасибо, Russ

Answer 1

Вместо Gitosis я бы порекомендовал Gitolite для детальной авторизации в сочетании с аутентификацией на основе ssh.

Answer 2

Я рекомендую использовать что-то вроде Gitolite ( download ) для того, что вы хотите, чтобы вы могли выбирать, кто имеет доступ к чему.Вы настроили пользователя "git", которого все используют для толчков Git.Гит сам отслеживает, кто что совершил, так что не стоит терять это.

Answer 3

Общая практика заключается в том, чтобы иметь одну учетную запись, а не несколько учетных записей ssh ​​для всех, кто хочет продвинуться в репо.

http://progit.org/book/ch4-4.html

http://blog.felipebalbi.com/2008/01/03/git-push-and-ssh-keys/

Это не лишает вас возможности знать, кто что совершил.Автор / коммиттер не зависит от пользователя ssh.

Answer 4

Разрешение нескольким пользователям писать в хранилище не означает, что вы сможете определить, «кто что сделал».

Это правда, что первый (серверный) пользователь создал конкретный объект(blob, tree, commit, annotated tag) будет владельцем свободного объектного файла объекта (хотя любой другой пользователь с правами записи может, вероятно, удалить и перезаписать файл), но в конечном итоге эти свободные объектные файлы будут эфемерными.Отдельные свободные объекты будут в конечном итоге упакованы и удалены (например, с помощью git gc, либо вручную, либо автоматически, как только накопится достаточно свободных объектов).

Git не выполняет ни аутентификации, ни авторизации, поэтому не имеет представления о«Пользователь», который делает толчок ¹ .Поскольку он не имеет понятия активного пользователя, он не может предоставить журнал «кто что нажал / изменил / удалил что».Если вам нужен такой журнал аудита , вам придется полагаться на любой инструмент, который фактически выполняет аутентификацию.К сожалению, многие инструменты хостинга Git ориентированы на распределенную природу Git, поэтому они, как правило, не предлагают большой поддержки «централизованных» функций, таких как журнал аудита.Однако есть некоторые исключения:

• Gitolite ведет журнал, который может быть использован в качестве журнала аудита (аутентификация выполняется сервером SSH или сервером HTTP, ноGitolite выполняет авторизацию).
• Gerrit , кажется, имеет некоторые встроенные ограничения, которые пытаются более тесно связать информацию пользователя коммиттера (и автора, в зависимости от конфигурации) с аутентифицированными учетными записями пользователей.(см. Идентификация кузницы );хотя это не журнал аудита, этого может быть достаточно, если вы последовательно ограничиваете полномочия «подделки».

(Возможно, есть другие инструменты или службы, которые также имеют некоторые функции ведения журнала / ограничения).

См. Также: Журнал журнала Git

¹ Git отслеживает автора и коммиттера для каждого коммита (тегера для каждого аннотированного тега),но их значения не ограничены Git.Любой может изменить действующего автора или коммиттера, изменив (или переопределив) свои переменные конфигурации user.email и user.name или установив переменные среды GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_COMMITTER_NAME и GIT_COMMITTER_EMAIL при создании коммита или тега.