참고 : 각 사용자가 서버에 자신의 사용자로 로그인 할 때 (즉, 저장소에 액세스하기 위해 단일 계정에 여러 사용자가 로그인하지 않은 경우) SSH 기반 액세스 메커니즘을 사용한다고 가정합니다. 이 가정이 사실이 아닐 경우, 다음 답은 완전히 유용하지 않을 수도 있습니다.
개인 저장소의 core.sharedrepository 설정하고 당신이 그것을 액세스하는 데 사용하는 umask를 원격 저장소에 사용되는 소유권 및 권한과 관련이없는.
원격 저장소의 core.sharedrepository에서 0660으로 설정하면 원하는 것을 얻을 수있는 올바른 방법입니다. 리모트 쪽에서 접근하는 사용자의 umask도 의 값인 0xxx을 볼 때 Git이 마스크를 덮어 쓰기 때문에 관련이 없습니다. 모든 파일과 디렉토리가 공통 그룹에 의해 소유되고 모든 디렉토리에 대해 2770 (또는 BSD-ish 시스템의 경우에만 770), objects/?? 및 /objects/pack/ 아래의 파일에 대해서는 440, 권한이 올바른지 확인해야합니다. 다른 파일의 경우 660).
새 파일을 만든 사용자가 새 파일을 소유하는 것은 정상적인 현상입니다. 비 BSD 시스템에서는 디렉토리에 setgid 비트 (2000 비트)가 있어야 새 항목이 상위 디렉토리의 그룹 소유자를 상속받습니다. 사용자 소유자는 거의 계승되지 않습니다 (FreeBSD는 setuid 비트를 사용하여 구성 할 수 있지만 정상 구성에서는 사용되지 않습니다). 따라서 모든 파일과 디렉토리는 동일하고 공통된 그룹 소유자를 가져야하지만 저장소 (예 : push)에 대한 각 쓰기는 쓰기 사용자가 사용자 소유 인 일부 파일 및/또는 디렉토리를 남겨 둡니다. 어느 한 사용자 (귀하의 rUser?)가 모든 파일과 디렉토리의 사용자 소유주 일 필요는 없으며, 저장소에 액세스해야하는 모든 사용자는 공통 그룹의 구성원이어야합니다.
1 각 사용자가 분명히/자신이 만든 디렉토리를 모든 파일을 사용자가-소유하지만, 힘내 "원자 재 작성"을 사용하기 때문에 그들은 또한 사용자가 자신의 대부분의 파일들은 수정 것이다 (이것은에 새로운 내용을 기록 동일한 디렉토리에있는 새 파일을 분리 한 다음 원래 파일의 이름을 바꿉니다.
힘들게 새 파일에 대한 umask를 재정의하는 방법에 버그가있을 수 있습니다. 정확히 어떤 파일이 너무 넓은 권한을 얻고 있습니까? Git의 어떤 버전을 원격지에서 저장소에 액세스 할 수 있습니까? 원격지에서 어떤 OS를 실행하고 있습니까?
내 Unixy 컴퓨터에서 두 명의 사용자와 공통 그룹으로 Git 1.7.4.1에서이 문제를 재현 할 수 없습니다.
시나리오를 약간 단순화 해보십시오. 서버 자체에서 직접 원격 저장소로 푸시 (즉, 로컬 복제본을 만들고 버려진 분기로 푸시)하십시오. 로컬 전용 액세스를 사용하면 중간에 어떤 종류의 전송이있을 때보 다 가정 (umask, uids, gids, 사용자 및 그룹 소유권, 파일 및 디렉토리 사용 권한)을 쉽게 확인할 수 있습니다 (Git 자체의 SSH 기반 전송 또는 완전한 충실도로 ID와 권한을 매핑하지 않는 네트워크 파일 시스템).
어떻게 원격 저장소에 액세스하고 있습니까? SSH 기반의 방법 ('host : path' 또는'ssh : // host/path' 저장소 URL)을 사용하는 것 같습니다. 네트워크 파일 시스템을 대신 사용한다면 복잡 할 수도 있습니다. –
ssh를 사용하여 액세스하고 있는데 원격 파일 시스템은 실제로 NFS 파일 시스템입니다 (왜 파일 시스템이 여기에 영향을 주는지 확실하지 않습니다). – user10