(2019 년 2 분기 Git 2.22 도입 git submodule set-branch --branch aBranch -- <submodule_path>)
참고 당신이 경우 기존의 서브 모듈 되지 않은 아직 지점을 추적 (다음을, 당신은 자식 1.8.2+이있는 경우 ) :
부모 리포지토리가 하위 모듈이 이제 분기를 추적한다는 것을 알고 있어야합니다.
cd /path/to/your/parent/repo
git config -f .gitmodules submodule.<path>.branch <branch>
서브 모듈이 실제로 해당 분기의 최신 버전인지 확인하십시오.
cd path/to/your/submodule
git checkout -b branch --track origin/branch
# if the master branch already exist:
git branch -u origin/master master
( "원산지"의 이름으로 되 REPO 상류 원격 서브 모듈.로부터 클로닝되었다 해당 서브 모듈을 표시 안에. 일반적으로, 그것이 '원점')
git remote -v
부모 저장소에 하위 모듈의 새로운 상태를 기록하는 것을 잊지 마십시오.
cd /path/to/your/parent/repo
git add path/to/your/submodule
git commit -m "Make submodule tracking a branch"
해당 서브 모듈에 대한 후속 업데이트는 다음 --remote옵션 을 사용해야합니다 .
# update your submodule
# --remote will also fetch and ensure that
# the latest commit from the branch is used
git submodule update --remote
# to avoid fetching use
git submodule update --remote --no-fetch
참고로 힘내 2.10+ (Q3 2016), 당신은 '사용할 수있는 .지점 이름으로'
브랜치의 이름은 다음과 같이 기록 submodule.<name>.branch에 .gitmodules대한 update --remote. 하위 모듈의 분기 이름이 현재 저장소의 현재 분기와 동일한 이름을 나타 내기 위해
특수 값 .인를 사용합니다 .
그러나 LubosD의 의견 에 따르면
를 사용 git checkout하여 수행 할 분기 이름이 " ."인 경우 커밋되지 않은 작업이 종료됩니다! 대신
사용하십시오 git switch.
이는 Git 2.23 (2019 년 8 월) 이상을 의미합니다.
" 혼란스러워git checkout "
분기에 따라 모든 하위 모듈을 업데이트하려는 경우 :
git submodule update --recursive --remote
댄 카메론 (Dan Cameron) 이 그의 답변 에서 언급 한 것처럼 , 업데이트 된 각 서브 모듈에 대한 결과는 거의 항상 분리 된 HEAD가 될 것 입니다.
( Clintm의 노트 코멘트에 당신이 실행하는 경우, git submodule update --remote그 결과 SHA1는 서브 모듈에 현재 분기와 같은, 그것은 아무것도 할 떠나 서브 모듈을 여전히 "그 지점에"이 아닌 분리 된 머리 상태에 있지 않습니다. )
브랜치가 실제로 체크 아웃되도록 (그리고 부모 리포지토리의 서브 모듈을 나타내는 특수 항목 의 SHA1을 수정하지 않도록 )하기 위해 다음과 같이 제안합니다.
git submodule foreach -q --recursive 'branch="$(git config -f $toplevel/.gitmodules submodule.$name.branch)"; git switch $branch'
각 하위 모듈은 여전히 동일한 SHA1을 참조하지만 새 커밋을 수행하는 경우 하위 모듈이 추적하려는 분기에서 참조하므로 해당 커밋을 푸시 할 수 있습니다.
하위 모듈 내에서 푸시 한 후에는 상위 리포지토리로 돌아가서 수정 된 하위 모듈에 대해 새 SHA1을 추가, 커밋 및 푸시하는 것을 잊지 마십시오.
사용주의 $toplevel추천, 코멘트에 의해 알렉산더 포그 레브 냑을 . 커밋 f030c96
$toplevel : git1.7.2에서 2010 년 5 월에 도입되었습니다 .
최상위 디렉토리의 절대 경로를 포함합니다 (있는 곳 .gitmodules).
dtmland주석에 추가합니다 :
foreach 스크립트는 분기를 따르지 않는 하위 모듈을 체크 아웃하지 못합니다.
그러나이 명령은 다음 두 가지를 모두 제공합니다.
git submodule foreach -q --recursive 'branch="$(git config -f $toplevel/.gitmodules submodule.$name.branch)"; [ "$branch" = "" ] && git checkout master || git switch $branch' –
같은 명령이지만 읽기 쉽습니다.
git submodule foreach -q --recursive \
'branch="$(git config -f $toplevel/.gitmodules submodule.$name.branch)"; \
[ "$branch" = "" ] && \
git checkout master || git switch $branch' –
umläute 을 세련 dtmland 단순화 된 버전의 명령 코멘트에 :
git submodule foreach -q --recursive 'git switch $(git config -f $toplevel/.gitmodules submodule.$name.branch || echo master)'
여러 줄 :
git submodule foreach -q --recursive \
'git switch \
$(git config -f $toplevel/.gitmodules submodule.$name.branch || echo master)'
Git 2.26 (Q1 2020) 이전에는 서브 모듈에서 업데이트를 재귀 적으로 가져 오도록 지시 된 페치는 필연적으로 많은 양의 출력을 생성하며 오류 메시지를 찾기 어렵게됩니다.
이 명령은 작업이 끝날 때 오류가 발생한 하위 모듈을 열거하도록 지시되었습니다 .
Emily Shaffer ( )의 commit 0222540 (2020 년 1 월 16 일)을 참조하십시오 . (의해 병합 Junio C 하마노 - - 에 b5c71cc 커밋 05 이월 2020)nasamuffin
gitster
fetch: 서브 모듈 페치 중 실패 강조
에 의해 서명 : 에밀리 셰퍼
많은 서브 모듈이있을 때 서브 모듈 페치가 실패하는 경우, 하나 이상의 페치가 다시 실패하면 단독 실패 서브 모듈 페치의 오류가 다른 서브 모듈의 활동에 묻 힙니다 fetch-by-oid.
늦게 오류를 불러내 어 사용자가 무언가 잘못되었다는 것을 알 수 있도록합니다 .
주위 fetch_finish()에 run_processes_parallel,mutexing에 의해 동 기적으로 만 호출 되기 때문에 필요하지 않습니다 submodules_with_errors.