이 GitPro 페이지 는 자식 서브 모듈 업데이트의 결과를 훌륭하게 요약합니다.
를 실행 git submodule update하면 특정 버전의 프로젝트가 체크 아웃되지만 분기에는 포함되지 않습니다. 이를 헤드 분리라고합니다. 이는 HEAD 파일이 기호 참조가 아닌 커밋을 직접 가리키는 것을 의미합니다.
문제는 일반적으로 분리 된 헤드 환경에서 작업하기를 원하지 않는다는 것 입니다. 변경 사항을 잃기 쉽기 때문 입니다.
초기 하위 모듈 업데이트를 수행하고, 작업 할 분기를 만들지 않고 해당 하위 모듈 디렉토리에서 커밋 한 다음 그 동안 커밋하지 않고 슈퍼 프로젝트에서 git 하위 모듈 업데이트를 다시 실행하면 Git이 변경 사항을 알리지 않고 덮어 씁니다. 기술적으로는 작업을 잃지 않지만 지점을 가리 키지 않으므로 검색하기가 다소 어려울 수 있습니다.
2013 년 3 월 참고 :
" git submodule tracking latest " 에서 언급했듯이 , 이제 서브 모듈 (git1.8.2)은 분기를 추적 할 수 있습니다.
# add submodule to track master branch
git submodule add -b master [URL to Git repo];
# update your submodule
git submodule update --remote
# or (with rebase)
git submodule update --rebase --remote
" git submodule update --remotevsgit pull "를 참조하십시오 .
MindTooth 의 답변 은 수동 업데이트 (로컬 구성 없음)를 보여줍니다.
git submodule -q foreach git pull -q origin master
두 경우 모두 하위 모듈 참조 ( gitlink , 상위 repo 인덱스 의 특수 항목) 가 변경 되며 기본 리포지토리에서 해당 참조를 추가, 커밋 및 푸시해야합니다.
다음에 해당 상위 저장소를 복제 할 때 새 SHA1 참조를 반영하도록 서브 모듈을 채 웁니다.
이 답변의 나머지 부분에서는 클래식 하위 모듈 기능 ( 고정 커밋에 대한 참조 , 하위 모듈 개념의 모든 요점)에 대해 자세히 설명합니다 .
이 문제를 피하려면 git checkout -b work 또는 이와 동등한 것으로 하위 모듈 디렉토리에서 작업 할 때 분기를 작성하십시오. 서브 모듈 업데이트를 두 번 수행해도 여전히 작업을 되돌릴 수 있지만 최소한 포인터를 다시 가져와야합니다.
하위 모듈이있는 분기를 전환하는 것도 까다로울 수 있습니다. 새 분기를 작성하고 거기에 하위 모듈을 추가 한 다음 해당 하위 모듈이없는 분기로 다시 전환하면 하위 모듈 디렉토리는 추적되지 않은 디렉토리로 계속 유지됩니다.
따라서 귀하의 질문에 답변하십시오 :
정기적 인 리포지토리에서와 같이 브랜치 / 수정을 생성하고 푸시 / 풀을 사용할 수 있습니까? 또는주의해야 할 사항이 있습니까?
브랜치를 만들고 수정을 푸시 할 수 있습니다.
경고 ( Git Submodule Tutorial에서 ) : 서브 모듈 변경 사항을 참조하는 수퍼 프로젝트에 대한 변경 사항을 공개 (푸시)하기 전에 항상 서브 모듈 변경 사항을 공개 (푸시)하십시오. 하위 모듈 변경 사항을 게시하지 않으면 다른 사용자가 리포지토리를 복제 할 수 없습니다.
서브 태그 참조 커밋을 말 (태그) 1.0에서 1.1로 어떻게 진행합니까 (원래 repo의 헤드가 이미 2.0 임에도 불구하고)
" 하위 모듈 이해하기 " 페이지 가 도움이 될 수 있습니다
Git 서브 모듈은 두 개의 움직이는 부분을 사용하여 구현됩니다.
.gitmodules파일- 특별한 종류의 나무 객체.
이들은 함께 특정 저장소의 특정 개정판을 삼각 측량하여 프로젝트의 특정 위치로 체크 아웃합니다.
로부터 자식 서브 모듈 페이지
메인 프로젝트 내에서 서브 모듈의 내용을 수정할 수 없습니다
100 % 정확 : 서브 모듈을 수정할 수 없으며 커밋 중 하나만 참조하십시오.
이것이 메인 프로젝트 내에서 서브 모듈을 수정할 때 다음과 같은 이유입니다.
- 하위 모듈 내 에서 (업스트림 모듈로) 커밋하고 푸시해야합니다.
- 그런 다음 기본 프로젝트로 이동하여 다시 커밋하십시오 (주 프로젝트가 방금 생성하고 푸시 한 새로운 하위 모듈 커밋을 참조하기 위해)
하위 모듈을 사용하면 구성 요소 기반 접근 방식 개발 을 할 수 있습니다 . 여기서 주 프로젝트는 다른 구성 요소 (여기서는 "하위 모듈로 선언 된 다른 Git 리포지토리")의 특정 커밋 만 참조합니다.
하위 모듈은 주요 프로젝트 개발주기에 구속되지 않는 다른 Git 저장소에 대한 마커 (커밋)입니다.이 모듈 ( "다른"Git 저장소)은 독립적으로 발전 할 수 있습니다.
필요한 다른 커밋에서 다른 리포지토리를 선택하는 것은 메인 프로젝트에 달려 있습니다.
그러나 편의상 주 프로젝트에서 해당 하위 모듈 중 하나를 직접 수정하려면 먼저 Git을 사용하여 해당 하위 모듈 수정 사항을 원래 Git 저장소에 게시 한 다음 주 프로젝트를 참조하십시오. 상기 서브 모듈 의 새로운 버전.
그러나 주요 아이디어는 다음과 같습니다.
- 자신의 수명주기가
- 자신의 태그 세트를 가지고
- 자체 개발
기본 프로젝트에서 참조하는 특정 커밋 목록은 구성을 정의합니다 (이것은 단순한 버전 제어 시스템을 포괄 하는 구성 관리의 모든 것입니다 )
메인 프로젝트 와 동시에 컴포넌트를 개발할 수 있다면 (메인 프로젝트를 수정하면 서브 디렉토리를 수정해야하고 그 반대도 마찬가지이므로) 더 이상 "서브 모듈"이 될 것입니다. 하위 트리 병합 (또한 cvs에서 분산 리포지토리로 레거시 코드베이스 전송 질문에 나와 있음 ), 두 Git 리포지토리 의 내역을 연결합니다.
그것이 Git 서브 모듈의 본질을 이해하는 데 도움이됩니까?