여러 프로젝트가있는 서버용 GIT 저장소 레이아웃

96

내가 Subversion을 설정하는 방식에 대해 내가 좋아하는 것 중 하나는 여러 프로젝트가있는 단일 주 저장소를 가질 수 있다는 것입니다. 프로젝트 작업을하고 싶을 때 해당 프로젝트 만 확인할 수 있습니다. 이렇게

\main
    \ProductA
    \ProductB
    \Shared

그때

svn checkout http://.../main/ProductA

git의 새로운 사용자로서 특정 워크 플로를 적용하기 전에 현장에서 약간의 모범 사례를 살펴보고 싶습니다. 지금까지 읽은 내용에서 git은 모든 것을 프로젝트 트리의 루트에있는 단일 .git 폴더에 저장합니다. 그래서 두 가지 중 하나를 할 수 있습니다.

  1. 각 제품에 대해 별도의 프로젝트를 설정하십시오.
  2. 하나의 대규모 프로젝트를 설정하고 제품을 하위 폴더에 저장합니다.

제품간에 종속성이 있으므로 단일 대규모 프로젝트가 적절 해 보입니다. 모든 개발자가 코드를 공유 할 수있는 서버를 사용할 것입니다. 나는 이미 SSH 및 HTTP를 통해 작동하고 있으며 그 부분을 좋아합니다. 그러나 SVN의 리포지토리 크기는 이미 많은 GB이므로 각 시스템의 전체 리포지토리를 드래그하는 것은 좋지 않은 생각처럼 보입니다. 특히 과도한 네트워크 대역폭에 대한 비용이 청구되기 때문입니다.

Linux 커널 프로젝트 리포지토리가 똑같이 크기 때문에 Git을 사용하여이를 처리하는 적절한 방법이 있어야한다고 생각하지만 아직 파악하지 못했습니다.

대규모 다중 프로젝트 저장소 작업에 대한 지침이나 모범 사례가 있습니까?

git 
— 폴 알렉산더
소스

답변:

65

Git 제한 과 관련하여 지침은 간단 합니다 .

  • 프로젝트 당 하나의 저장소
  • 서브 모듈이 있는 메인 프로젝트 .

아이디어는 하나의 거대한 git 저장소에 모든 것을 저장하는 것이 아니라 작은 저장소를 기본 프로젝트로 빌드하는 것입니다.이 저장소는 각각 프로젝트 또는 자체의 공통 구성 요소를 나타내는 다른 저장소의 올바른 커밋을 참조합니다.

OP 폴 알렉산더의 의견 :

이것은 Subversion에서 제공하는 "외부"지원과 비슷하게 들립니다.
우리는 이것을 시도했고 프로젝트가 서로에 대한 종속성과 동시에 개발되기 때문에 외부에서 버전 참조를 지속적으로 업데이트하는 것이 매우 번거 롭다는 것을 알았습니다. 다른 옵션이 있습니까 ??

@Paul : 예, 기본 프로젝트에서 버전을 업데이트하는 대신 다음 중 하나를 수행합니다.

  • 메인 프로젝트 내에서 직접 서브 프로젝트를 개발합니다 ( " 서브 모듈의 진정한 특성 "에 설명 됨 ).
  • 또는 origin하위 저장소에서 다른 곳에서 개발중인 동일한 하위 저장소를 참조합니다 . 거기에서 해당 하위 저장소에서 다른 곳에서 변경 한 내용을 가져와야합니다.

두 경우 모두 새 구성을 기록하기 위해 주 프로젝트를 커밋하는 것을 잊지 않아야합니다. 여기에서 업데이트 할 "외부"속성이 없습니다. 모든 과정은 훨씬 더 자연 스럽습니다.

솔직히 이것은 진짜 고통처럼 들리며 개발자가 매번 수동으로 무언가를해야하는 모든 것은 유지 보수의 정기적 인 버그 소스가 될 것입니다.
수퍼 프로젝트의 일부 스크립트를 사용하여이를 자동화하는 방법을 살펴 보겠습니다.

나는 대답했다 :

솔직히, 당신이 옳았을 수도 있습니다 ... 최신 Git 릴리스 1.7.1 까지 입니다.
git diff그리고 git status둘 다 메인 프로젝트에서 실행 되더라도 하위 모듈 상태를 고려하는 법을 배웠습니다.
서브 모듈 수정을 놓칠 수 없습니다.

즉,

— VonC
소스
또한 메인 프로젝트에 하위 모듈을 포함하면 각 하위 모듈은 자체 git 저장소이므로 특정 버전의 하위 모듈, 특정 태그 등을 자유롭게 포함 할 수 있습니다.
— Damien Wilson
1
@VonC : 이것은 Subversion에서 제공하는 "외부"지원과 비슷하게 들립니다. 우리는 이것을 시도했고 프로젝트가 서로에 대한 종속성과 동시에 개발되기 때문에 외부에서 버전 참조를 지속적으로 업데이트하는 것이 매우 번거 롭다는 것을 알았습니다. 다른 옵션이 있습니까 ??
— Paul Alexander
@Paul : 예, 메인 프로젝트에서 버전을 업데이트하는 대신 메인 프로젝트 내에서 직접 하위 프로젝트를 개발하거나 ( stackoverflow.com/questions/1979167/git-submodule-update/… 참조 ) sub-repo 다른 곳에서 개발중인 동일한 하위 저장소를 향한 출처 : 거기에서 다른 곳에서 변경 한 사항을 해당 하위 저장소에서 가져와야합니다. 두 경우 모두 새 구성을 기록하기 위해 주 프로젝트를 커밋하는 것을 잊지 않아야합니다. 업데이트 할 "외부"속성이 없습니다. 모든 과정은 훨씬 더 자연 스럽습니다.
— VonC
3
@Paul : 솔직히 말이 맞을지도 모르겠네요 ... 최신 Git 릴리스 1.7.1까지입니다. ( kernel.org/pub/software/scm/git/docs/RelNotes-1.7.1.txt ) git diff그리고 git status둘 다 메인 프로젝트에서 실행 되더라도 서브 모듈 상태를 고려하는 법을 배웠습니다. 서브 모듈 수정을 놓칠 수 없습니다.
— VonC
1
@PaulAlexander가 무언가를 말할 때까지 나는 그가 실제로 서브 모듈을 사용하고 있다고 믿기로 결정했습니다.
— cregox
2

GitSlave를 사용하면 여러 독립 저장소를 하나로 관리 할 수 ​​있습니다. 각 저장소는 일반 git 명령으로 조작 할 수 있으며 gitslave를 사용하면 모든 저장소에 대해 추가로 명령을 실행할 수 있습니다.

super-repo
+- module-a-repo
+- module-b-repo

gits clone url-super-repo
gits commit -a -m "msg"

Repo-per-project는 Maven과 같은 도구를 사용하여 구성 요소 화 및 단순화 된 빌드에 이점이 있습니다. 프로젝트 별 저장소는 잘못된 쓰레기 커밋 측면에서 개발자가 변경하는 범위를 제한하여 보호 기능을 추가합니다.

— 안드레
소스
gitslave 대 git 하위 모듈의 장단점에 대해 조금 설명해 주시겠습니까?
— MM
1
Gitslave의 가장 큰 장점은 Git 저장소를 단독으로 사용할 수 있다는 것입니다. gitslave 관계에 영향을주지 않고 일반 git 명령으로 저장소를 관리 할 수 ​​있습니다. 그러나 예를 들어 모든 저장소에서 태그를 실행하려면 gitslave가이를 수행 할 수 있습니다.
— Andre
1
내 생각에 서브 모듈은 복잡하다. 개발자는이를 이해하고 밀접하게 작업해야합니다.
— Andre
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.