동일한 전체 프로젝트의 일부인 여러 Git 리포지토리 그룹화

14

서버 구성 요소, 웹 응용 프로그램 구성 요소, iOS 구성 요소, Android 구성 요소 등 여러 구성 요소가있는 프로젝트가 있다고 가정 해 보겠습니다.이 구성 요소는 모두 별도의 코드베이스이지만 느슨하게 연결되어 있습니다 (예 : 서버 변경). 코드는 다른 모든 구성 요소를 변경해야 할 수도 있습니다)

Git에서이 프로젝트를 구성하는 가장 효율적인 방법은 무엇입니까? 하나의 저장소에 모두 넣으면 항상 최신 버전을 사용하지만 다른 구성 요소가 아닌 한 구성 요소를 변경하기 시작하면 문제가 발생합니다.

반면에 각 구성 요소를 별도의 리포지토리로 만드는 경우 앱의 버전 2.0에 서버 구성 요소의 버전 1.5 등이 필요하다는 것을 알 수 있도록 이러한 리포지토리를 어떻게 "링크"할 수 있습니까?

여러 관련 저장소를보다 효과적으로 관리하기 위해 최신 readme (또는 보이지 않는 더 나은 솔루션)를 유지하는 것 외에 git에 기능이 있습니까?

git

— 사용자 1203054
소스

이러한 구성 요소는 실제로 릴리스 가능 구성 요소와 라이브러리 간의 관계처럼 서로 의존합니까? 아니면 모든 릴리스 가능 구성 요소를 동기화 상태로 유지하려고합니까?

— 쓸모없는

다음 은 StackOverflow에 대한 이전 토론입니다 (기적적으로 아직 닫히지 않았습니다).

— Dan Dascalescu

6

하위 프로젝트는 DVCS (Distributed Version Control Systems)가 풀리지 않았더라도 확실히 약간 위태로워지기 시작한 곳입니다.

Git 하위 모듈 과 Mercurial 하위 리포지토리는 모두 하위 프로젝트 지원을 목표로합니다. 둘 다 릴리스 별 기능이 향상되었습니다. Mercurial의 이전 "이 기능이 존재하지만 사용하지 말아야합니다"경고는 더 이상 전면 및 중앙이 아닙니다.

그럼에도 불구하고, 다중 프로젝트 저장소는 모두가 사용하는 기능이 아닌 특수한 사용 사례로 남아 있습니다. 문서에는 수많은 프로젝트와 "이 사용법"지침이 포함되어 있는데 "프로젝트 프로젝트"관리는 두 가지 수준의 관심사이며 메타 관리는 직접적인 단일 수준 프로젝트 관리와는 약간 다르지만 실제로는 다릅니다. 결과적으로 경험이 훨씬 적습니다. 그리고 "git submodules을 사용하지 마십시오!"라는 부족이 없습니다 "수은 하위 저장소를 피하십시오!" 의견과 블로그 게시물.

하위 저장소에 대한 내 자신의 경험이 혼합되었습니다. 그것은 효과가 있었지만 성가시다. 나는 하위 프로젝트의 아이디어를 좋아하지만 실제로는 큰 올인원 리포지토리 또는 동반자 형제 프로젝트와 같은 대안이 더 쉽게 정리 될 수 있습니다 (매우 우아하지는 않지만). 하위 리포지토리가 주류이며 고통이 아닌 날을 기대하지만 아직은 경험하지 못했습니다.

서브 모듈 / 서브 포스를 관리하는 것이 효과가 없다고 말하는 것은 아니지만,주의해서 수행해야하며, 사전 실험과 계획이 필요합니다.

Git에 집중하고 있다면 Git 서브 트리도 살펴 봐야한다. Git 서브 트리는 git 서브 모듈보다 나은 대안이 될 수있다 .

— 조나단 유니스
소스

1

2016 년에 다시 방문 : Hg 문서는 여전히 하위 저장소 를 최후의 수단 이라고 부릅니다 . Git 문서는 더욱 열성적이며 하위 모듈 기능이 더욱 통합되었습니다. 또한 둘 다 중첩 된 repos를 잘 처리 합니다 (중첩 된 repo가 관리하는 파일로 "공을 가지고 있음"을 인식)하여 또 다른 유용한 하위 repo 옵션을 제공합니다. 그러나 DVCS 도구는 여전히 단일 수준 저장소에 중점을 두므로 "하위 저장소 => 다중 수준 관리"및 "드래곤이 있습니다"경고는 여전히 관련이 있습니다.

— Jonathan Eunice

2

C #을 사용하면 NuGet을 사용할 수 있습니다.

각 구성 요소를 라이브러리로 만들고 자체 저장소에 보관하십시오. 시맨틱 버전 관리에 따라 버전을 지정한 기본 구성 요소를 릴리스하십시오.

마지막으로 빌드 서버가 라이브러리를 NuGet 패키지로 패키징하고 프론트 엔드 구성 요소 (iOS, Android)의 프로젝트에서 해당 NuGet 패키지를 사용하도록하십시오.

다른 언어에서도 동일한 기본 접근 방식 (버전 및 패키지 종속성)을 사용할 수 있지만 편리하지 않을 수 있습니다.

Git 하위 모듈을 사용하지 않는 것이 좋습니다. 이론적으로 이러한 종류의 문제에 사용할 수는 있지만 가치보다 큰 번거 로움을 느낍니다.

— 윌버 트
소스

2

제 생각에 이것은 실제로 얼마나 많이 연결되어 있는지에 달려 있습니다. git bisect회귀를 추적 할 때 자동으로 실행할 수 있는 것이 좋지만 모든 커밋이 다른 버전의 다른 종속성에 따라 실행되는 경우에는 수행하기가 어렵습니다.

두 가지 가능한 옵션은 하위 모듈이있는 하나의 리포지토리 또는 올바른 버전 관리 방법이있는 여러 리포지토리입니다.

앱의 버전 2.0에 서버 구성 요소의 버전 1.5 등이 필요하다는 것을 알 수 있도록 이러한 리포지토리를 어떻게 "링크"할 수 있습니까?

이것은 일반적으로 Git 자체가 아닌 일부 종속성 관리 프레임 워크 (예 : Gradle, Maven)의 도메인입니다.

— 편집증
소스