gitosis 대 gitolite? [닫은]

팀과 프로젝트를 공유하기 위해 git 서버를 설치하려고합니다. git 액세스가 필요한 각 개발자를 위해 SSH 액세스 권한을 가진 서버에서 사용자 계정을 만들고 싶지 않습니다. 이 문제를 다루는 두 가지 동시 솔루션이 있습니다 : gitosis & gitolite.

두 솔루션 사이의 비교를 찾을 수 없습니다. 그들 사이의 주요 차이점은 무엇입니까? 다른 비슷한 해결책이 있습니까?

팀과 프로젝트를 공유하기 위해 git 서버를 설치하려고합니다.

당신은 할 수 있습니다 만 자식을 사용합니다.

git 서버를 가지려면 원격 서버에서 필요한 유일한 것은 git입니다. 세분화 된 권한이 필요하지 않은 경우 (팀과 공유하면 가능할 가능성이 있음) 또는 추가 기능이 필요하지 않은 경우, gitolite 등이 필요하지 않습니다.

무 설치 솔루션

원격 서버에서 git을 사용할 수 있다면 아무것도하지 않고 지금 요청하는 것을 할 수 있습니다

ssh [user@]server
cd repos/are/here/
mkdir project.git
cd project.git
git init --bare

토지 상에서:

cd projects/are/here/project
git remote add origin [user@]server:repos/are/here/project.git
git push -u origin master

자식 서버를 설정하는 것은 쉽다.

전용 git 사용자와 작업을 수행하려는 경우 git 서버 설정에 대한 문서 가 짧습니다. 실제로 수행하기가 쉽기 때문입니다.

요약해서 말하자면:

• 자식 설치
• git이라는 사용자를 만듭니다
• 당신과 당신의 팀의 공개 키를 자식 사용자 .ssh/authorized_keys파일에 추가하십시오.
• 자식 사용자의 쉘을 다음과 같이 변경하십시오. git-shell
• 서버에서 리포지토리 생성
• git pull을 시작 /git@yourserver.com으로 푸시

단지 전용 자식 사용자를 사용하지 차이, 당신 설치 망할 놈의 사용자가 사용하는 경우이다 git-shell그 자체가 다른 작업을 수행 할 수 없습니다. 그러나 git 서버 역할을한다는 점에서 설치하지 않는 솔루션과 동일합니다.

주된 차이점은 현재 gitosis가 더 이상 사용되지 않으며 더 이상 적극적으로 유지되지 않는다는 것입니다.

Gitolite는 훨씬 더 완벽한 기능을 제공 하며 세 번째 버전을 출시했습니다 .

가장 흥미로운 기능은 VREF (Virtual Reference) 로, 원하는 만큼 많은 업데이트 후크 를 선언 할 수 있으므로 다음을 통해 푸시를 제한 할 수 있습니다.

• dir / file name :
  주니어 개발자가 Makefile을 변경하는 것을 원하지 않는다고 가정하십시오.
  - VREF/NAME/Makefile = @junior-devs

• 새 파일의 개수 :
  당신이 그 (것)들을 만들고 싶어하기 때문에 말 당신은 커밋 당 9 개 이상의 파일을 밀어 주니어 개발자를 원하지 않는 작은 커밋 :
  - VREF/COUNT/9/NEWFILES = @junior-devs

• 고급 파일 유형 감지 :
  파일에 표준 확장자 ( 'gitignore'd는 안됨)가 있지만 실제로 자동으로 생성됩니다. 여기를 잡기 위해 하나 개의 방법 :
  - VREF/FILETYPE/AUTOGENERATED = @all
  참조가 src/VREF/FILETETYPE검출 메커니즘을 볼 수 있습니다.

• 저자 이메일 확인 :
  일부 사람들은 "자신의 커밋 만 푸시"할 수 있기를 원합니다.
  - VREF/EMAIL-CHECK = @all
  참조하십시오 src/VREF/EMAIL-CHECK.

• 커밋
  에 대한 투표 : 커밋에 대한 기본 투표 구현은 놀라 울 정도로 쉽습니다
  - VREF/EMAIL-CHECK = @all. 구현을
  # 2 votes required to push master, but trusted devs don't have this restriction
# RW+ VREF/VOTES/2/master = @trusted-devs
# - VREF/VOTES/2/master = @devs
  참조하십시오 src/VREF/VOTES.

• 등등...

단지 참고 사항입니다. Gerrit 을 필요에 따라 사용할 수도 있습니다 .

Gerrit 코드 검토

먼저 Gerrit가 코드 검토에 사용되는 것 같지만 실제로는 사용자 관리에도 사용하여 적절한 권한을 부여 할 수 있습니다. 당신은 할 수있는 패스 코드 리뷰 (저점 액세스 제어 ) 및 단지 프로젝트와 SSH-키를 관리하기 위해 그것을 사용할 수 있습니다. Gerrit는 매우 강력한 액세스 제어 메커니즘을 가지고 있습니다.

Gerrit 액세스 제어

액세스 제어 문서에 정의되어있는 브랜치, 태그 또는 상상할 수있는 모든 것을 푸시하도록 제한 할 수 있습니다.

더 빠르고 더 더러운 솔루션을 얻으려면 git 데몬을 사용 하고 피어 투 피어로 이동하십시오. 다음 은 그 작업에 대한 기사 입니다.

편집 : 이것이 OP의 질문에 엄격하게 대답하지는 않는다는 것을 알고 있습니다. 나는 엔터프라이즈 github 계정이 설정 될 때까지 코드를 공유 할 수있는 길고 더러운 방법을 찾고있는 동안 저와 같은 사람들을 위해 주로 여기에 넣었습니다.

LDAP 액세스, 세분화 된 액세스 제어 등으로 작업하는 git 서버를 얻기 위해 잠시 엉망이되었습니다. 계시를 찾았습니다 : Gitlab 사용 :

• 자식 저장소
• 세밀한 접근 (afaik gitlab은 후드 아래에서 gitolite를 사용합니다)

빠르고 빠른 설치 방법을 원할 경우 : bitnami 설치 프로그램을 사용하십시오