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

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

---

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

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

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

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

예를 들어, 하나의 작업 트리에서 커밋 된 변경 사항이 다른 작업 트리에서 커밋 된 변경 사항으로 인해 다른 작업 트리가 동기화되지 않도록하기 때문에 동일한 분기를 연결된 두 개의 작업 트리에서 동시에 체크 아웃 할 수 없습니다.

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

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

---

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

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

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

이제 유일하게 누락 된 부분은 Windows 용 공식 git 2.5 버전이지만 Windows 용 새로운 git 이 곧 출시 될 것이라는 희망이 있습니다 :-) (편집 : 지금 출시)

---

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

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

그래서 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경우 신속하고 공간 효율적인 방법입니다.

If you create another worktree, most parts of the repo (i.e. .git) will be shared, meaning if you create a branch or fetch data while you are in one work tree, it will also be accessible from any other work trees you have. Say you want to run your test suite on branch foo without having to push it somewhere to clone it, and you want to avoid the hassle of cloning your repo locally, using git-worktree is a nice way to create just a new checkout of some state in a separate place, either temporarily or permanently. Just like with a clone, all you need to do when you are done with it is delete it, and the reference to it will be garbage collected after some time.

---

I originally stumbled on this question after wondering what these fancy worktrees could be used for. Since then I have integrated them into my workflow and in spite of my initial scepticism I have come to find them quite useful.

I work on a rather large code-base, which takes quite some time to compile. I usually have the current development branch on my machine along with the feature branch I am currently working on plus the master branch, which represents the current state of the live system.

One of the biggest benefits for me is obviously that I don't have to recompile the entire thing everytime I switch branches (that is, worktrees). A nice side-effect is that I can go to the development worktree, do stuff there, change directory to the worktree for my current feature branch and then rebase it without having to pull first.

---

I've got a rather unusual one: I am doing Windows and Linux development on the same machine. I have a VirtualBox running Linux inside of my Windows box. The VirtualBox mounts some Windows directories and uses them directly inside of the Linux machine. This lets me use Windows to manage files but build within Linux. This is a cross-platform project, so it builds on both Windows and Linux from the same directory structure.

The problem is that the Linux and Windows build systems crash into each other when used in the same directory; there are some complicated build steps for downloading libraries, etc., that use the same directory names. The Windows version of the build system downloads the Windows-specific libraries, and the Linux version of the build system downloads the Linux-specific libraries.

In an ideal world, the build system would be modified so that Windows & Linux can co-exist within the directory, but for now, the problem is being addressed with worktrees. The "Linux" folder can generate Linux-specific build artifacts, and the "Windows" folder can generate Windows-specific build artifacts. While this is hardly an ideal solution, it makes a nice stopgap while waiting for the build system bugs to be addressed.

Admittedly, worktree wasn't designed for this; I have to keep the Windows version and the Linux version on separate branches, even though I'd really prefer them to be on the same branch. Still, it's doing the job, and is a somewhat unconventional case of worktree saving the day.

---

In new project for me, I've created a feature. But some specs failed. To compare results with master I created a work-tree repo. I compared results step by step in run code, until understand what went wrong.

---

I'm using git worktree for machine learning development.

I have a main functional code and then I want to split branches of different experiments (different algorithms and different hyperparameters). git worktree allows me to integrate dvc alongside different versions of my code specialized to different algorithms. After running all training jobs I evaluate final metrics and merge to master the best branch/model.

참고URL : https://stackoverflow.com/questions/31935776/what-would-i-use-git-worktree-for