머가필요해

최근 AI 에이전트를 이용하여 코딩 작업을 하면서

병렬로 동시에 여러 작업을 하는 경우에 유용한 기능으로 git worktree가 각광을 받고 있다.

git worktree가 어떤 기능을 제공해주는지

어떤 상황에서 필요로 하는지에 대해서 알아보고자 한다.

[ 준비 ]

실습을 해보기 위해서 저장소 하나를 clone 받아서 준비해보자.

[ 문제 상황 ]

feature-1 작업을 수행하기 위해 브랜치(branch)를 하나 생성해서 새로운 파일을 하나 만들었다고 해보자.

그런데, 갑자기 급하게 보안 이슈가 발생하여 hotfix 작업을 해야한다고 해보자.

feature-1 작업은 아직 진행 중이기에 commit까지 할 상황은 아니지만

지금까지 작업한 내용은 계속 보관을 하고 싶다고 하면 어떻게 해야할까?

[ 솔루션 #1 - new branch ]

그냥 다른 브랜치(branch)로 이동하면 되는 것 아닐까?

잠시 main 브랜치로 이동을 해보면 알겠지만,

feature-1 브랜치에서 작업하던 내용이 그대로 딸려온다.

여기에서 hot-fix-1 브랜치를 새로만들어도 마찬가지이다.

즉, 전에 작업하던 것을 잠시 치워놓고 다른 일을 할 수 있는 상황은 아니라는 것이다.

[ 솔루션 #2 - stash ]

이럴 때 가장 먼저 생각나는 방법은 `git stash` 명령어일 것이다(git 공부를 했다면 '이어야 한다'! ^^).

임시 보관이라는 말이 딱 어울리는 명령어이다.

변경 사항들을 모두 stash 명령어를 통해 따로 저장해놓으면,

현재 working directory는 깨끗해지게 된다.

`-u` 옵션은 추적하지 않는(untracked) 파일도 모두 stash 저장하라는 것이고,

`-m` 옵션은 stash 저장할 때 메모를 하도록 하기 위해 사용하는 것이다(여러 stash 저장 목록 구분을 위해).

이제 급한 hot-fix 업무를 처리한 후에

다시 돌아와서 전에 작업하던 내역을 불러와 계속 이어서 작업을 하면 되는 것이다.

그런데,

이렇게 좋은 stash 기능도 원하는 상황에 따라서는 충분하지 않을 수도 있다.

[ `새로운` 문제 상황 ]

`git stash` 기능이 정말 유용하긴 하지만,

만약 한 번에 하나의 작업이 아니라 동시에 여러 작업을 해야 한다고 하면 어떻게 해야할까?

앞서 말한 AI 에이전트가 동시에 여러 기능을 개발하도록 하고 싶은 경우,

여러 디렉토리에 각각 git clone 받아서 개발하도록 하면 될까?

그런데, 서로 개발 중인 내용을 주고 받는 것도 해야한다고 하면?

`stash`가 아니라 새로운 기능이 필요하다 !!!

[ 솔루션 #3 - worktree ]

현재 상태를 먼저 점검해보고, worktree를 사용해보자.

feature-1 브랜치에서 기존 파일 수정도 하고, 새로운 파일을 생성도 하던 중

긴급히 hot-fix를 진행해야 하는 상황에서 worktree를 사용하면 된다.

'git worktree add {디렉토리 경로} -b {새 브랜치 이름}` 형태로 사용하면 된다.

지정한 디렉토리 경로에 새로운 작업 공간을 마련하게 되기에

현재 디렉터리 하위 보다는 상위 경로로 지정해주는 것을 권장한다.

기존 branch를 사용할 때에는 `-b` 옵션을 사용하지 않아도 되지만

새로운 branch를 생성하도록 할 때에 `-b` 옵션을 사용하면 된다.

그런데, 여러 디렉토리에 각각 clone 받은 것과 어떤 차이가 있을까?

아래 예시를 자세히 살펴보자.

worktree로 생성된 hot-fix-1 작업 공간에서 새로운 작업을 하고 commit까지 했다.

`git log`를 통해서 당연히 새로운 commit까지 이력이 확인 된다.

그런데, 기존 디렉토리로 돌아가서 `git log`를 했는데 새로운 이력이 여기에서도 그대로 나온다.

그렇다!

worktree로 연결되어 있는 작업 공간끼리는 서로 공유 된다.

`git stash`로 잠시 저장해 놓은 이력들도 서로 공유하면서 이용할 수 있다.

삭제는 `git worktree remove {경로}` 명령어를 사용하면 된다.

AI 에이전트에서 이를 어떻게 활용하면 좋을지에 대해서는

각 AI 에이전트에 대해서 실습하면서 공부해보도록 하겠다.

저장소를 만든 후에 이름을 바꾸고 싶은 경우에 대해서 알아보자.

이번에도 저장소의 Settings 메뉴를 선택하면 된다.

제일 앞에 이름을 변경할 수 있는 부분이 보인다.

변경 후에 "Rename" 버튼만 누르면 된다.

끝났다 !!!

너무나 간단하다 !!!

GitHub에서 저장소 이름을 변경한다는 것은

저장소의 URL도 같이 변경된다는 것을 의미한다.

그러면, 저장소 이름을 변경하기 전에 이미 clone을 받은 사람은 어떻게 할까?

URL이 바뀌었기에 push, pull, fetch 등의 작업을 할 때 주소를 못찾게 된다 !

그렇기에 변경된 URL을 알려줘야만 한다.

바뀐 주소만 넣어주면 끝 !!! 😅

저장소를 생성했으면 삭제하는 방법도 알아보자.

삭제하고자 하는 저장소의 메뉴 중에서 Settings를 선택해보자.

제일 밑에 위치하고 있는 Delete this repository 부분을 찾으면 된다.

저장소를 삭제하면 복구가 안되기 때문에 뭔가 단계(절차)가 많다.

정말 삭제할 것이냐고 묻는다.

삭제하게 되면 어떤 일이 벌어지는 것인지 정말 이해하고 있냐고 묻는다.

그래도, 한 번 더 확인을 위해 번거롭지만 직접 저장소 이름을 타이핑하도록 하고 있다.

개인마다 상황이 다르겠지만, Passkey를 등록해놓은 경우 Passkey를 또 확인하고 있다.

이렇게 힘든 과정을 거쳐야지만 비로소 repository가 삭제 된다.

힘들다 !!! 😅

GitHub에서 저장소(repository)를 생성해보자.

Organization에서 repository를 생성하는 것과

개인 계정에서 repository를 생성하는 경우가 있지만,

repository를 생성하는 것은

생성되는 위치만 달라지는 것이지 모두 똑같은 repository를 생성하는 것이다.

하지만, 이렇게 생성되는 repository의 상태는 텅텅비어 있는 경우와 initial commit이 있는 경우로 구분될 수 있다.

아래와 같이 README 파일이나 .gitignore 파일을 모두 선택하지 않는 경우에는

initial commit 조차 없는 텅텅 비어 있는 repository로 만들어진다.

이후 어떻게 진행하면 된다고 친절하게 가이드 해주고 있다.

그대로 따라해보자.

브랜치(branch)와 관련된 부분은 가이드의 내용과 다르게 진행했는데,

기본 브랜치로 "main"으로 하라고 환경 설정을 하고 진행하는 방식으로 해봤다.

README 파일을 생성하도록 하거나 .gitignore 파일을 포함하도록 하는 경우를 살펴보자.

아래의 예시와 같이 둘 모두를 선택해도 동일하다.

이렇게 생성하면 README 파일, .gitignore 파일을 등록하는 initial commit이 실행되어

아래와 같이 생성되지 마자 저장소의 내용을 확인할 수 있다.

저장소 URL을 확인하고

저 주소로 git clone 받으면 된다.

정말 간단하지 않은가!? 😅