공통 중첩 하위 모듈을 사용하여 Git 리포지토리 구성

나는 Git 서브 모듈을 좋아한다 . 버전과 함께 종속성을 추적 할 수 있기 때문에 이전 버전의 프로젝트로 롤백하고 해당 버전의 종속성을 안전하고 깨끗하게 빌드 할 수 있습니다. 또한 라이브러리 히스토리는 라이브러리 히스토리가 라이브러리에 종속 된 (및 오픈 소스되지 않을) 애플리케이션과 분리되어 있으므로 오픈 소스 프로젝트로 라이브러리를 공개하는 것이 더 쉽습니다.

직장에서 여러 프로젝트에 대한 워크 플로를 설정하고 있는데, 단일 모 놀리 식 프로젝트를 사용하는 대신이 접근법을 약간 극단적으로 사용하면 어떻게 될지 궁금합니다. 실제로 서브 모듈을 사용 하는 경우 웜의 가능성이 있음을 금방 깨달았습니다 .

: 응용 프로그램의 한 쌍의 치죠 studio하고 player, 그리고 종속 라이브러리 core, graph그리고 network다음과 같이 의존성은 :

• core 독립형
• graph에 따라 core(서브 모듈 ./libs/core)
• network에 정의 됨 core(의 서브 모듈 ./libs/core)
• studio에 의존 graph하고 network(AT 서브 모듈 ./libs/graph및 ./libs/network)
• player에 의존 graph하고 network(AT 서브 모듈 ./libs/graph및 ./libs/network)

CMake를 사용 하고 있으며 각 프로젝트에 단위 테스트와 모든 작업 이 있다고 가정 합니다. 코드 메트릭, 단위 테스트 등을 수행하려면 각 프로젝트 ( studio및 포함 player)를 독립형으로 컴파일 할 수 있어야합니다.

문제는 재귀 적 git submodule fetch이며 다음 디렉토리 구조를 얻습니다.

studio/
studio/libs/                    (sub-module depth: 1)
studio/libs/graph/
studio/libs/graph/libs/         (sub-module depth: 2)
studio/libs/graph/libs/core/
studio/libs/network/
studio/libs/network/libs/       (sub-module depth: 2)
studio/libs/network/libs/core/

공지 사항 core두 번 복제되는 studio프로젝트. 이 낭비되는 디스크 공간 외에도 core두 번 빌드 하고 두 개의 다른 버전이 생길 수 있으므로 빌드 시스템 문제 가 core있습니다.

질문

공통 중첩 하위 모듈의 여러 복사본을 얻지 않고 버전 종속성 및 독립 실행 형 빌드를 얻도록 하위 모듈을 구성하는 방법은 무엇입니까?

가능한 해결책

라이브러리 종속성이 약간의 제안 (예 : "버전 X로 작업하는 것으로 알려진"또는 "버전 X 만 공식적으로 지원됨"방식)이고 잠재적 인 종속 응용 프로그램 또는 라이브러리가 원하는 버전으로 빌드해야하는 경우 다음 시나리오를 상상할 수 있습니다.

• 빌드 시스템을 준비 graph하고 network찾을 위치를 알려주십시오 core(예 : 컴파일러 포함 경로를 통해). "독립형"및 "종속성"이라는 두 개의 빌드 대상을 정의하십시오. 여기서 "독립형"은 "종속성"을 기반으로하며 로컬 core하위 모듈 을 가리키는 포함 경로를 추가합니다 .
• 추가 종속성을 소개하십시오 : studioon core. 그런 다음 studiobuilds core, 포함 경로를 core하위 모듈 의 자체 복사본으로 설정 한 다음 빌드 graph하고 network"종속성"모드로 설정합니다.

결과 폴더 구조는 다음과 같습니다.

studio/
studio/libs/                    (sub-module depth: 1)
studio/libs/core/
studio/libs/graph/
studio/libs/graph/libs/         (empty folder, sub-modules not fetched)
studio/libs/network/
studio/libs/network/libs/       (empty folder, sub-modules not fetched)

그러나,이 몇 가지 빌드 시스템 마술 (나는이 CMake와 함께 할 수 꽤 확신) 및 버전 업데이트 부분에 수동 약간의 작업 (업데이트가 필요 graph또한 업데이트가 필요할 수 core와 network의 호환 버전을 얻기 위해 core모든 프로젝트를) .

이것에 대한 생각?

이 파티에 매우 늦었지만 귀하의 질문에 아직 완전한 답변이없는 것 같으며 Google에서 매우 인기가 있습니다.

C ++ / CMake / Git / Submodules와 똑같은 문제가 있으며 MATLAB / Git / Submodules와 비슷한 문제가 있습니다. MATLAB이 컴파일되지 않았기 때문에 약간의 이상한 점이 있습니다. 나는 우연히 이 비디오 는 "솔루션"을 제안 보인다 최근. 나는 본질적으로 서브 모듈을 버리는 것을 의미하기 때문에 솔루션을 좋아하지 않지만 문제를 제거합니다. @errordeveloper가 권장하는 것과 같습니다. 각 프로젝트에는 하위 모듈이 없습니다. 프로젝트를 빌드하려면 수퍼 프로젝트를 작성하여 빌드하고이를 종속 항목의 형제로 포함하십시오.

따라서 개발 프로젝트 graph는 다음과 같습니다.

buildgraph/graph
buildgraph/core

스튜디오 프로젝트는 다음과 같습니다.

buildstudio/studio
buildstudio/graph
buildstudio/network
buildstudio/core

슈퍼 프로젝트는 단지 하나의 메인 CMakeLists.txt모듈이고 많은 서브 모듈입니다. 그러나 어떤 프로젝트에도 하위 모듈이 없습니다.

이 접근 방식에서 볼 수있는 유일한 비용은 실제 프로젝트를 구축하는 데 전념하는 사소한 "슈퍼 프로젝트"의 확산입니다. 누군가 누군가 프로젝트 중 하나를 손에 넣는 경우, 슈퍼 프로젝트를 찾지 않고 그 의존성이 무엇인지 쉽게 알 수있는 방법이 없습니다. 예를 들어 Github에 실제로보기 흉한 위치에 놓일 수 있습니다.

하위 모듈 graph과 network하위 모듈을 모두 통합 할 때 의 역사에서 주어진 시간에 studio항상 동일한 버전을 가져야 한다고 가정합니다 . 나는 simlink 것 으로 서브 모듈을 .corestudiostudio/libs/corestudio/libs/{graph,network}/libs

최신 정보:

나는 당신이 언급 한 의존성으로 여러 저장소를 만들었습니다.

./core      <--- (v2)
./graph
./graph/libs
./graph/libs/core  <--- (v2)
./graph/.gitmodules
./network
./network/libs
./network/libs/core  <--- (v1)
./network/.gitmodules
./studio
./studio/libs
./studio/libs/graph
./studio/libs/graph/libs
./studio/libs/graph/libs/core <--- (v1)
./studio/libs/graph/.gitmodules
./studio/libs/network
./studio/libs/network/libs
./studio/libs/network/libs/core  <--- (v1)
./studio/libs/network/.gitmodules
./studio/studio
./studio/.gitmodules

v1의 v2두 가지 버전이 core있습니다. graph버전 2는 반면, 처리하는 network몇 가지 작업을 필요로하고 버전 1에서에 붙어 studio의 지역 임베디드 버전 core에 모두 포인트 v1작업 프로그램을 위해. 이제 빌드 관점을 제외하고 모든 것이 하위 모듈과 잘 작동합니다.

이제 다음 디렉토리를 제거 할 수 있습니다.

./studio/libs/network/libs/core

그리고 심볼릭 링크로 교체하십시오.

./studio/libs/network/libs/core@ -> ../../graph/libs/core/

나는이 변경 사항을 로컬로 커밋하고 core내부의 두 가지 별도 버전을 가질 수는 studio없지만 core한 번만 빌드 합니다. 로 업그레이드 할 준비가되면 다음을 수행 할 v2수 있습니다.

 git submodule update # (--rebase ?)

... 스튜디오 / libs / 네트워크 내부.

나는 하나의 하위 모듈 깊이를 갖도록 평평하게하고 모든 모듈을 하위 모듈로 보유하고 README 및 빌드 스크립트와는 다른 저장소를 보유합니다. 종속성을 연결하는 각 패키지마다 별도의 빌드 스크립트가 있습니다. 그렇지 않으면 패키지에 대해 별도의 저장소를 가질 수 있습니다.

하위 모듈을 사용하지 않을 것입니다.

svn-externals의 경우와 마찬가지로 유혹적입니다. 그러나 연결 한 모든 프로젝트가 1 년 안에 같은 위치에 있는지 확인할 수 있습니까? 5시에 어때?

따라서 필요한 모든 종속성을 프로젝트에 복사하고 있습니다. 이것은 내 저장소가 유효한 한 정확한 상태를 확인할 수 있음을 의미합니다.

기본적으로 다음과 같은 폴더 구조가 있습니다.

myproject/... [sources etc]
ext/ [third-party dependencies]


e.g. ext/boost, ext/cppunit

이것은 디스크 공간 관점에서 그리 좋지는 않지만, repo를 훨씬 더 많이 사용할 수있는 한 기록 된 모든 상태를 확인할 수 있다는 보장이 중요합니다.

또한 여기에 설명 된대로 서브 모듈에 많은 문제가 있습니다

여기서 똑같은 문제에 직면합니다. 솔루션 중 하나는 일부의 repo 가질 수 libs개최 것 core, network, graph서브 모듈 및 종속성을 찾을 수있는 libs와 각을 말할 것 단지 CMakeLists있다. 각 응용 프로그램은 이제 libs하위 모듈로 사용되며 필요한 라이브러리 만 사용합니다.

각 lib의 테스트는 두 가지 방법으로 설정할 수 있습니다.

• core_testing, graph_testing, network_testing을 별도의 응용 프로그램으로 사용하십시오.
• 테스트 서버를 테스트 서버에 배포하고 cmake를 사용하여 테스트를 실행하는 동안 라이브러리를 찾습니다