머신에서 여러 사용자와 Git 저장소를 공유하는 방법


216

여러 개발자가 끌어낼 수있는 준비 서버에 Git 리포지토리가 있습니다. 여러 사람이 해당 저장소로 가져 가기를 제외하고는 내가 git-init찾고있는 것에 매우 가까운 플래그가있는 것 같습니다 --shared. git-clone의의 --shared플래그는 완전히 다른 무언가를.

기존 리포지토리의 권한을 변경하는 가장 쉬운 방법은 무엇입니까?


"Windows 용 Github"을 사용하고 있고 두 개의 Github 계정 간 전환 : stackoverflow.com/questions/18565876/…
— Alisa

답변:


186

권한은 해충입니다.

기본적으로 모든 개발자가 git repo의 모든 것에 쓸 수 있는지 확인해야합니다.

개발자 그룹에게 쓰기 기능을 부여하는 탁월한 방법은 New-Wave 솔루션으로 건너 뛰십시오.

표준 솔루션

모든 개발자를 특별히 만든 그룹에 배치하면 원칙적으로 다음을 수행 할 수 있습니다.

chgrp -R <whatever group> gitrepo
chmod -R g+swX gitrepo

그런 다음 umask사용자를로 변경하여 002그룹 쓰기 가능 권한으로 새 파일을 작성하십시오.

이것의 문제는 군단입니다. 당신이 가정 배포판에라면 umask의 022(예 : 공통 것으로 users기본적으로 모든 사람을 포함 그룹)이 다른 곳에서 보안 문제를 열 수 있습니다. 그리고 조만간, 신중하게 조작 된 권한 체계가 망쳐 져서 root접근 할 수 있고 수정 될 때까지 (즉, 위의 명령을 다시 실행할 때까지) 리포지토리가 작동 하지 않게됩니다.

새로운 웨이브 솔루션

잘 이해되지는 않지만 좀 더 많은 OS / 도구 지원이 필요한 우수한 솔루션은 POSIX 확장 속성을 사용하는 것입니다. 나는 최근에이 지역에만 왔기 때문에 여기에 대한 지식은 그다지 뜨겁지 않습니다. 그러나 기본적으로 확장 ACL은 3 개의 기본 슬롯 (사용자 / 그룹 / 기타) 이상에 대한 권한을 설정하는 기능입니다.

다시 한 번, 그룹을 생성 한 후 다음을 실행하십시오.

setfacl -R -m g:<whatever group>:rwX gitrepo
find gitrepo -type d | xargs setfacl -R -m d:g:<whatever group>:rwX

이것은 그룹 구성원이 이미 존재하는 파일 (첫 번째 행)을 읽고 쓸 수 있도록 그룹에 대한 확장 ACL을 설정합니다. 그런 다음 모든 기존 디렉토리에 새 파일에 동일한 ACL을 적용해야한다고 지시하십시오 (두 번째 줄).

희망이 당신을 당신의 길에 데려다 줄 것입니다.


62
git init에는 그룹 작업을위한 core.sharedRepository 변수를 설정하는 --shared라는 매개 변수가 있습니다. 기존 리포지토리에서 변수를 설정할 수도 있습니다. git이 파일을 조작하기 전에 그것을 제곱 값으로 설정하기 때문에 umask를 수동으로 설정할 필요가 없습니다.
— ptman

6
POSIX 확장 속성의 경우 +1-뉴스
— RobM

5
내가했을 때 chmod -R g+swX, 그것은 Git을 매우 불행하게 만들었고 더 이상 자식 저장소가 아니라고 결정했다 ( "repo는 자식 저장소가 아닌 것으로 보인다"). 나는 모든 파일 을 chmod gs해야했다 . 디렉토리 에서 setgid 비트를 설정하려면 시도하십시오 find /path/to/repo -type d -print0 | xargs -0 chmod g+s. 여전히 chgrp -R thegroup /path/to/repo.
— rescdsk

10
chmod -R g+swX gitreposetguid 비트를 파일에 적용하면 보안 상 위험합니다. 대신 find . -type d -exec chmod g+s {} +디렉토리에만 적용 할 수 있습니다 .
— Ian Dunn

1
ACL (setfacl)에는 디렉토리 내에 생성 된 새 파일 및 하위 디렉토리가 그룹 ID를 상속하도록 강제하기 위해 setgid에 대한 설정이 없습니다. 따라서 chmod를 통해 setgid를 별도로 설정해야합니다. 그러나 Git의 --shared 옵션 ( git-scm.com/docs/git-init )을 사용하면 사용자의 umask를 설정하고 재정의 할 수 있습니다.
— Chase T.

121

저장소를 만들거나 기존 저장소를 복제하여 새 저장소를 복제 한 경우

$ git init --shared=group 

또는

$ git init --shared=0NNN

Git은 기본 umask가 제공하는 것 이상의 권한을 처리해야합니다. 마침내 이것은 내 버전의 Git (1.6.3)에서 사실입니다. 물론 이것은 사용자가 같은 그룹에 있다고 가정합니다.

그러나 다양한 수준의 읽기 / 쓰기로 여러 그룹의 사용자를 관리해야한다면 gitosis로 갈 것입니다. 또한 지사 수준의 권한을 제공하기 위해 가정되는 gitosis 포크 인 gitolite ( http://github.com/sitaramc/gitolite )에 대한 언급을 들었습니다 . 개인적으로 사용했다고 말할 수는 없습니다.


9
이것은 정답입니다.
— ELLIOTTCABLE

4
나는이 문제를 겪었으며 이것이 가장 좋은 대답입니다. 유일한 문제는 --shared인수가 16 진수가 아닌 8 진수를 사용 한다는 것 입니다. 나는 이것을 Git 1.7.8의 출처에서 확인했으며 두 번째 예는 git init --shared=0NNN.
— qpingu

3
무엇 NNN-permissions 마스크 또는 그룹 번호 또는 뭔가 다른?
— Craig McQueen

20
BTW, 위의 "그룹"은 키워드이며 그룹 이름의 자리 표시자가 아닙니다. chgrp 명령을 사용하여 그룹을 지정합니다. 새 git init --bare --shared=group myproj리포지토리의 경우 myproj는 리포지토리 이름이고, chgrp -R mygroup myprojmygroup은 그룹 이름입니다.
— labradort

2
기본 그룹이 원래 그룹과 다를 때 사용자가 커밋을 수행하면 문제가 발생할 수 있습니다. 이 문제를 해결하려면 각 사용자가 저장소에있는 모든 파일을 올바른 그룹으로 chgrp해야합니다. 커밋하고 푸시하기 전에 모든 사람이 올바른 그룹 아래에서 또는 올바른 그룹으로 새 파일을 만들거나 전환하게하는 방법을 알아 내지 않으면이 과정이 반복됩니다.
— ragerdl

55

이것은 언급되지 않았으므로 빨리 추가하고 싶습니다.

권한 문제로 인해 머리가 잘리지 않게하려면 git 공유 리포지토리의 구성 파일에서 다음을 설정하십시오.

[core]
    sharedRepository = true

이렇게하면 시스템의 "umask"설정이 존중됩니다.


6
git-config (1) ( kernel.org/pub/software/scm/git/docs/git-config.html ) core.sharedRepository에 따르면, git 존경을 갖기 위해 이것을 "umask"또는 "false"로 설정해야합니다 사용자의 umask
— David Schmitt

14
이 user35117의 답변이 맞습니다. "true"는 "group"과 동일하며 이는 명령으로 설정할 수 있습니다 git config core.sharedRepository true.
— ColinM

원격으로 푸시 될 때 파일의 소유권을 여전히 변경합니까?
— Duc Tran

2
사실 이후가 아닌 복제시이를 설정하려면 git init --sharedis에 해당 git clone --config core.sharedRepository=true합니다. --shared비슷한 명령에서 다른 의미 로 사용할 git의 이상한 .
— stevek_mcc

21

힘내 사용 설명서 하는 방법에 대해 설명 저장소를 공유하는 여러 가지 방법.

저장소를 공유하는 기능을 갖춘 완전한 방법은 다음과 같습니다.

우리는 6 명의 개발자로 구성된 팀을 위해 GitHub를 사용합니다.


1
나는 Gitosis를 좋아한다. 공개 키를 기반으로 액세스를 제어하는 ​​매우 효과적인 방법입니다.
— Mike Mazur

이러한 솔루션 중 어떤 것이 "여러 사람이 해당 저장소로 끌어 들이고 싶습니다"라는 문제를 어떻게 해결합니까?
— womble

gitosis를 살펴보십시오. 하나는 당신의 문제를 해결합니다.
— pilif 2016 년

3
저장소를 공유하면 사람들이 저장소를 가져올 수 있습니다. 복제하거나 원격 지점을 추가해야 할 수도 있습니다. 내가 링크 한 문서는 문제 해결 과정을 매우 명확하게 안내합니다. 개발자가 Git과 소스 코드를 공동 작업하는 데 도움이되는 모든 방법을 사용했습니다. 내 지식으로는 ServerFault는 손 잡기를위한 것이 아닙니다.
— jtimberman 2016 년

3
Gitosis 사용에 동의해야합니다. 여러 SSH 키로 인증 된 단일 계정을 사용하여 권한 문제를 해결합니다. 또한 git commit을 통해 자체적으로 관리됩니다.
— Jeremy Bouse

9

또한 git 저장소를 호스팅하는 gitolite 를 살펴보십시오 . Gitosis는 분명히 더 이상 개발되지 않고 있습니다.


4

공유 저장소에서 권한을 수정하여 푸시 할 때 권한 문제가 발생하지 않는 한 가지 방법은 업데이트 후 후크 스크립트를 작성하는 것입니다. 이것은 모든 자식 버전에서 작동합니다.

/myrepo.git에 공유 저장소가 있다고 가정하십시오. 해당 저장소의 모든 파일은 mysharedgroup에 속합니다 . 해당 저장소로 푸시하는 모든 사용자는 mysharedgroup 에도 속해야합니다 . 이제 다음 파일을 작성하십시오 ( mysharedgroup 을 환경 설정으로 변경 ).

/myrepo.git/hooks/post-update

#!/bin/sh
chmod -R g+w . 2>/dev/null
chgrp -R mysharedgroup . 2>/dev/null

사용자가 기본 그룹이 다른 경우에 대한 정답
— Pat

디렉토리에 setgid 비트를 설정하면 사용자가 만든 파일이 디렉토리와 동일한 그룹 소유권을 상속받습니다 (사용자가 해당 그룹에 속하는 경우). 사용자의 기본 그룹이 아닌 경우에도 마찬가지입니다. 그런 다음이 후크는 필요하지 않습니다. 이것이 @womble의 답변 (및 그것에 대한 나의 의견) 이하는 일입니다.
— rescdsk

내 centos7 컴퓨터 에서이 페이지에 나열된 모든 솔루션을 시도한 후에 위의 @bkmks 솔루션 변형이 실제로 작동하는 유일한 옵션이었습니다 (위와 같이 업데이트 후 대신 병합 후 및 체크 아웃 후크 설정).
— Mike Godin 2016 년

STDER의 오류 메시지 또는 경고를 파이프하는 솔루션을 홍보하는 것은 좋지 않은 조언이라고 생각합니다 /dev/null. 사용자에게이 메시지를 먼저보고 스스로 결정하도록하십시오.
— Daniel Böhmer

3

새로운 리포지토리 설정에 대한 다양한 다른 답변과 의견에서 좋은 조언과 비트를 집계하려면 다음을 수행하십시오.

그룹 myrepo에 /srv/git대해 새로운 리포지토리 를 설정하는 경우 mygroup원하는 것입니다.

mkdir /srv/git/myrepo.git
chgrp mygroup /srv/git/myrepo.git
git init --bare --shared /srv/git/myrepo.git
  1. 첫 번째 줄은 repo dir을 만듭니다.
  2. 두 번째 줄은 그룹을 mygroup
  3. 세 번째 줄은 다음 구성으로 Bare Repo를 초기화합니다.
    1. core.bare = true: 맨손으로 레포로 만들기
    2. core.sharedrepository = 1(동일하게 core.sharedrepository = group되찾기 디렉토리와 나중에에서 생성 된 모든 디렉토리가 허용하는 자식에 의해 관리됩니다) mygroup, 읽기, 쓰기뿐만 아니라 설정 SGID 비트를 (실행 권한을 - 누구가 사용자와 함께 작동하도록, mygroup하지 그들의 기본 그룹)
    3. receive.denyNonFastforwards = 1: repo에 대한 비 빨리 감기 푸시 거부

당신이 미세 조정하려면 사용자, 그룹 또는 다른 사용자의 권한, 사용 --shared=0NNN, NNN표준 사용자, 그룹 및 다른 비트있는 파일을 합니다 (실행과에 SGID 비트 디렉토리가 자식에 의해 적절하게 관리됩니다). 예를 들어, 사용자에 대한 읽기 및 쓰기 액세스 권한과 그룹에 대한 읽기 전용 액세스 권한이 있으며 다른 사용자에게는 액세스 권한이 없습니다.

git init --bare --shared=0640 /srv/git/myrepo.git

이를 통해 사용자 및 그룹에 대한 읽기 및 쓰기 액세스가 가능하며 다른 사용자에게는 액세스 할 수 없습니다.

git init --bare --shared=0660 /srv/git/myrepo.git

이를 통해 사용자 및 그룹에 대한 읽기 및 쓰기 액세스 권한과 다른 사용자에 대한 읽기 전용 액세스 권한이 부여됩니다.

git init --bare --shared=0664 /srv/git/myrepo.git

그룹에 대한 쓰기 액세스를 허용하지 않으려면 먼저 chownrepo의 소유자를 설정 한 다음 git init해당 사용자로 명령 을 실행 하십시오 (리포가 올바른 소유자로 초기화되었는지 확인하십시오). 모든 초기 파일 및 하위 디렉토리).


높은 투표 응답보다 더 정확합니다.
— XO01


1

이 작업을 기존 저장소에서 정확하게 수행했습니다. 이것은 전에 몇 가지 답변과 의견에서 조언을 얻습니다.

서버의 저장소 상위 디렉토리에서 다음을 수행하십시오.

chgrp -R <whatever group> gitrepo
chmod -R g+wX gitrepo
cd gitrepo
find . -type d -exec chmod g+s {} +
git config core.sharedRepository group

0

@ stevek_mcc 답변은이 질문에 대해봤을 때 찾고있는 답변입니다.

git clone --config core.sharedRepository=true
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.