어떤 문제가 git subtree
해결됩니까? 이 기능을 언제, 왜 사용해야합니까?
나는 그것이 저장소 분리에 사용 된다는 것을 읽었습니다 . 그러나 관련되지 않은 두 개의 저장소를 하나로 묶는 대신 두 개의 독립적 인 저장소를 만들지 않는 이유는 무엇입니까?
이 GitHub 가이드 에서는 Git 하위 트리 병합을 수행하는 방법을 설명 합니다 .
나는 그것을 사용 하는 방법 을 알고 있지만 언제 (사용 사례), 왜 , 그리고 그것이 git submodule
. 다른 프로젝트 또는 라이브러리에 대한 종속성이있을 때 하위 모듈을 사용합니다.
답변
실제로 두 개의 별개이지만 관련 주제가 여기 에 있기 때문에 문맥에서 ‘하위 트리’ 라는 용어를 사용할 때 말하는 내용을 명시 적으로주의해야합니다 git
.
git-subtree 및 git 하위 트리 병합 전략 .
TL; DR
두 하위 트리 관련 개념을 사용하면 여러 저장소를 하나에서 효과적으로 관리 할 수 있습니다. 메타 데이터 만 루트 저장소에 .gitmodules 형식으로 저장되는 git-submodule 과 달리 외부 저장소를 별도로 관리해야합니다.
자세한 내용은
git 하위 트리 병합 전략 은 기본적으로 참조한 명령을 사용하는보다 수동적 인 방법입니다.
git-subtree 는보다 자연스러운 구문을 지원하는 래퍼 쉘 스크립트입니다. 이것은 실제로 여전히 일부이며 contrib
일반적인 man 페이지와 함께 git에 완전히 통합되지는 않았습니다. 문서는 대신 스크립트 측면을 따라 저장됩니다.
사용 정보는 다음과 같습니다.
NAME
----
git-subtree - Merge subtrees together and split repository into subtrees
SYNOPSIS
--------
[verse]
'git subtree' add -P <prefix> <commit>
'git subtree' add -P <prefix> <repository> <ref>
'git subtree' pull -P <prefix> <repository> <ref>
'git subtree' push -P <prefix> <repository> <ref>
'git subtree' merge -P <prefix> <commit>
'git subtree' split -P <prefix> [OPTIONS] [<commit>]
나는 내 자신의 블로그 게시물을 작성할 계획을 세우고 있었기 때문에 하위 트리 주제에 대해 꽤 많은 리소스를 발견했습니다. 내가 할 경우이 게시물을 업데이트 할 것이지만 지금은 당면한 질문과 관련된 몇 가지 정보가 있습니다.
많은 당신이 찾을 수 있습니다 추구하는 어떤 이 골드 피처 블로그 에 의해 니콜라 Paolucci 관련 섹션 아래 :
서브 모듈 대신 서브 트리를 사용하는 이유는 무엇입니까?
subtree
사용하는 것이 더 좋은 이유는 다음과 같습니다.
- 간단한 워크 플로우 관리가 쉽습니다.
- 의 이전 버전
git
이 지원됩니다 ( 이전 버전 포함v1.5.2
).- 하위 프로젝트의 코드는
clone
슈퍼 프로젝트가 완료된 직후에 사용할 수 있습니다 .subtree
저장소 사용자가 새로운 것을 배울 필요가 없으며subtree
종속성을 관리하는 데 사용하고 있다는 사실을 무시할 수 있습니다 .subtree
doessubmodules
(예
와 같은 새 메타 데이터 파일을 추가하지 않습니다.gitmodule
.- 모듈의 내용은 다른 곳에 종속성의 별도 리포지토리 복사본이 없어도 수정할 수 있습니다.
제 생각에는 단점이 허용됩니다.
- 새로운 병합 전략 (예 :)에 대해 배워야합니다
subtree
.upstream
하위 프로젝트에 대한 코드 기여 는 약간 더 복잡합니다.- 커밋에서 슈퍼 및 하위 프로젝트 코드를 혼합하지 않는 책임은 사용자에게 있습니다.
나는 이것의 많은 부분에도 동의 할 것이다. 일반적인 사용법에 대해 설명하는 기사를 확인하는 것이 좋습니다.
그가 여기 에이 접근 방식에서 생략 된 중요한 세부 사항을 언급하는 후속 작업을 작성했음을 알 수 있습니다 .
git-subtree
현재 리모컨을 포함하지 않습니다!
이 짧은 시력은 아마도 사람들이 종종 하위 트리를 다룰 때 수동으로 원격을 추가한다는 사실 때문일 수 있지만 이것은 git에도 저장되지 않습니다. 작성자는 git-subtree
이미 생성 된 커밋에이 메타 데이터를 추가하기 위해 작성한 패치를 자세히 설명합니다 . 이것이 공식 git 메인 라인이 될 때까지 커밋 메시지를 수정하거나 다른 커밋에 저장하여 비슷한 일을 할 수 있습니다.
또한 이 블로그 게시물도 매우 유익합니다. 저자는 그가 호출하는 세 번째 하위 트리 메서드를 git-stree
믹스에 추가합니다. 이 기사는 그가 세 가지 접근 방식을 비교하는 데 꽤 좋은 일을했기 때문에 읽을 가치가 있습니다. 그는 자신이하는 일과 싫어하는 일에 대한 개인적인 의견을 제시하고 왜 세 번째 접근 방식을 만들 었는지 설명합니다.
기타
마무리 생각
이 항목에서는 git
기능이 표시를 놓쳤을 때 발생할 수있는 세분화 의 힘 과 세분화를 모두 보여줍니다 .
나는 git-submodule
기여자들이 이해하기 더 헷갈 리기 때문에 개인적으로 혐오감을 쌓았다 . 또한 여러 저장소를 관리하지 않고도 쉽게 재현 가능한 환경을 용이하게하기 위해 프로젝트 내에서 모든 종속성을 관리 하는 것을 선호 합니다. git-submodule
그러나 현재는 훨씬 더 잘 알려져 있으므로이를인지하고 결정을 좌우할 수있는 청중에 따라 당연히 좋습니다.
답변
첫 번째 : 귀하의 질문은 강하게 의견이 많은 답변을받는 경향이 있으며 여기서 주제에서 벗어난 것으로 간주 될 수 있습니다. 그러나 나는 그 SO 정책을 좋아하지 않으며 주제에 대한 경계를 약간 바깥쪽으로 밀어 붙일 것이므로 대신 대답하고 다른 사람들도 그렇게하기를 바랍니다.
귀하가 지적한 GitHub 튜토리얼에는 장점 / 단점에 대한 관점을 제공하는 하위 트리 병합 전략을 사용하는 방법에 대한 링크 가 있습니다 .
하위 트리 병합과 하위 모듈 비교
사용의 장점 하위 트리 병합 이 있다는 것입니다 사용자로부터 적은 관리 부담이 필요 저장소의를. 그것은 나이와 함께 작동 (힘내 v1.5.2 전) 클라이언트 당신은 복제 후 코드 권리가 있습니다.
그러나 하위 모듈 을 사용하는 경우 하위 모듈 개체를 전송하지 않도록 선택할 수 있습니다 . 하위 트리 병합에 문제가있을 수 있습니다.
또한 다른 프로젝트 를 변경 한 경우 서브 모듈 만 사용하면 변경 사항을 제출 하는 것이 더 쉽습니다 .
위의 관점은 다음과 같습니다.
나는 종종 일반 git 사용자가 아닌 사람들 (= 커미터)과 함께 일하며, 일부는 여전히 버전 제어에 어려움을 겪습니다. 하위 모듈 병합 전략을 사용하는 방법에 대해 교육하는 것은 기본적으로 불가능합니다. 여기에는 병합, 분기 및 모든 것을 하나의 워크 플로로 혼합하는 것에 대한 추가 원격 개념이 포함됩니다. 업스트림에서 당기고 업스트림으로 밀어 올리는 것은 두 단계 프로세스입니다. 가지가 이해하기 어렵 기 때문에 이것은 모두 절망적입니다.
하위 모듈을 사용하면 여전히 너무 복잡 하지만 ( sigh ) 이해하기가 더 쉽습니다. 저장소 내의 저장소 (계층 구조에 익숙 함) 일 뿐이며 평소처럼 밀고 당기는 작업을 수행 할 수 있습니다.
간단한 래퍼 스크립트를 제공하는 것이 하위 모듈 워크 플로에 대해 더 쉽습니다.
많은 하위 저장소가있는 대형 수퍼 저장소의 경우 일부 하위 저장소의 데이터를 복제하지 않도록 선택하는 점은 하위 모듈의 중요한 이점입니다. 작업 요구 사항 및 디스크 공간 사용량에 따라이를 제한 할 수 있습니다.
액세스 제어가 다를 수 있습니다. 아직이 문제가 발생하지 않았지만 다른 리포지토리에 다른 액세스 제어가 필요하여 일부 사용자를 일부 하위 리포지토리에서 효과적으로 금지하는 경우 하위 모듈 방식으로 수행하는 것이 더 쉬운 지 궁금합니다.
개인적으로 나는 무엇을 사용해야할지 결정되지 않았습니다. 그래서 나는 당신의 혼란을 공유합니다 : o]
답변
git 하위 트리가 구원 인 실제 사용 사례 :
우리 회사의 주요 제품은 높은 모듈 식이며 별도의 저장소에서 여러 프로젝트로 개발되었습니다. 모든 모듈에는 별도의 로드맵이 있습니다. 전체 제품은 콘크리트 버전의 모든 모듈로 구성됩니다.
병행하여 전체 제품의 구체적인 버전은 각 고객에 맞게 사용자 정의됩니다 (각 모듈에 대한 개별 분기). 때때로 여러 프로젝트에서 한 번에 사용자 정의해야합니다 ( cross-module customization
).
맞춤형 제품에 대해 별도의 제품 수명주기 (유지 관리, 기능 분기)를 갖기 위해 git 하위 트리를 도입했습니다. 모든 사용자 정의 모듈에 대해 하나의 git-subtree 저장소가 있습니다. 우리의 커스터마이징은 모든 원본 리포지토리에서 커스터마이징 브랜치로 돌아가는 ‘git subtree push’입니다.
이렇게 우리는 많은 저장소와 많은 지점을 관리하지 않습니다. git-subtree는 생산성을 여러 번 향상 시켰습니다!
최신 정보
댓글에 게시 된 솔루션에 대한 자세한 내용 :
우리는 새로운 저장소를 만들었습니다. 그런 다음 클라이언트 분기가있는 각 프로젝트를 해당 새 저장소에 하위 트리로 추가했습니다. 마스터 변경 사항을 원래 리포지토리의 클라이언트 브랜치로 정기적으로 되 돌리는 젠킨스 작업이있었습니다. 우리는 기능 및 유지 관리 분기와 함께 tipical git 흐름을 사용하여 “클라이언트 저장소”로 작업했습니다.
우리의 ‘클라이언트’리포지토리도이 특정 클라이언트에 맞게 조정 한 스크립트를 작성했습니다.
그러나 제시된 솔루션의 함정이 있습니다.
제품의 주요 핵심 개발에서 점점 더 멀어짐에 따라 특정 클라이언트에 대한 가능한 업그레이드가 점점 더 어려워졌습니다. 우리의 경우에는 하위 트리가 이미 주 경로의 한 방법이되기 전의 프로젝트 상태가 괜찮 았으므로 하위 트리는 최소한 기본 git 흐름을 도입 할 수있는 순서와 가능성을 도입합니다.
답변
기본적으로 Git-subtree는 Git-submodule 접근 방식에 대한 대안입니다. 많은 단점이 있거나 오히려 git-submodules를 사용하는 동안 매우주의해야합니다. 예를 들어 “one”repo가 있고 “one”안에있는 경우 하위 모듈을 사용하여 “two”라는 또 다른 저장소를 추가했습니다. 주의해야 할 사항 :
-
“two”에서 무언가를 변경할 때 “two”내부에서 커밋하고 푸시해야합니다. 최상위 디렉토리 (즉, “one”)에 있으면 변경 사항이 강조 표시되지 않습니다.
-
알 수없는 사용자가 “하나”저장소를 복제하려고 할 때 “하나”를 복제 한 후 해당 사용자는 “2 개”저장소를 얻기 위해 하위 모듈을 업데이트해야합니다.
다음은 몇 가지 요점이며 더 나은 이해를 위해 다음 비디오를 시청하는 것이 좋습니다. https://www.youtube.com/watch?v=UQvXst5I41I
-
이러한 문제를 극복하기 위해 하위 트리 접근 방식이 발명되었습니다. git-subtree에 대한 기본 정보를 얻으려면 https://www.youtube.com/watch?v=t3Qhon7burE를 확인하세요.
-
하위 트리 접근 방식이 하위 모듈에 비해 더 안정적이고 실용적이라는 것을 알았습니다.
(저는 이런 말을하는 것이 매우 초보자입니다)
건배!
답변
위의 답변에 추가하려면 하위 트리 사용의 추가 단점은 하위 모듈과 비교하여 리포지토리 크기입니다.
실제 메트릭은 없지만 모듈에서 푸시가 수행 될 때마다 해당 모듈이 사용되는 모든 곳에서 상위 모듈에서 동일한 변경 사항의 복사본을 가져옵니다 (이후 해당 저장소에서 업데이트 될 때).
따라서 코드 기반이 크게 모듈화되어 있다면 상당히 빨리 추가 될 것입니다.
그러나 스토리지 가격이 항상 하락하고 있으므로 중요한 요소가 아닐 수 있습니다.