집 >기술 주변기기 >IT산업 >git에서 서브 모듈을 이해하고 작업합니다

git에서 서브 모듈을 이해하고 작업합니다

Joseph Gordon-Levitt원래의: 2025-02-10 15:58:09130검색

Understanding and Working with Submodules in Git 현대 소프트웨어 프로젝트는 주로 다른 프로젝트의 작업 결과에 의존합니다. 다른 사람이 우수한 솔루션을 작성하고 코드에서 바퀴를 재창조한다면, 그것은 큰 시간 낭비 일 것입니다. 그렇기 때문에 많은 프로젝트가 라이브러리 나 모듈과 같은 타사 코드를 사용하는 이유입니다.

세계에서 가장 인기있는 버전 제어 시스템 인 git은 이러한 종속성을 관리하는 우아하고 강력한 방법을 제공합니다. "서브 모듈"이라는 개념을 통해 타사 라이브러리를 포함하고 관리하면서 우리 자신의 코드와 명확하게 분리되어 있습니다.

이 기사는 왜 git 하위 모듈이 유용한 지, 정확히 무엇이며 어떻게 작동하는지 설명합니다.

키 포인트

git 서브 모듈은 프로젝트에서 타사 라이브러리를 관리하고 주 코드 기반에서 명확하게 분리하는 강력하고 간단한 방법입니다. 이들은 다른 부모 git 저장소에 배치 된 표준 GIT 저장소입니다.

프로젝트에 하위 모듈을 추가하려면 별도의 폴더를 작성한 다음 "git submodule add"명령을 사용한 다음 원하는 라이브러리의 URL을 사용합니다. 이로 인해 저장소를 프로젝트에 서브 모듈로 클론하여 기본 프로젝트의 저장소와 분리합니다.

git 하위 모듈이 포함 된 프로젝트를 클로닝 할 때, 하위 모듈은 "git clone"명령에서 "-recurse-submodules"옵션을 사용하여 자동으로 초기화되고 클로닝됩니다. 이 작업을 수행하지 않으면 서브 모듈 폴더가 클로닝 후 비어 있으며 "Git 하위 모듈 업데이트 (Init -Recursive”로 채워야합니다. git 하위 모듈에서는 지점이 아닌 특정 버전이 체크 아웃되어 기본 프로젝트에서 사용되는 정확한 코드를 완전히 제어 할 수 있습니다. 하위 모듈을 업데이트하려면 "git submodule update"를 사용한 다음 하위 모듈 이름을 사용합니다.

git 하위 모듈이 귀중한 구조인지 명확하게 설명하기 위해 에

서브 모듈이없는 경우를 살펴 보겠습니다. 오픈 소스 라이브러리와 같은 타사 코드를 포함 해야하는 경우 쉬운 방법을 선택할 수 있습니다. Github에서 코드를 다운로드하여 프로젝트 어딘가에 넣으십시오. 이 방법은 매우 빠르지 만 여러 가지 이유로 깨끗하지 않습니다.

제 3 자 코드를 프로젝트에 강제로 복사하면 실제로 여러 프로젝트를 하나의 프로젝트에 혼합하는 것입니다. 자신의 프로젝트와 다른 사람들의 프로젝트 (도서관) 사이의 경계가 흐려지기 시작합니다.

라이브러리 코드를 업데이트해야 할 때마다 (관리자가 새로운 기능을 제공하거나 심각한 버그를 수정하기 때문에) 다운로드, 복사 및 붙여 넣어야합니다. 이것은 곧 지루한 과정이 될 것입니다.

소프트웨어 개발에서 "다른 것들을 분리"하는 일반적인 규칙은 불합리하지 않습니다. 이는 자신의 프로젝트에서 타사 코드를 관리하는 데 특히 그렇습니다. 다행히도 Git의 서브 모듈 개념은 이러한 상황을 위해 설계되었습니다.

물론, 서브 모듈 만 그러한 문제에 대한 유일한 해결책은 아닙니다. 많은 현대 언어 및 프레임 워크에서 제공하는 다양한 "패키지 관리자"시스템을 사용할 수도 있습니다. 이 작업에 아무런 문제가 없습니다!

그러나 몇 가지 장점으로 Git의 하위 모듈 아키텍처를 생각할 수 있습니다.

아마도 패키지 관리자를 통해 모든 코드를 사용할 수있는 것은 아닙니다. 두 프로젝트간에 자신의 코드를 공유하고 싶을 수도 있습니다.이 경우 하위 모듈은 가장 쉬운 프로세스를 제공 할 수 있습니다.

git 하위 모듈의 본질

git 리포지토리를 자식 리포지토리로 만드는 유일한 것은 다른 parent

git 리포지토리 에 위치한다는 것입니다. 그 외에는 GIT 하위 모듈은 여전히 완전히 기능적인 저장소입니다. "정상적인"git 작업에서 이미 알고있는 모든 것을 수행 할 수 있습니다. 파일 수정에서 커밋, 당기고 밀고 푸시하는 것에 이르기까지. 하위 모듈의 모든 것이 가능합니다.

하위 모듈 추가

전형적인 예를 들어 보자. 프로젝트에 타사 라이브러리를 추가하고 싶다고 가정 해 봅시다. 코드를 얻기 전에 그러한 컨텐츠를 저장할 별도의 폴더를 만드는 것이 합리적입니다.

이제 우리는 순서대로 하위 모듈을 사용하여 프로젝트에 타사 코드를 가져올 준비가되었습니다. 작은 "시간대 변환기"JavaScript 라이브러리가 필요하다고 가정합니다.

우리 가이 명령을 실행할 때, git은 저장소를 우리 프로젝트에 서브 모드로 클론합니다 : 작업 카피 폴더를 보면 라이브러리 파일이 실제로 프로젝트에 도착했음을 알 수 있습니다. "차이점은 무엇입니까?" 주요 차이점은 자체 git 저장소에 포함되어 있다는 것입니다. 우리가 파일을 다운로드하고 프로젝트에 파일을 던지고 나머지 프로젝트와 같이 커밋하는 경우 동일한 GIT 저장소의 일부가 될 것입니다. 그러나 하위 모듈은 라이브러리 파일이 기본 프로젝트의 저장소에 "누출"되지 않도록합니다.

기본 프로젝트 루트 폴더에서 새로운 .gitModules 파일이 생성되었습니다. 다음은 내용입니다 :

<code class="language-bash">$ mkdir lib
$ cd lib</code>

이 .gitModules 파일은 GIT 추적 프로젝트의 서브 모듈에 대한 여러 위치 중 하나입니다. 다른 하나는 .git/config이며 이제 다음과 같이 끝납니다.

마지막으로, Git은 또한 각 하위 모듈의 .git 저장소 사본을 내부 .git/modules 폴더에 보관합니다.

이 모든 것은 기억할 필요가없는 기술적 세부 사항입니다. 그러나 GIT 서브 모듈의 내부 유지 보수가 상당히 복잡하다는 것을 이해하는 것이 도움이 될 수 있습니다. 그렇기 때문에 기억해야 할 것이 중요합니다. GIT 하위 모듈 구성을 수동으로 수정하지 마십시오! 하위 모듈을 이동, 삭제 또는 다른 방식으로 작동하려면 자신에게 호의를 베풀고 수동으로 시도하지 마십시오. "타워"와 같은 적절한 git 명령 또는 git 데스크톱 GUI를 사용할 수 있으며 이러한 세부 정보를 처리합니다.

<code class="language-bash">$ git submodule add https://github.com/spencermountain/spacetime.git</code>

하위 모듈을 추가 한 후 메인 프로젝트의 상태를 보자.

보시다시피, Git은 다른 변경과 동일한 변경 사항과 함께 하위 모듈을 추가하는 것을 취급합니다. 그래서 우리는 다른 변화와 마찬가지로이 변화를 저지해야합니다 :

GIT 하위 모듈이 포함 된 프로젝트를 복제하십시오 위의 예에서는 기존 git 저장소에 새로운 서브 모드를 추가했습니다. 그러나 "차례로" 하위 모드가 포함 된 저장소를 복제하면 어떻게됩니까?

우리는 명령 줄에서 일반적인 git clone & lt; 원격 URL; 이것은 다시 한 번 하위 모듈 파일이 독립적이며 부모 저장소에 포함되지 않았 음을 생생하게 증명합니다. Understanding and Working with Submodules in Git 이 경우, 상위 저장소를 복제 한 후 하위 모듈을 채우려면 단순히 GIT 하위 모듈 업데이트 (Init -Recursive를 수행 할 수 있습니다. 더 좋은 방법은 처음으로 Git 클론을 호출 할 때-Recurse-Submodules 옵션을 직접 추가하는 것입니다.

체크 아웃 버전

"정상 "git 저장소에서 일반적으로 분기를 확인합니다. GIT Checkout & lt; Branch Name & Git; Branch Name & Gt; 이 지점에서 새로운 커밋이 이루어지면 헤드 포인터는 자동으로

를 최신 커밋으로 이동합니다. git 서브 모듈이 다르게 작동하기 때문에 이것을 이해하는 것이 중요합니다!

<code>Cloning into 'carparts-website/lib/spacetime'...
remote: Enumerating objects: 7768, done.
remote: Counting objects: 100% (1066/1066), done.
remote: Compressing objects: 100% (445/445), done.
remote: Total 7768 (delta 615), reused 975 (delta 588), pack-reused 6702
Receiving objects: 100% (7768/7768), 4.02 MiB | 7.78 MiB/s, done.
Resolving deltas: 100% (5159/5159), done.</code>

서브 모듈에서 우리는 항상 지점이 아닌 특정 버전을 확인합니다! 백그라운드에서 하위 모듈에서 GIT 체크 아웃 메인과 유사한 명령을 실행하더라도 해당 분기의 현재 최신

커밋

는 지점 자체가 아닌 기록됩니다.

<code>[submodule "lib/spacetime"]
  path = lib/spacetime
  url = https://github.com/spencermountain/spacetime.git</code>

물론,이 행동은 실수가 아닙니다. 이것을 고려하십시오 : 타사 라이브러리를 포함하면 기본 프로젝트에서 사용하는 정확한 코드를 완전히 제어 할 수 있습니다. 라이브러리의 관리자가 새 버전을 출시 할 때 좋습니다. 그러나 프로젝트 에서이 새 버전을 자동으로 사용하고 싶지는 않습니다. 이러한 새로운 변경 사항이 프로젝트를 중단할지 모르기 때문입니다!

하위 모듈이 사용중인 버전을 찾으려면 기본 프로젝트 에서이 정보를 요청할 수 있습니다.

이것은 현재 Lib/Spacetime 서브 모드에서 체크 아웃 한 버전을 반환합니다. 또한이 버전은 "6.16.3"이라는 태그임을 알려줍니다. GIT 서브 모듈을 사용할 때 태그를 많이 사용하는 것이 일반적입니다.

하위 모듈이 "6.14.0"으로 표시된 이전 버전의

<code class="language-bash">$ mkdir lib
$ cd lib</code>

를 사용하기를 원한다고 가정 해 봅시다. 먼저, 우리는 주요 프로젝트가 아닌 서브 모드의 맥락에서 GIT 명령이 실행되도록 디렉토리를 변경해야합니다. 그런 다음 태그 이름으로 단순히 git 체크 아웃을 실행할 수 있습니다.

이제 우리가 메인 프로젝트로 돌아가서 GIT 하위 모듈 상태 상태를 다시 실행한다면, 우리는 체크 아웃을 볼 것입니다.

출력을 보러 오십시오 : SHA-1 해시 이전의 기호는 서브 모드 버전이 현재 상위 저장소에 저장된 버전과 다르다는 것을 알려줍니다. 체크 아웃 버전을 방금 변경 했으므로 이것은 정확해 보입니다.

우리의 주요 프로젝트에서 git 상태를 부르는 것은 이제 우리 에게이 사실을 알려줍니다. 당신은 git가 다른 변경 사항과 동일한 변경 사항과 동일한 변경 사항으로 이동하는 것을 취급한다는 것을 알 수 있습니다. 저장하려면 저장소에 커밋해야합니다.

git submodule

<code class="language-bash">$ git submodule add https://github.com/spencermountain/spacetime.git</code>

업데이트 위의 단계에서, 우리는 우리 자신이

하위 모듈 포인터를 옮겼습니다. 우리는 다른 버전을 체크 아웃하고 제출하여 팀의 원격 저장소로 푸시하는 사람들입니다. 그러나 우리 동료가 하위 모듈 버전을 변경했다면 어쩌면 흥미로운 새 버전의 하위 모듈 버전이 출시되었고 동료가 프로젝트에서이를 사용하기로 결정했기 때문에 (물론 철저한 테스트 후).

주 프로젝트에서 간단한 git 당김을 실행합시다 - 공유 원격 저장소에서 새로운 변경 사항을 얻기 위해 자주 할 수 있기 때문입니다.

<code>Cloning into 'carparts-website/lib/spacetime'...
remote: Enumerating objects: 7768, done.
remote: Counting objects: 100% (1066/1066), done.
remote: Compressing objects: 100% (445/445), done.
remote: Total 7768 (delta 615), reused 975 (delta 588), pack-reused 6702
Receiving objects: 100% (7768/7768), 4.02 MiB | 7.78 MiB/s, done.
Resolving deltas: 100% (5159/5159), done.</code>

두 번째 라인은 하위 모듈의 무언가가 변경되었음을 나타냅니다. 그러나 자세히 살펴 보겠습니다 :

나는 당신이 여전히 작은 수를 기억한다고 믿습니다. 이것은 하위 모듈 포인터가 움직 였다는 것을 의미합니다! 로컬 체크 아웃 버전을 팀원이 선택한 "공식"버전으로 업데이트하려면 업데이트 명령을 실행할 수 있습니다.

좋아요! 우리의 하위 모듈은 이제 주요 프로젝트 저장소에 기록 된 버전으로 확인됩니다!

<code>[submodule "lib/spacetime"]
  path = lib/spacetime
  url = https://github.com/spencermountain/spacetime.git</code>

git 서브 모드 사용 우리는 git 서브 모듈을 사용하여 기본 빌딩 블록을 덮었습니다. 다른 워크 플로우는 매우 표준입니다!

예를 들어, 서브 모듈의 새로운 변경 사항을 확인하는 것은 다른 Git 저장소에서와 같습니다. 하위 모듈 저장소에서 Git Fetch 명령을 실행하고 업데이트를 사용하려면 Git Pull Origin과 같은 것을 실행할 수 있습니다. 명령.

하위 모듈 변경은 특히 라이브러리 코드를 직접 관리하는 경우 (제 3자가 아닌 내부 라이브러리이기 때문에) 귀하에게도 효과가있을 수 있습니다. 다른 git 저장소와 마찬가지로 하위 모듈을 사용할 수 있습니다. 변경하고 커밋하고 밀어 넣을 수 있습니다.

<code>[submodule "lib/spacetime"]
  url = https://github.com/spencermountain/spacetime.git
  active = true</code>

git의 힘을 얻으십시오 git에는 무대 뒤에서 강력한 기능이 있습니다. 그러나 GIT 서브 모듈과 같은 많은 고급 도구는 잘 알려져 있지 않습니다. 많은 개발자들은 많은 강력한 기능을 놓쳤습니다.

다른 고급 GIT 기술을 더 깊이 파고 들으려면 "Advanced Git Toolkit"을 강력히 추천합니다. 이것은 (무료!) 짧은 비디오 컬렉션입니다. 선택 및 분기 전략.

더 나은 개발자를 기원합니다!

git 하위 모듈에 대한 자주 질문

git 하위 모듈이란 무엇입니까? git submodule은 다른 git 저장소를 자신의 git 저장소에 서브 디렉토리로 포함시키는 방법입니다. 주 프로젝트에서 별도의 저장소를 하위 프로젝트로 유지할 수 있습니다.

왜 git 하위 모듈을 사용합니까? git 서브 모듈은 외부 리포지토리를 프로젝트에 병합하는 데 유용합니다. 특히 개발 기록을 주요 프로젝트와 분리하려는 경우. 이는 종속성을 관리하거나 외부 라이브러리를 포함하는 데 매우 유리합니다.

하위 모듈에 관한 주요 프로젝트에 어떤 정보가 저장됩니까? 주요 프로젝트는 상위 저장소의 특별 항목에 URL을 저장하고 하위 모듈의 해시를 저지른 것입니다. 이를 통해 주요 프로젝트를 복제하는 사람은 참조 된 서브 모듈을 복제 할 수 있습니다.

서브 모듈을 포함하는 git 저장소를 복제하는 방법은 무엇입니까? 서브 모듈을 포함하는 저장소를 클로닝 할 때 -git 클론 명령의 -재수자 플래그를 사용하여 자동으로 초기화하고 복제 할 수 있습니다. 또는 클로닝 후 GIT 하위 모듈 업데이트를 사용할 수 있습니다.

하위 모듈을 둥지 할 수 있습니까? 예, GIT는 중첩 하위 모듈을지지하므로 서브 모듈에는 자체 서브 모듈이 포함될 수 있습니다. 그러나 중첩 하위 모듈을 관리하면 복잡해질 수 있으며 각 하위 모듈이 올바르게 초기화되고 업데이트되도록해야합니다.

위 내용은 git에서 서브 모듈을 이해하고 작업합니다의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

JavaScript 架构 switch 指针接口 github git

성명：

이전 기사：파이썬을 사용한 기계 학습의 프라이머다음 기사：파이썬을 사용한 기계 학습의 프라이머