핫픽스가 왔는데 하던 일이 반쯤 열려 있다

목표

저장소 하나에 작업 디렉터리를 셋까지 붙였다 정리합니다. 끝나면 stash 없이 브랜치를
갈아타는 손이 생기고, 작업 사본이 남긴 관리 파일을 어떻게 치우는지 알게 됩니다.

왜 중요한가

브랜치를 바꾸는 일이 왜 이렇게 번거로운지 생각해 보면, 작업 트리가 하나뿐이기
때문입니다. 저장소는 객체와 브랜치 참조를 들고 있고, 작업 트리는 그중 한 커밋을 펼쳐
놓은 사본입니다. 펼쳐 놓는 자리를 늘릴 수 있다면 갈아타기 자체가 필요 없어집니다.
git worktree 가 정확히 그 일을 합니다. 다만 브랜치 참조는 저장소가 하나로 들고
있어서, 같은 브랜치를 두 자리에서 열려고 하면 git 이 막습니다. 이 제약을 이해하는
것이 이 실습의 절반입니다. 나머지 절반은 정리입니다 — 디렉터리만 지우면 관리 파일이
남고, 그 자리가 prunable 인 채로 계속 목록에 뜹니다.

단계

1. /root/gitx4/repo 에 커밋 3개짜리 저장소를 만들고 release 브랜치를 땁니다.
2. release 를 /root/gitx4/rel 에 작업 사본으로 붙입니다.
3. main 을 /root/gitx4/dup 에 한 번 더 붙여 보고, 거절 메시지를 notes/dup.txt 에 남깁니다.
4. repo 에 저장하지 않은 변경을 남겨 둔 채 /root/gitx4/hot 에 hotfix 브랜치를 새로
만들어 붙이고, 거기서 hotfix.txt 를 커밋합니다.
5. git worktree list --porcelain 을 notes/list.txt 로 남깁니다.
6. /root/gitx4/tmp 를 붙였다가 디렉터리만 rm -rf 하고, prunable 표시와 prune 결과를
notes/prune.txt 에 남깁니다.
7. /root/gitx4/usb 를 붙여 lock 을 걸고, remove 가 거절하는 것을 notes/lock.txt 에
남긴 뒤 풀어서 지웁니다.
8. notes/report.md 에 worktree · stash · clone 을 언제 쓰는지 정리합니다.

참고

• 이 이미지에는 git 신원이 전역으로 없습니다. 저장소를 만들면 git config user.email 과

git config user.name 을 그 저장소에 지정해야 커밋이 됩니다.

• 커밋 시각은 GIT_AUTHOR_DATE 와 GIT_COMMITTER_DATE 로 고정합니다. 채점이 시각에

흔들리지 않게 하려는 것이고, 실무에서도 재현 가능한 이력을 만들 때 쓰는 손입니다.

• 흔한 실수: 4단계에서 repo 의 변경을 git stash 나 커밋으로 치워 버리는 것입니다.

이 실습의 요점은 치우지 않고도 된다 는 쪽이라, 그대로 두어야 합니다.

• 흔한 실수: 6단계에서 git worktree remove 를 쓰는 것입니다. 거기서는 디렉터리를

rm -rf 로 먼저 없애고, 남은 관리 파일을 prune 이 치우는 흐름을 봐야 합니다.

단계 8개

1. 저장소와 릴리스 브랜치 만들기
2. 릴리스 브랜치를 두 번째 자리에 붙이기
3. 같은 브랜치를 두 자리에서 열 수 없는 이유
4. 저장하지 않은 변경을 그대로 두고 핫픽스
5. 지금 자리가 몇 개인지 기계가 읽는 형식으로
6. 디렉터리만 지우면 관리 파일이 남는다
7. 잠긴 자리는 remove 가 거절한다
8. 언제 자리를 늘리고 언제 밀어 넣는가