Thomas dot Git 상세 정리 · 별도 원문
본문의 관련 교시에서 연결한 선택 심화다. 각 항목 끝의 교시 링크로 발표와 교재에 돌아갈 수 있다.
목차와 처음으로 ↑Codex에서 시작해 GitHub에 기록하고, Supabase·Vercel·Resend와 SNS 인증을 연결하는 실습 중심 강의.
본문의 관련 교시에서 연결한 선택 심화다. 각 항목 끝의 교시 링크로 발표와 교재에 돌아갈 수 있다.
목차와 처음으로 ↑「Git 브랜치 생성 정리」의 4개 대화를 수업용으로 재구성했다.
주 근거 대화: 2026-11-09 「Git 브랜치 생성 정리」. 역사적 배포 상태와 이번 로컬 Git 확인 범위를 구분한다.
파일 저장, 다음 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 브랜치와 이름이 비슷하지만 다른 개념이다.
이름이 가리키는 위치를 먼저 찾는다.
| 이름 | 실제 의미 | 확인 |
|---|---|---|
| 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은 각각 독립된 로컬 저장소다.
방향과 현재 파일 변경 여부를 함께 설명한다.
| 명령 | 변하는 대상 | 현재 파일 |
|---|---|---|
| push | 로컬 commit을 원격 브랜치로 전송 | 보통 변경 없음 |
| fetch | 원격 객체와 추적 참조 갱신 | 변경 없음 |
| pull | fetch 뒤 현재 브랜치에 통합 | 변경될 수 있음 |
| pull --ff-only | 분기 이력 없이 앞으로 이동할 때만 통합 | 분기하면 멈춤 |
git status -sb
git fetch origin
git log --oneline --left-right main...origin/main
# < 로컬 main에만, > origin/main에만 존재
# main Worktree에서 상태 확인 후
git pull --ff-only origin mainpull origin staging은 현재 브랜치에 원격 staging을 통합한다. 현재 폴더와 브랜치를 확인하지 않고 실행하지 않는다.
버튼을 눌러 파일 저장부터 fetch까지 달라지는 상태를 비교한다.
| 단계 | 작업 파일 | 로컬 branch | 원격 branch | 추적 참조 |
|---|---|---|---|---|
| 기준 | A | A | A | A |
| 파일 수정 | 수정 중 | A | A | A |
| add | index에 선택 | A | A | A |
| commit | B | B | A | A |
| push | B | B | B | B |
| 다른 기기의 원격 변경 | B | B | C | B |
| fetch | B | B | C | C |
2일차 발표에서 Git 상태 변화 버튼 실습 ↗ (온라인 안내)
검증된 기준점에서 한 목적의 변경을 만든다.
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-copystaging에 이미 기능이 통합된 프로젝트는 기준을 staging으로 선택할 수 있다. 운영 hotfix는 main이 적절할 수 있으므로 작업 목적에 맞춰 정한다. 수업은 새 실습 저장소에서만 실행한다.
commit·push·PR·merge·deploy는 다른 사건이다.
| 확인 질문 | 필요한 증거 |
|---|---|
| GitHub에 올라갔나? | 원격 브랜치와 commit |
| 어디에 합쳤나? | PR base/head와 merged 상태 |
| 어떤 코드가 실행되나? | 배포 commit·환경·URL |
| 기능이 정상인가? | 실제 사용자 시나리오와 데이터 대조 |
이력 모양과 SHA가 달라지는 이유를 설명한다.
| 방식 | 대상 브랜치에 남는 이력 | 정리 시 주의 |
|---|---|---|
| Merge commit | 원래 commit과 명시적 병합 지점 | 전체 분기 이력 보존 |
| Squash and merge | PR 변경을 새 commit 하나로 결합 | 원래 commit의 병합 판정과 다를 수 있음 |
| Rebase and merge | commit을 대상 위에 다시 쌓음 | SHA 변경과 충돌 확인 |
한 PR 한 목적이면 squash를 쉽게 사용할 수 있지만 실제 저장소 정책을 따른다. staging과 main에서 SHA가 다르다는 이유만으로 기능이 빠졌다고 판단하지 않고 diff·PR·실제 검증을 대조한다.
브랜치는 이력의 이름, Worktree는 실제 파일을 다루는 폴더다.
commit 객체·브랜치·원격 참조
main · 운영 기준
codex/login · 로그인 변경
codex/export · 내보내기 변경
각 Worktree는 자기 HEAD·index·미커밋 변경을 가진다. 객체와 대부분의 참조는 공유한다. 동일 로컬 브랜치를 보통 둘 이상의 Worktree에 동시에 checkout할 수 없다. 별도 폴더가 나중의 merge 충돌까지 제거하지는 않는다.
동시에 열어 둘 작업만 별도 폴더로 만든다.
git worktree list
git branch -avv
# main에서 새 브랜치와 폴더 생성
git worktree add -b codex/export ../course-export main
cd ../course-export
git status -sb
# lockfile에 맞게 설치 후 개발 서버 실행
# 두 서버를 함께 켜면 서로 다른 포트를 사용새 수업용 저장소에서 Worktree 목록과 미커밋 변경을 먼저 읽어줘. main 기준 codex/export 브랜치와 별도 폴더를 제안해줘. 생성 후 각 폴더의 브랜치·HEAD·의존성·환경변수 이름·서버 포트를 확인해줘. 비밀값을 복사해 출력하지 말고 실제 코드 수정은 지정한 파일 한 곳으로 제한해줘.한 Mac의 연결 폴더와 다른 Mac의 clone을 구분한다.
staging은 Git 이름, Preview는 배포 환경 유형이다.
| 대상 | 역할 | 확인할 연결 |
|---|---|---|
| codex/* | 기능 개발 브랜치 | 기능 PR과 필요시 Preview |
| staging | 기능 통합 검증 브랜치 | 고정 Preview 주소·검증 DB |
| main | 운영 반영 기준 브랜치 | Production 환경·운영 DB |
| Preview | 비운영 배포 환경 | 배포 commit·환경변수·접근 보호 |
브랜치를 staging이라고 이름 붙여도 별도 Supabase DB가 자동으로 생기지 않는다. 같은 Preview 환경 안에서도 branch별 환경변수 설정을 확인한다. Vercel의 별도 custom environment는 계정 제공 범위를 확인할 선택 기능이다.
통합 검증과 운영 반영을 명시적으로 나눈다.
로컬 구현·검증
diff·검사·통합
기능·권한·회귀
검증 내용과 호환성
배포 commit 확인
로그인·저장·메일
기능 PR은 필요에 따라 고유 Preview를 제공한다. staging 통합 뒤에도 main의 최신 변경과 합쳤을 때 생길 차이를 확인한다. 운영 반영 직전 검증한 내용이 보존됐는지 대조한다.
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도 파일 업로드·권한·메일 등 모든 기능의 통과를 뜻하지 않는다.
배포 상태가 설명하는 범위를 읽는다.
| 상태 | 뜻 | 다음 확인 |
|---|---|---|
| READY | 배포 준비가 끝남 | 실제 URL의 핵심 기능 |
| CANCELED | 해당 배포가 취소됨 | 자동 취소·수동 취소 이유 |
| SKIPPED / Ignored | 배포 또는 빌드가 생략됨 | 생략 조건과 필요한 검증 누락 |
| ERROR | 배포 작업이 실패함 | 빌드·실행 로그와 환경 |
취소된 배포가 있다는 사실만으로 브랜치가 삭제됐거나 기능이 실패했다고 단정하지 않는다.
삭제나 강제 동기화보다 현재 변경의 의미를 먼저 확인한다.
git status
git diff --name-only --diff-filter=U
# 충돌 표시를 읽고 의미에 맞게 수정
git add README.md
git diff --staged
# 프로젝트의 관련 검사 실행 후 병합 완료수업에서는 새 연습 저장소의 README 두 줄로 충돌을 재현한다. 운영 저장소에 실습 충돌을 만들지 않는다. rebase 진행 중에는 merge용 명령을 섞지 않는다.
Git revert, 앱 배포 복구, DB 복구는 범위가 다르다.
| 대상 | 방법 예 | 되돌리지 못하는 것 |
|---|---|---|
| 공유 코드 이력 | git revert로 상쇄 commit | DB·서비스 설정·발송된 메일 |
| 실행 중 앱 | 이전 정상 배포로 복구 | 스키마·회원 기록 |
| DB·Auth·설정 | 백업·호환 migration·별도 설정 복구 | 이미 외부로 전달된 결과 |
reflog는 로컬 위치를 찾는 도구이며 모든 기기와 원격의 영구 백업이 아니다. reset --hard와 force push는 이 수업의 기본 복구 실습에 사용하지 않는다.
미커밋 변경·PR·원격과 보존 여부를 먼저 확인한다.
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은 원격에서 사라진 추적 참조를 정리하며 로컬 작업 브랜치를 삭제하지 않는다.
새 저장소에서 작은 문구 변경 하나를 끝까지 추적한다.
이번 Git 실습에서 수행한 단계와 수행하지 않은 단계를 표로 정리해줘. 각 단계의 폴더·브랜치·commit·remote·PR·Preview 증거를 연결해줘. 미완료를 성공으로 표현하지 말고, 다음에 확인할 명령 하나씩 제안해줘.다섯 질문에 답하면 상태를 설명할 수 있다.