2012-09-21 8 views
2

예, hehe를 알고 있습니다. 분산 버전 제어 시스템에는 중앙 저장소가 없으므로 중앙 집중식 VCS가 아니기 때문에 모든 저장소의 버전을 얻을 수 있습니다. 그러나 사무실에서 실생활에서 종종 상사는 모든 것의 주인이되기를 원합니다. 그래서 누군가 내 경우에 좋은 접근법을 가지고 있는지 여기에 왔습니다.GIT의 사용자/저장소 계층 구조

내 사무실에서

우리는 GIT를 사용하기 시작했고, 우리는 다음과 같이 있습니다

<SERVER> 
---->../apache/htdcos/All_Proyects [Bare repository] 
-------->/Proyect_A [Repository]~~~ Developer 1 [Git Repo], Developer 2 [Git Repo] 
-------->/Proyect_B [Repository]~~~ Developer 3 [Git Repo], Developer 4 [Git Repo] 
-------->/Proyect_123 [Repository]~~~ Developer 5 [Git Repo], Developer 6 [Git Repo] 

이 모든 프로젝트는 그 자체가 GIT 저장소의와 All_Projects 그것이 베어 저장소를 가질 수 폴더에 있는지의 아이디어를 "main one"을 선택하면 모든 프로젝트가이 프로젝트를 수행 할 수있게되고 맨처 리지는 마스터 저장소와 같은 마스터가 될 것입니다. (처음에 좋은 접근입니까?)

이 접근 방식을 사용하면 몇 가지 의문점이 있습니다 ...

나는 사용자/저장소의 계층 구조를 가질 수 있습니까 ?? 예를 들어, Developer 5는 Proyect_A를 푸시/풀/커밋 할 수 없지만 자신의 Proyect_123으로 할 수 있습니까 ??

다음과 같은 계층 구조 시스템을 사용할 수 있습니까? : 개발자가 Boss 리포지토리에 푸시하고 Boss가 프로젝트 리포지토리에 서버를 자동으로 푸시합니다 (cron 어쩌면) 모든 프로젝트 리포지토리에서 마스터 리포지토리의 맨 마스터로 연결됩니다. (개발자가 맨손 저장소에 직접 연결할 수없는 경우).

어떻게하면됩니까? 감사합니다.

답변

1

부모 저장소에서 참조하는 Repos는 정확히 submodules입니다.

및 보호 사용자가 프로젝트이 가능하여, 당신은 (installation page 참조) 주 망할 놈의 repos 서버 Gitolite에 추가 한 제공.
Git 명령을 가로 챌 수있는 Perl 스크립트의 작은 모음이며 어떤 사용자가 어떤 repo에서 어떤 작업을 수행 할 수 있는지 지정하는 구성 파일에 대해 해당 명령의 유효성을 검사합니다.

+0

내 사장님이 내 이마에 별을 넣어 주셔서 고마워. 자습서를 좀 보도록하겠습니다. 아주 유용하게 보입니다. – Metafaniel