rebase 안전 절차
- 01`git fetch origin` — 원격 최신 상태 받기
- 02`git rebase origin/main` — main 기준으로 rebase
- 03충돌 발생 시 파일 수정 후 `git add <file>` → `git rebase --continue`
- 04완료 후 `git push --force-with-lease` 로 원격에 반영
git fetch origin && git rebase origin/mainGit 워크플로우
Git 워크플로우
Git 2.x 기준브랜치 전략, rebase, 머지 충돌 복구, 코드 리뷰 체크리스트를 단계별로 정리했다. Git에서 실수했을 때 따라하는 복구 절차 위주다.
절차별 체크리스트
단계별 Git 절차 모음
머지 충돌 복구
- 01`git status`로 충돌 파일 확인
- 02파일 열어서 `<<<<<<`, `======`, `>>>>>>` 마커 제거 후 원하는 내용으로 수정
- 03`git add <file>` — 수정 완료 표시 후 `git commit`
git status
# 충돌 파일 수정 후
git add . && git commit브랜치 전략 요약
- 01`main` — 배포 가능한 상태만 유지
- 02`feature/<이슈번호>-<설명>` — 기능 단위 브랜치
- 03PR 머지 후 기능 브랜치는 삭제
- 04hotfix는 `main`에서 분기 후 머지
git checkout -b feature/42-add-login실수 복구 시나리오
Git 실수별 복구 절차
recovery / 01
잘못된 `git reset --hard`
- symptom
- 커밋이 사라진 것처럼 보임.
- recover
- `git reflog`로 사라진 커밋 해시 찾기 → `git cherry-pick <hash>` 또는 `git reset --hard <hash>`로 복원.
복구 절차 보기
recovery / 02
실수로 force push
- symptom
- 팀원의 커밋이 원격에서 사라짐.
- recover
- 팀원의 로컬에 해당 커밋이 남아있으면 `git push origin <branch>` 로 복원 가능. `--force-with-lease` 를 습관화해 예방.
복구 절차 보기
recovery / 03
detached HEAD 상태
- symptom
- `HEAD detached at <hash>` — 브랜치 없이 특정 커밋에 있는 상태.
- recover
- 작업을 보존하려면 `git checkout -b <new-branch>`. 버리고 돌아가려면 `git switch -` 또는 `git checkout main`.
복구 절차 보기
recovery / 04
실수로 민감 정보 커밋
- symptom
- API 키, 비밀번호 등이 커밋 히스토리에 남은 경우.
- recover
- `git rebase -i` 로 해당 커밋을 수정하거나 `BFG Repo Cleaner`로 히스토리에서 제거. 노출된 키는 즉시 revoke한다.
복구 절차 보기
관련 데브로그 글
Git 관련 노트
아직 Git 관련 글이 없다. 데브로그 전체를 확인한다.
Git 워크플로우 자주 묻는 것들
자주 나오는 질문과 답
개인 기능 브랜치에서 main을 따라잡을 때는 rebase로 히스토리를 선형 유지. 팀원과 공유한 브랜치에서는 merge로 안전하게. force push가 필요한 rebase는 공유 브랜치에서 원칙적으로 금지다.