Git 설명: Git 서브 모듈을 사용하는 항목 낙하산 구조

일반적으로 개발팀은 Git 구조를 실현하여 프로젝트를 처리하는 데 필요한 다양한 부분에 대한 결정에 직면하게 된다.일부 팀은 monorepo를 선택하고 다른 팀은 이를 하위 프로젝트로 분해하기로 결정합니다. 예를 들어 UI용 저장소와 API용 저장소입니다.두 Git 구조 모두 장점과 단점이 있다.
Monorepos는 코드 공유, 더 적은 코드 중복, 단일 구축과 원자 제출 등 장점을 제공한다.그러나monorepos는 트리의 상관없는 부분의 대량 제출과 코드를 복제, 획득, 전송할 때의 잠재적 성능 문제를 처리한다.다른 한편, 유지보수 하위 프로젝트는 복제할 여러 개의 저장소, 설치와 구축, 그리고 따라야 할 여러 개의 디렉터리로 바뀌었다.
최근에 Git 서브 모듈을 사용하여 UI와 API 외부 저장소의 특정 커밋을 가리키는 중앙 낙하산 저장소를 만드는 것이 소개되었습니다.이런 낙하산 구조는 하위 프로젝트의 구성을 유지하고 모노르포를 사용하는 장점을 가진다. 예를 들어 하나의 중심 위치에서 문서와 설정을 관리하고 한 단계에서 전체 프로젝트(하위 프로젝트 포함)를 추진하는 능력이다.이 글은 benefits of using an umbrella repository structure using Git Submodules, struggles that come with itcommands that you need to learn to start using this Git structure을 토론할 것이다.

이점


하위 항목 구성.프로젝트의 다른 부분에 여러 개의 저장소를 제공하여 인코딩이 필요한 기초 위에서 제한된 접근 권한을 제공할 수 있습니다.예를 들어 UI 구현을 가속화하기 위해 몇 주 안에 프런트엔드 개발자를 팀에 추가하는 상황이 발생할 수 있습니다.개발자는 API를 방해하지 않고 UI 저장소만 추출하도록 쉽게 선택할 수 있습니다.
지속적으로 발전하다.Git 서브 모듈의 의안 낙하산 구조를 사용하여 하위 프로젝트 조합을 보존하고 모든 저장소가 자신의 배치 과정을 가질 수 있도록 한다.
서류를 한 곳에 두다.낙하산 저장소는 전체 프로젝트에 적용되는 문서를 한 위치에 저장할 수 있는 공간을 제공합니다.저는 개인적으로 낙하산 저장소에 전역 가격 인하 파일을 저장하는 것을 좋아합니다. 그 중에서 Docker을 사용하여 전체 프로젝트를 구축하고 운행하는 설명을 포함하고 모든 저장소에 가격 인하 파일을 저장합니다. 그 중에서 로컬에서 각 하위 프로젝트를 어떻게 설치하고 사용하는지에 대한 설명을 포함합니다.
한 위치에 배치합니다.우리 팀은 Docker 컨테이너를 사용하여 애플리케이션을 생성, 배포 및 실행합니다.낙하산 저장소는 docker-compose.yml 파일을 배치하는 가장 좋은 장소로 이 파일은 명령을 통해 데이터베이스 이미지,api와 ui 환경을 구축하고 실행합니다.
원자 코드 추출.낙하산 저장소를 복제할 때 --recurse-submodules 플래그를 사용하면 하나의 명령에서 하위 모듈을 포함하는 모든 중첩 디렉터리를 얻을 수 있습니다.즉, UI와 API 저장소를 동시에 사용할 수 있습니다.

투쟁


명령에서 Git 서브 모듈 사용을 지정해야 합니다.만약 당신의 팀이 이런 Git 구조에 익숙하지 않다면, 그들은 어떻게 그것들을 정확하게 복제하거나 처리하는지 모를 것이다.기본적으로 Git는 하위 모듈 컨텐트를 다운로드하지 않으므로 설명 파일에 이 정보를 포함해야 합니다.
하위 모듈 업데이트를 수동으로 검색합니다.Git는 하위 모듈의 업데이트를 자동으로 등록하지 않습니다.하위 모듈에 대한 변경 사항을 보려면 git submodule update --remote을 실행해야 합니다.
단순 구현만 가능합니다.지금까지 나는 이 낙하산 구조만 사용하여 각 항목의 UI와 API 저장소를 연결했다.두 개 이상의 하위 모듈이 얼마나 도전적인지 알 수 있습니다. 다른 실현을 연구해야 할 수도 있습니다.
Docker를 사용할 때 가장 유용합니다.만약 Docker를 사용하지 않았다면, 이러한 구조의 장점은 그렇게 큰 영향을 미치지 않았을 것입니다.

명령


공구 상자에서 이러한 낙하산 구조를 실현할 가능성과 명령에 대해 토론해 봅시다.
  • Create a project with submodules
  • Rename a submodule
  • Clone a project with submodules
  • Work in a submodule
  • Check and pull submodule updates
  • Update umbrella project with latest submodule commits
  • 하위 모듈이 포함된 항목 만들기


    이 조작을 명확하게 설명하기 위해서, 나는 GitHub에서umbrella라는 저장소와 두 개의umbrellaui와umbrellaapi라는 저장소를 만들 것이다.너는 here을 볼 수 있다.
    cd[umbrella-project-name]
    git submodule add [[email protected]:your-account/umbrella-ui.git] [name]
    

    Note: the name parameter is optional. If you don’t pass a name, you will get the submodule repository name. In this case, I will give it the “ui” name parameter because I don’t want a redundant directory name like “umbrella-ui” inside my “umbrella” project.

    ls -a 명령을 실행하여 ui이라는 새 디렉터리와 .gitmodules이라는 새 파일을 보십시오..gitmodules 파일은 주 프로젝트와 하위 모듈 간의 매핑을 저장하는 설정입니다.다음과 유사하게 보입니다.
    [submodule “ui”]
    path = ui
    url = [email protected]:your-account/umbrella-ui.git
    
    이 변경 사항을 제출하고 추진하면 하위 모듈의 폴더를 볼 수 있습니다. 이 폴더는 하위 모듈의 주요 지점에 있는 최신 제출을 가리킵니다.

    이름 바꾸기 모듈


    하위 모듈을 추가할 때 이름 매개 변수를 전달하는 것을 잊어버리면 다음 명령을 사용하여 하위 모듈 디렉터리 이름을 변경할 수 있습니다.
    git mv [old-name] [new-name]
    

    하위 모듈이 있는 항목 클론


    다음 명령을 실행하여 프로젝트와 하위 모듈을 자동으로 복제합니다.--recurse-submodules 플래그가 전달되지 않으면 디렉토리가 비어 있습니다.
    git clone --recurse-submodules [git-repo-url]
    

    하위 모듈에서 작업


    이것은 일반 저장소를 처리할 때 따르는 과정과 같다.너는 변화를 해서 제출하고 그것들을 원격으로 미뤄라.

    하위 모듈 업데이트 확인


    하위 모듈의 변경 사항이 원격 저장소로 전송될 때, 커밋 포인터가 만료되기 때문에 변경 사항을 확인하고 우산식 저장소를 업데이트해야 합니다.
    이 개념을 이해하실 수 있도록 umbrella-api 저장소를 보여 드리겠습니다. 업데이트되었습니다. 마스터의 마지막 제출은 6302c8…입니다.

    이제 낙하산 메모리 라이브러리를 살펴보겠습니다. api 서브 모듈은 umbrella-api의 최신 제출을 가리키지 않습니다.반대로 그것은 오래된 제출 15a146…을 가리킨다

    다음 명령을 사용하여 모든 하위 모듈의 변경 사항을 낙하산 디렉토리에서 직접 추출할 수 있습니다.
    // fetch all new updates in submodules
    git submodule update --remote
    
    // see which submodule has been modified
    git status
    

    // see all new commits that have been pulled down
    git diff
    

    최신 하위 모듈을 사용하여 낙하산 항목 업데이트 제출


    하위 모듈에서 변경을 한 이상 낙하산 항목 지침을 업데이트해야 합니다.만약 누군가가 이런 상태에서 우리의 우산형 프로젝트를 복제한다면, 그들은 우리의 하위 모듈 아래의 최신 코드를 얻을 수 없을 것이다.
    // add all submodules changes
    git add .
    
    // commit new pointers
    git commit -m “Update submodule pointers”
    
    // publish the changes
    git push origin master
    

    Note: You can also use the following shortcut to pull the latest changes made to your submodules and get your umbrella project to point to the last commits.


    git submodule update --remote --merge
    
    현재, 우리의 낙하산 프로젝트는 두 개의 하위 모듈 중의 최신 제출, 즉 낙하산 ui와 낙하산api를 가리킨다.

    이전에 유사한 낙하산 구조에서 Git 서브 모듈을 사용한 적이 있습니까?만약 없다면, 나는 그것이 너의 흥미를 불러일으키기를 바란다. 네가 한번 해 봐라.
    저의 Git 해석 시리즈를 읽고 좋아해 주시고 공유해 주셔서 감사합니다. 이것은 저에게 정말 큰 의미가 있습니다.나는 그것들을 함께 놓는 것을 좋아하고, 너의 문제와 건의를 좋아한다.
    다른 Git 설명 게시물을 보고 다음 게시물을 유의하십시오.저는 매주 토요일마다 Git 개념을 탐색하고 정의하며 해석합니다!

    좋은 웹페이지 즐겨찾기