git-worktree를 무엇에 사용합니까?

git-worktree에 대한 Github의 게시물을 읽었습니다 . 그들이 적다:

사용자가에서 feature긴급 버그를보고 할 때 이라는 지점의 Git 저장소에서 작업한다고 가정 해 보겠습니다 master. 먼저 새 브랜치를 사용하여 연결된 작업 트리를 만들고 hotfix[...] 마스터를 기준으로 체크 아웃합니다. 버그를 수정하고 핫픽스를 푸시하며 풀 요청을 만들 수 있습니다.

feature라는 지점에서 작업하고 마스터의 긴급 버그가보고되면 일반적으로 작업중인 모든 것을 숨기고 새 지점을 만듭니다. 완료되면 계속 작업 할 수 있습니다. 이것은 매우 간단한 모델입니다. 몇 년 동안 그런 식으로 일해 왔습니다.

반면에 git-worktree 사용에는 고유 한 제한이 있습니다.

예를 들어 하나의 작업 트리에서 커밋 된 변경 내용이 다른 작업 트리에서 커밋 된 변경 내용을 동기화 할 수 있기 때문에 동일한 분기가 연결된 두 개의 작업 트리에서 동시에 체크 아웃 할 수 없습니다.

이미 해결 된 문제에 대해 더 복잡한 워크 플로를 선택해야하는 이유는 무엇입니까?

git-worktree미리 할 수 ​​없었고이 완전히 새로운 복잡한 기능을 정당화 할 수 있는 어떤 것이 있습니까?

저에게 git worktree는 오랜 시간 동안 가장 크게 개선되었습니다. 엔터프라이즈 소프트웨어 개발을하고 있습니다. 3 년 전에 출시 한 것과 같은 이전 버전을 유지 관리하는 것이 매우 일반적입니다. 물론 각 버전마다 지점이 있으므로 쉽게 전환하고 버그를 수정할 수 있습니다. 그러나 그 동안 저장소를 완전히 재구성하고 시스템을 구축 할 수 있기 때문에 전환 비용이 많이 듭니다. 전환하면 IDE가 프로젝트 설정을 조정하려고 열광합니다.

작업 트리를 사용하면 지속적인 재구성을 피할 수 있습니다. 작업 트리를 사용하여 이전 폴더를 별도의 폴더로 체크 아웃하십시오. 각 지점마다 독립적 인 IDE 프로젝트가 있습니다.

물론 이것은 과거에 저장소를 여러 번 복제하여 수행 할 수 있었으며 지금까지 나의 접근 방식이었습니다. 그러나 그것은 또한 hardrive 공간을 낭비하고 저장소에서 동일한 변경 사항을 여러 번 가져와야한다는 것을 의미했습니다.

나는 이것에 대한 몇 가지 용도를 볼 수 있습니다.

장시간 실행되는 테스트 스위트가있는 경우 시간을 상상해보십시오. 테스트 스위트가 시작되면 테스트가 완료 될 때까지 해당 작업 사본을 효과적으로 차단합니다. 테스트 중에 분기를 전환하면 이해하기 어려운 방식으로 분기됩니다.

그래서 git-worktree다른 지점에서 작업을 수행하기 위해 두 번째 아이디어를 시작할 수있었습니다.

또한 빠른 조사를 위해 다른 지점으로 전환하면 IDE에서 많은 파일이 갑자기 변경되었다고 생각하고 모든 변경 사항을 인덱싱합니다. 다시 전환 할 때 다시 인덱싱해야합니다.

세 번째 사용 사례는 두 가지가 아닌 경우 두 디렉토리 사이에서 git-diffnormal과 같은 다른 도구를 사용하여 파일을 비교하는 것 diff입니다.

하나의 명백한 용도는 행동 을 동시에 비교하는 것 입니다 다른 버전 (예 : 웹 사이트의 다른 버전 또는 웹 페이지)의 (소스가 아님) 입니다.

나는 이것을 로컬로 시도했다.

• 디렉토리를 만듭니다 page1.

• 내부에 디렉토리 src와 디렉토리를 작성하십시오 git init.

• 에서 src생성 page1.html약간의 내용과 그것을 커밋합니다.

• $ git branch ver0

• $ git worktree add ../V0 ver0

• src마스터 에서 더 많은 텍스트를 추가 page1.html하고 커밋하십시오.

• $ git branch sty1

• 브랜치 page1.html에서 편집 하고 sty1(특이한 CSS 스타일을 추가하십시오) 커밋을 추가하십시오.

• $ git worktree add ../S1 sty1

이제 웹 브라우저를 사용하여이 3 가지 버전을 동시에 열고 볼 수 있습니다.

• ..\page1\src\page1.html // 현재 자식이 무엇이든

• ..\page1\V0\page1.html // 초기 버전

• ..\page1\S1\page1.html // 실험적으로 스타일이 지정된 버전

1. 파일 시스템에서 한 번에 여러 개의 작업 트리를 원하거나 필요로하는 합당한 이유가 있습니다.

   • 다른 곳에서 변경을 수행 하면서 체크 아웃 된 파일 조작 (예 : 컴파일 / 테스트)

   • 일반적인 diff 도구를 통해 파일을 diffing

   • 병합 충돌 중에 종종 파일의 충돌 을 해결 하면서 소스 측에서 소스 코드를 탐색하고 싶습니다 .

   • 많이 전환해야하는 경우 시간을 낭비하고 여러 워크 트리와 관련이 없는지 다시 확인하는 시간이 낭비됩니다.

   • git stashing을 통해 브랜치 사이의 정신 컨텍스트 전환의 정신 비용은 실제로 측정 할 수 없습니다. 어떤 사람들은 단순히 다른 디렉토리에서 파일을 열어서 존재하지 않는 정신적 비용이 있다는 것을 알고 있습니다.

2. 어떤 사람들은 "여러 개의 로컬 클론을 사용하지 않는 이유"를 묻습니다. "--local"플래그를 사용하면 추가 디스크 공간 사용에 대해 걱정할 필요가 없습니다. 이것 (또는 유사한 아이디어)은 내가 지금까지 한 일입니다. 로컬 클론에 비해 연결된 작업 트리의 기능적 이점은 다음과 같습니다.

   1. 로컬 클론을 사용하면 추가 작업 트리 (로컬 클론에 있음)는 단순히 오리진 또는 업스트림 브랜치에 액세스 할 수 없습니다. 클론의 '원점'은 첫 번째 클론의 '원점'과 동일하지 않습니다.

      • 달리기 git log @{u}..또는 git diff origin/feature/other-feature매우 도움이 될 수 있으며 더 이상 불가능하거나 어렵습니다. 이러한 아이디어는 다양한 워 크라운을 통해 로컬 클론으로 기술적으로 가능하지만 연결된 워크 트리를 통해 수행 할 수있는 모든 해결 방법이 더 좋고 간단합니다.

   2. 작업 트리간에 참조를 공유 할 수 있습니다. 다른 지역 지점의 변경 사항을 비교하거나 빌리려면 지금 할 수 있습니다.

tl; dr : 어떤 이유로 든 두 개의 작업 트리를 동시에 체크 아웃하려는 git-worktree경우 신속하고 공간 효율적인 방법입니다.

다른 작업 트리를 만들면 리포지토리의 대부분의 부분 (예 :) .git이 공유됩니다. 즉 , 하나의 작업 트리에있는 동안 분기를 만들거나 데이터를 가져 오면 가지고있는 다른 작업 트리에서도 액세스 할 수 있습니다. 당신이 그것을 복제하기 위해 어딘가에 밀어 넣지 않고 foo 브랜치에서 테스트 스위트를 실행하고 싶다면 repo를 로컬로 복제하는 번거 로움을 피하고 싶다고 가정 해보십시오 git-worktree. 임시 또는 영구적으로 별도의 장소. 복제와 마찬가지로 복제가 완료되면 삭제하면됩니다. 복제본에 대한 참조는 시간이 지나면 가비지 수집됩니다.

나는이 멋진 작업 트리가 무엇을 사용할 수 있는지 궁금해 한 후에이 질문에 걸려 들었습니다. 그 이후로 나는 그것들을 워크 플로에 통합했으며 초기 회의론에도 불구하고 그것들을 매우 유용하게 찾았습니다.

나는 다소 큰 코드베이스에서 작업하는데 컴파일하는 데 꽤 시간이 걸립니다. 일반적으로 현재 작업중인 기능 분기와 함께 현재 시스템에 현재 개발 분기가 있고 마스터 분기는 라이브 시스템의 현재 상태를 나타냅니다.

나에게 가장 큰 이점 중 하나는 분명히 분기를 전환 할 때마다 (즉, 작업 트리) 전체를 다시 컴파일 할 필요가 없다는 것입니다. 좋은 부작용은 개발 작업 트리로 가서 거기에서 작업을 수행하고 디렉토리를 현재 기능 분기의 작업 트리로 변경 한 다음 먼저 가져 오지 않고도 리베이스 할 수 있다는 것입니다.

나는 다소 특이한 것을 가지고있다 : 나는 같은 머신 에서 Windows와 Linux 개발을하고있다 . Windows 상자 안에 Linux를 실행하는 VirtualBox가 있습니다. VirtualBox는 일부 Windows 디렉토리를 마운트하고 Linux 시스템 내에서 직접 사용합니다. 이를 통해 Windows를 사용하여 파일을 관리하지만 Linux 내에서 빌드 할 수 있습니다. 이것은 크로스 플랫폼 프로젝트이므로 동일한 디렉토리 구조에서 Windows와 Linux 모두에서 빌드됩니다.

문제는 Linux와 Windows 빌드 시스템이 동일한 디렉토리에서 사용될 때 서로 충돌한다는 것입니다. 동일한 디렉토리 이름을 사용하는 라이브러리 등을 다운로드하기위한 복잡한 빌드 단계가 있습니다. 빌드 시스템의 Windows 버전은 Windows 특정 라이브러리를 다운로드하고 Linux 버전의 빌드 시스템은 Linux 특정 라이브러리를 다운로드합니다.

이상적인 세계에서, 빌드 시스템은 Windows와 Linux가 디렉토리 내에 공존 할 수 있도록 수정 될 것이지만, 현재는 문제가 워크 트리와 함께 해결되고 있습니다. "Linux"폴더는 Linux 특정 빌드 아티팩트를 생성 할 수 있고 "Windows"폴더는 Windows 특정 빌드 아티팩트를 생성 할 수 있습니다. 이것은 이상적인 솔루션은 아니지만 빌드 시스템 버그가 해결되기를 기다리는 동안 좋은 스톱 갭을 만듭니다.

분명히, worktree는 이것을 위해 설계되지 않았습니다. Windows 버전과 Linux 버전을 동일한 지점에 두는 것을 선호하지만 별도의 지점에 보관해야합니다. 아직도, 그것은 일을하고 있으며, 하루를 절약하는 다소 관습적인 작업 트리의 경우입니다.

나를 위해 새 프로젝트에서 기능을 만들었습니다. 그러나 일부 사양은 실패했습니다. 결과를 비교하기 master위해 work-treerepo를 만들었습니다 . 무엇이 잘못되었는지 이해할 때까지 실행 코드에서 단계별로 결과를 비교했습니다.

git worktree기계 학습 개발에 사용 하고 있습니다.

주요 기능 코드가 있고 다른 실험 (다른 알고리즘과 다른 하이퍼 매개 변수)의 분기를 나누고 싶습니다. 다른 알고리즘에 특화된 다른 버전의 코드와 함께 dvcgit worktree 를 통합 할 수 있습니다 . 모든 교육 작업을 실행 한 후 최종 메트릭을 평가하고 병합하여 최상의 지점 / 모델을 마스터합니다.