Git 하위 모듈 업데이트

Git 하위 모듈 업데이트

Git 하위 모듈 업데이트 설명서에서 다음이 무엇을 의미하는지 잘 모르겠습니다.

한 됩니다.서브 모듈 HEAD를 분리합니다. 그렇지 않은 경우에 따라--rebase또는--merge지정됨...

안녕하십니까?--rebase/--merge상황을 바꾸나요?

저의 주요 사용 사례는 여러 개의 중앙 저장소를 보유하는 것이며, 이를 하위 모듈을 통해 다른 저장소에 포함시킬 것입니다.이러한 중앙 저장소를 원래 위치에 직접 배치하거나 내장 저장소(서브 모듈을 통해 사용하는 저장소) 내에서 개선할 수 있기를 바랍니다.

• 이러한 하위 모듈 내에서 일반 리포지토리와 마찬가지로 분기/수정 사항을 생성하고 푸시/풀을 사용할 수 있습니까? 아니면 주의해야 할 사항이 있습니까?
• (원래 저장소의 헤드가 이미 2.0에 있더라도) 하위 모듈 참조 커밋을 say(태그 있음) 1.0에서 1.1로 앞당기거나 사용되는 분기의 커밋을 선택하려면 어떻게 해야 합니까?

이 GitPro 페이지는 Git 서브모듈 업데이트의 결과를 잘 요약합니다.

을 할 때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 --remote vs. "를 참조하십시오.

MindTooth의 답변은 (로컬 구성 없이) 수동 업데이트를 보여줍니다.

git submodule -q foreach git pull -q origin master

두 경우 모두 하위 모듈 참조(상위 레포 인덱스의 특수 항목인 gitlink)를 변경하며, 기본 레포에서 해당 참조를 추가, 커밋 및 푸시해야 합니다.
다음에 해당 상위 레포를 복제할 때 하위 모듈이 채워지고 이러한 새 SHA1 참조가 반영됩니다.

이 답변의 나머지 부분에서는 고전적인 하위 모듈 기능(하위 모듈 개념의 배후에 있는 모든 지점인 고정 커밋에 대한 참조)을 자세히 설명합니다.

---

이 문제를 방지하려면 git checkout -b work 또는 이와 유사한 작업을 통해 하위 모듈 디렉토리에서 작업할 때 분기를 생성합니다.하위 모듈 업데이트를 두 번째로 수행하면 작업이 계속 복구되지만 적어도 다시 시작할 포인터는 있습니다.

하위 모듈이 포함된 분기를 전환하는 것도 까다로울 수 있습니다.새 분기를 생성하고 하위 모듈을 추가한 다음 해당 하위 모듈이 없는 분기로 다시 전환해도 하위 모듈 디렉터리는 추적되지 않는 디렉터리로 남아 있습니다.

---

질문에 대한 답변:

일반 저장소에서와 같이 분기/수정을 생성하고 푸시/풀을 사용할 수 있습니까? 아니면 주의해야 할 사항이 있습니까?

분기를 생성하고 수정 사항을 푸시할 수 있습니다.

경고(Git 하위 모듈 튜토리얼에서):하위 모듈 변경사항을 참조하는 수퍼 프로젝트에 변경사항을 게시(푸시)하기 전에 항상 하위 모듈 변경사항을 게시(푸시)합니다.하위 모듈 변경 내용을 게시하지 않으면 다른 사용자가 리포지토리를 복제할 수 없습니다.

(원래 레포의 헤드가 이미 2.0에 도달했음에도 불구하고) 하위 모듈 참조 커밋을 say(태그 부착) 1.0에서 1.1로 어떻게 앞당길 수 있습니까?

"하위 모듈 이해" 페이지가 도움이 될 수 있습니다.

Git 하위 모듈은 두 가지 이동 부품을 사용하여 구현됩니다.

• 그자리의 .gitmodules 및 일및
• 특별한 종류의 나무 물체

이것들은 함께 프로젝트의 특정 위치로 체크아웃된 특정 리포지토리의 특정 개정판을 삼각측량합니다.

---

Git 하위 모듈 페이지에서

기본 프로젝트 내에서 하위 모듈의 내용을 수정할 수 없습니다.

100% 맞습니다. 서브모듈은 수정할 수 없으며 커밋 중 하나만 참조할 수 있습니다.

따라서 기본 프로젝트 내에서 하위 모듈을 수정할 때 다음 작업을 수행해야 합니다.

• 서브모듈 내에서 (업스트림 모듈로) 커밋하고 밀어야 합니다.
• 그런 다음 기본 프로젝트로 이동하여 다시 커밋합니다(해당 메인 프로젝트가 방금 생성하고 푸시한 새 하위 모듈 커밋을 참조하기 위해).

하위 모듈을 사용하면 구성 요소 기반 접근 방식을 개발할 수 있습니다. 여기서 주 프로젝트는 다른 구성 요소의 특정 커밋(여기서는 "하위 모듈로 선언된 기타 Git 저장소")만 참조합니다.

서브모듈은 메인 프로젝트 개발 주기에 구속되지 않는 다른 Git 저장소에 대한 마커(커밋)입니다. 서브모듈("다른" Gitrepo)은 독립적으로 진화할 수 있습니다.
다른 레포에서 필요한 커밋을 선택하는 것은 주요 프로젝트에 달려 있습니다.

그러나 편의상 메인 프로젝트에서 직접 하위 모듈 중 하나를 수정하려면 Git을 사용하여 해당 하위 모듈 수정 사항을 원래 Gitrepo에 게시한 다음 해당 하위 모듈의 새 버전을 참조하여 메인 프로젝트를 커밋할 수 있습니다.

그러나 주요 아이디어는 다음과 같은 특정 구성 요소를 참조하는 것입니다.

• 고유한 라이프사이클이 있습니다.
• 고유한 태그 집합이 있습니다.
• 독자적인 발전이 있습니다.

기본 프로젝트에서 참조하는 특정 커밋 목록은 사용자의 구성을 정의합니다(이것이 바로 Configuration Management의 목적이며, 단순한 버전 제어 시스템 포함).

만약 구성 요소가 정말로 당신의 메인 프로젝트와 동시에 개발될 수 있다면(메인 프로젝트의 수정은 하위 디렉터리를 수정하는 것을 포함하고 그 반대도 마찬가지이기 때문에), 그것은 더 이상 "하위 모듈"이 아니라 하위 트리 병합이 될 것입니다(CVS에서 분산 저장소로 레거시 코드 기반 전송 문제에도 제시됨).두 깃레포의 역사를 함께 연결하는 것.

그것이 Git 서브모듈의 본질을 이해하는 데 도움이 됩니까?

각 하위 모듈을 업데이트하려면 저장소 루트에서 다음 명령을 실행할 수 있습니다.

git submodule -q foreach git pull -q origin master

-q 옵션을 제거하여 전체 공정을 따를 수 있습니다.

주소 지정하기--rebase대.--merge옵션:

슈퍼 저장소 A와 하위 모듈 B가 있고 하위 모듈 B에서 작업을 수행하려고 한다고 가정해 보겠습니다.당신은 당신의 숙제를 했고 전화를 한 후 그것을 압니다.

git submodule update

헤드가 없는 상태이므로 이 시점에서 수행한 커밋은 다시 시작하기 어렵습니다.서브모듈 B의 새로운 분기에 대한 작업을 시작했습니다.

cd B
git checkout -b bestIdeaForBEver
<do work>

한편, A 프로젝트의 다른 사람은 B의 최신 버전과 가장 훌륭한 버전이 A가 받을 자격이 있다고 결정했습니다.습관적으로 가장 최근의 변경 사항을 아래로 병합하고 하위 모듈을 업데이트합니다.

<in A>
git merge develop
git submodule update

이런!당신은 다시 머리가 없는 상태로 돌아왔는데, 아마도 B가 이제 B의 새로운 팁과 관련된 SHA 또는 다른 약속을 가리키고 있기 때문일 것입니다.만약 당신이 가지고 있었다면:

git merge develop
git submodule update --rebase

Fast-forwarded bestIdeaForBEver to b798edfdsf1191f8b140ea325685c4da19a9d437.
Submodule path 'B': rebased into 'b798ecsdf71191f8b140ea325685c4da19a9d437'

이제 B에 대한 최고의 아이디어가 새로운 약속에 기반을 두고 있으며, 더 중요한 것은 당신이 여전히 머리가 없는 상태가 아니라 B에 대한 개발 지점에 있다는 것입니다!

(계속)--merge 사항을 합니다. 을 UpdateSHA 를 추가합니다변경 내용을 UpdateSHA 이후에 다시 적용하는 대신 작업 분기에 SHA를 적용합니다.)

1옵션인 Git 1.8.2를 합니다.--remote정확하게 이 동작을 가능하게 할 것입니다. 중입니다.

git submodule update --rebase --remote

에서는 각 하위 모듈의 업스트림에서 최신 변경 사항을 가져와 기본 재배치한 다음 하위 모듈의 최신 버전을 확인합니다.설명서에서 설명하는 바와 같이:

--원격의

이 옵션은 업데이트 명령에 대해서만 유효합니다.슈퍼 프로젝트의 기록된 SHA-1을 사용하여 하위 모듈을 업데이트하는 대신 하위 모듈의 원격 추적 분기 상태를 사용합니다.

은 이실행는것같다니습과를 실행하는 것과 .git pull각 하위 모듈에서, 일반적으로 원하는 것이 정확합니다.

(이 답변에서 복사했습니다.)

언급URL : https://stackoverflow.com/questions/1979167/git-submodule-update