G01 Thomas dot Git 자료의 범위
「Git 브랜치 생성 정리」의 4개 대화를 수업용으로 재구성했다.
브랜치 생성·삭제, kysong의 로컬·원격과 origin, Branch·Worktree 관계를 정리했다.
uc-anchor의 codex/*, staging, main과 Vercel Preview·Production을 연결했다.
대화에서 예시로 제시한 Worktree 폴더는 실제 폴더 구성으로 단정하지 않는다.
기존 2026-08-27 Git 핸드북도 비교하고 현재 공식 문서와 대조했다.


강사 설명: 주 근거 대화: 2026-11-09 「Git 브랜치 생성 정리」. 역사적 배포 상태와 이번 로컬 Git 확인 범위를 구분한다.
참고: https://chatgpt.com/c/6af151e4-aa58-83ee-b884-46e97f10a2af
https://git-scm.com/docs/gittutorial
https://git-scm.com/docs/git-worktree

G02 Git의 세 영역
파일 저장, 다음 commit 후보, 확정된 이력을 분리한다.
작업 폴더: 지금 수정 중인 파일.
스테이징 영역: 다음 commit에 포함할 변경.
로컬 저장소: commit으로 확정된 스냅샷과 이력.
git status -sb
git diff
git add README.md
git diff --staged
git commit -m "docs: explain local startup"

강사 설명: staging area는 Git의 인덱스다. staging 브랜치와 이름이 비슷하지만 다른 개념이다.
참고: https://git-scm.com/docs/gittutorial

G03 origin · main · origin/main
이름이 가리키는 위치를 먼저 찾는다.


이름 | 실제 의미 | 확인
main | 내 저장소의 로컬 브랜치 | git branch -vv
origin | 원격 저장소 주소의 별칭 | git remote -v
origin/main | 로컬에 저장된 원격 main 추적 참조 | git log origin/main
GitHub main | GitHub 서버의 브랜치 | GitHub의 브랜치·commit
HEAD | 현재 Worktree에서 체크아웃한 위치 | git status -sb
강사 설명: origin은 브랜치가 아니다. origin/main은 실시간 원격 조회가 아니다. fetch 등 통신으로 갱신한 추적 참조다. 서로 다른 Mac의 clone은 각각 독립된 로컬 저장소다.
참고: https://chatgpt.com/c/6af151e4-aa58-83ee-b884-46e97f10a2af
https://git-scm.com/docs/gittutorial

G04 push · fetch · pull
방향과 현재 파일 변경 여부를 함께 설명한다.

git status -sb
git fetch origin
git log --oneline --left-right main...origin/main
# < 로컬 main에만, > origin/main에만 존재
# main Worktree에서 상태 확인 후
git pull --ff-only origin main
명령 | 변하는 대상 | 현재 파일
push | 로컬 commit을 원격 브랜치로 전송 | 보통 변경 없음
fetch | 원격 객체와 추적 참조 갱신 | 변경 없음
pull | fetch 뒤 현재 브랜치에 통합 | 변경될 수 있음
pull --ff-only | 분기 이력 없이 앞으로 이동할 때만 통합 | 분기하면 멈춤
강사 설명: pull origin staging은 현재 브랜치에 원격 staging을 통합한다. 현재 폴더와 브랜치를 확인하지 않고 실행하지 않는다.
참고: https://git-scm.com/docs/gittutorial
https://chatgpt.com/c/6af151e4-aa58-83ee-b884-46e97f10a2af

G05 관찰 실습: Git 상태 변화
버튼을 눌러 파일 저장부터 fetch까지 달라지는 상태를 비교한다.
이 화면은 가상 이력 시뮬레이션이며 실제 Git 저장소를 변경하지 않는다.
원격 추가 commit 이후 fetch를 해도 로컬 파일은 그대로 남는다.


강사 설명: 
참고: https://git-scm.com/docs/gittutorial

G06 브랜치 생성과 작은 commit
검증된 기준점에서 한 목적의 변경을 만든다.
작업 변경을 보존한 뒤 기준 브랜치와 upstream을 확인한다.
git add . 대신 관련 파일을 골라 stage한다.
한 commit에는 한 목적을 담고 diff와 실행 결과를 남긴다.
git status -sb
git switch main
git pull --ff-only origin main
git switch -c codex/login-copy
# 안내 문구 한 곳 수정 후
git diff
git add README.md
git diff --staged
git commit -m "docs: clarify login setup"
git push -u origin codex/login-copy

강사 설명: staging에 이미 기능이 통합된 프로젝트는 기준을 staging으로 선택할 수 있다. 운영 hotfix는 main이 적절할 수 있으므로 작업 목적에 맞춰 정한다. 수업은 새 실습 저장소에서만 실행한다.
참고: https://chatgpt.com/c/6af151e4-aa58-83ee-b884-46e97f10a2af
https://git-scm.com/docs/gittutorial

G07 PR은 검토, merge는 이력 반영
commit·push·PR·merge·deploy는 다른 사건이다.
commit: 로컬 기록. push: 원격에 전달.
PR: base와 head의 diff·검증·대화를 모은 검토 요청.
merge: 선택한 방식으로 대상 브랜치에 이력을 반영.
deploy: 특정 소스를 빌드해 실행 환경에 배치.

확인 질문 | 필요한 증거
GitHub에 올라갔나? | 원격 브랜치와 commit
어디에 합쳤나? | PR base/head와 merged 상태
어떤 코드가 실행되나? | 배포 commit·환경·URL
기능이 정상인가? | 실제 사용자 시나리오와 데이터 대조
강사 설명: 
참고: https://docs.github.com/en/pull-requests/reference/pull-request-merges
https://vercel.com/docs/git

G08 세 가지 병합 방식
이력 모양과 SHA가 달라지는 이유를 설명한다.


방식 | 대상 브랜치에 남는 이력 | 정리 시 주의
Merge commit | 원래 commit과 명시적 병합 지점 | 전체 분기 이력 보존
Squash and merge | PR 변경을 새 commit 하나로 결합 | 원래 commit의 병합 판정과 다를 수 있음
Rebase and merge | commit을 대상 위에 다시 쌓음 | SHA 변경과 충돌 확인
강사 설명: 한 PR 한 목적이면 squash를 쉽게 사용할 수 있지만 실제 저장소 정책을 따른다. staging과 main에서 SHA가 다르다는 이유만으로 기능이 빠졌다고 판단하지 않고 diff·PR·실제 검증을 대조한다.
참고: https://docs.github.com/en/pull-requests/reference/pull-request-merges

G09 Branch와 Worktree의 관계
브랜치는 이력의 이름, Worktree는 실제 파일을 다루는 폴더다.



강사 설명: 각 Worktree는 자기 HEAD·index·미커밋 변경을 가진다. 객체와 대부분의 참조는 공유한다. 동일 로컬 브랜치를 보통 둘 이상의 Worktree에 동시에 checkout할 수 없다. 별도 폴더가 나중의 merge 충돌까지 제거하지는 않는다.
참고: https://git-scm.com/docs/git-worktree
https://chatgpt.com/c/6af151e4-aa58-83ee-b884-46e97f10a2af

G10 Worktree 생성·실행·점검
동시에 열어 둘 작업만 별도 폴더로 만든다.
예시 경로이며 실제 프로젝트 경로를 가정하지 않는다.
각 폴더의 의존성·.env.local·포트·연결 DB를 따로 확인한다.
git worktree list
git branch -avv
# main에서 새 브랜치와 폴더 생성
git worktree add -b codex/export ../course-export main
cd ../course-export
git status -sb
# lockfile에 맞게 설치 후 개발 서버 실행
# 두 서버를 함께 켜면 서로 다른 포트를 사용

강사 설명: 
참고: https://git-scm.com/docs/git-worktree

G11 Worktree를 여러 기기와 함께 쓸 때
한 Mac의 연결 폴더와 다른 Mac의 clone을 구분한다.
같은 로컬 저장소의 linked Worktree들은 객체와 참조를 공유한다.
Mac Studio와 MacBook은 보통 각각 clone하고 GitHub로 commit을 주고받는다.
환경변수·node_modules·Docker·DB 연결이 기기 사이에 자동 동기화되지 않는다.
같은 파일을 수정한 브랜치는 병합할 때 충돌할 수 있다.


강사 설명: 
참고: https://git-scm.com/docs/git-worktree
https://chatgpt.com/c/6af151e4-aa58-83ee-b884-46e97f10a2af

G12 staging 브랜치와 Preview 환경
staging은 Git 이름, Preview는 배포 환경 유형이다.


대상 | 역할 | 확인할 연결
codex/* | 기능 개발 브랜치 | 기능 PR과 필요시 Preview
staging | 기능 통합 검증 브랜치 | 고정 Preview 주소·검증 DB
main | 운영 반영 기준 브랜치 | Production 환경·운영 DB
Preview | 비운영 배포 환경 | 배포 commit·환경변수·접근 보호
강사 설명: 브랜치를 staging이라고 이름 붙여도 별도 Supabase DB가 자동으로 생기지 않는다. 같은 Preview 환경 안에서도 branch별 환경변수 설정을 확인한다. Vercel의 별도 custom environment는 계정 제공 범위를 확인할 선택 기능이다.
참고: https://vercel.com/docs/git
https://vercel.com/docs/environment-variables
https://chatgpt.com/c/6af151e4-aa58-83ee-b884-46e97f10a2af

G13 기능에서 운영까지의 검증 경로
통합 검증과 운영 반영을 명시적으로 나눈다.



강사 설명: 기능 PR은 필요에 따라 고유 Preview를 제공한다. staging 통합 뒤에도 main의 최신 변경과 합쳤을 때 생길 차이를 확인한다. 운영 반영 직전 검증한 내용이 보존됐는지 대조한다.
참고: https://chatgpt.com/c/6af151e4-aa58-83ee-b884-46e97f10a2af
https://vercel.com/docs/git

G14 uc-anchor PR #720과 #722
2026-11-09 Git 기록과 당시 배포 관찰을 구분한다.


단계 | 확인 기록 | 해석
기능 개발 | codex/performance-support-zip-staging-20261109 | 대화의 해당 배포 CANCELED
staging 병합 | PR #720 · fa3c95c6 | 로컬 Git에서 병합 기록 확인
main 병합 | PR #722 · f3b1228e | 로컬 Git에서 병합 기록 확인
배포 상태 | 대화에서 staging/main READY | 이번 작업의 라이브 재검증은 아님
강사 설명: 대화의 설명은 staging에서 검증한 ZIP 증빙 개선을 main 최신 코드에 반영한 사례다. 두 SHA를 같아야 하는 값으로 가르치지 않는다. 배포 READY도 파일 업로드·권한·메일 등 모든 기능의 통과를 뜻하지 않는다.
참고: https://chatgpt.com/c/6af151e4-aa58-83ee-b884-46e97f10a2af
https://github.com/SKY6174/uc-anchor/pull/720
https://github.com/SKY6174/uc-anchor/pull/722

G15 READY · CANCELED · SKIPPED · ERROR
배포 상태가 설명하는 범위를 읽는다.


상태 | 뜻 | 다음 확인
READY | 배포 준비가 끝남 | 실제 URL의 핵심 기능
CANCELED | 해당 배포가 취소됨 | 자동 취소·수동 취소 이유
SKIPPED / Ignored | 배포 또는 빌드가 생략됨 | 생략 조건과 필요한 검증 누락
ERROR | 배포 작업이 실패함 | 빌드·실행 로그와 환경
강사 설명: 취소된 배포가 있다는 사실만으로 브랜치가 삭제됐거나 기능이 실패했다고 단정하지 않는다.
참고: https://vercel.com/docs/git
https://chatgpt.com/c/6af151e4-aa58-83ee-b884-46e97f10a2af

G16 충돌을 만났을 때의 순서
삭제나 강제 동기화보다 현재 변경의 의미를 먼저 확인한다.
git status로 충돌 파일과 진행 중 작업을 확인한다.
충돌의 양쪽 의도와 필요한 변경을 읽는다.
파일을 해결한 뒤 stage하고 관련 검증을 다시 실행한다.
원래의 merge를 중단할 때만 git merge --abort를 사용한다.
git status
git diff --name-only --diff-filter=U
# 충돌 표시를 읽고 의미에 맞게 수정
git add README.md
git diff --staged
# 프로젝트의 관련 검사 실행 후 병합 완료

강사 설명: 수업에서는 새 연습 저장소의 README 두 줄로 충돌을 재현한다. 운영 저장소에 실습 충돌을 만들지 않는다. rebase 진행 중에는 merge용 명령을 섞지 않는다.
참고: https://git-scm.com/docs/git-merge

G17 복구 대상 세 가지
Git revert, 앱 배포 복구, DB 복구는 범위가 다르다.


대상 | 방법 예 | 되돌리지 못하는 것
공유 코드 이력 | git revert로 상쇄 commit | DB·서비스 설정·발송된 메일
실행 중 앱 | 이전 정상 배포로 복구 | 스키마·회원 기록
DB·Auth·설정 | 백업·호환 migration·별도 설정 복구 | 이미 외부로 전달된 결과
강사 설명: reflog는 로컬 위치를 찾는 도구이며 모든 기기와 원격의 영구 백업이 아니다. reset --hard와 force push는 이 수업의 기본 복구 실습에 사용하지 않는다.
참고: https://git-scm.com/docs/git-revert
https://vercel.com/docs/git

G18 병합 뒤 Worktree와 브랜치 정리
미커밋 변경·PR·원격과 보존 여부를 먼저 확인한다.
main과 staging은 유지하고 일회성 기능 작업을 정리한다.
Worktree 폴더를 일반 파일 삭제로 지우지 않고 worktree remove를 사용한다.
원격 삭제, 로컬 삭제, 추적 참조 정리는 각각 다른 동작이다.
git worktree list
git -C ../course-export status --short
# PR 병합과 변경 보존을 확인한 뒤
git worktree remove ../course-export
git branch -d codex/export
# 원격에 남았고 삭제할 대상이 맞을 때만
git push origin --delete codex/export
git fetch --prune

강사 설명: -d가 거절하면 중단하고 squash 병합과 미보존 commit을 확인한다. --merged main 목록은 reachability 기준이다. squash된 변경의 의미적 동등성까지 판정하지 않는다. fetch --prune은 원격에서 사라진 추적 참조를 정리하며 로컬 작업 브랜치를 삭제하지 않는다.
참고: https://git-scm.com/docs/git-worktree
https://docs.github.com/en/pull-requests/reference/pull-request-merges
https://chatgpt.com/c/6af151e4-aa58-83ee-b884-46e97f10a2af

G19 Git 30분 연습과 완료 기준
새 저장소에서 작은 문구 변경 하나를 끝까지 추적한다.
0~3분: 폴더·branch·remote·status 확인.
3~10분: 새 branch에서 README 한 곳 수정하고 diff 확인.
10~15분: 해당 파일 stage, staged diff, commit.
15~22분: 수업 원격 push와 PR base/head 확인.
22~27분: 별도 Worktree 목록·HEAD·설정 비교.
27~30분: commit·push·PR·merge·배포 차이를 말로 설명.


강사 설명: 
참고: https://chatgpt.com/c/6af151e4-aa58-83ee-b884-46e97f10a2af

G20 Git 질문 카드
다섯 질문에 답하면 상태를 설명할 수 있다.
commit했는데 GitHub에 안 보인다: 원격으로 push했는가?
push했는데 main에 없다: 어느 원격 브랜치로 보냈고 PR을 병합했는가?
origin/main이 오래됐다: 마지막 원격 통신과 fetch 결과는?
Preview는 정상인데 운영은 다르다: commit·환경변수·DB·callback이 같은 의도인가?
브랜치를 지워도 되나: PR·미커밋·Worktree·필요 변경의 보존을 확인했는가?


강사 설명: 
참고: https://chatgpt.com/c/6af151e4-aa58-83ee-b884-46e97f10a2af
https://git-scm.com/docs/gittutorial