💡 학습 개념 정의

• 핵심 키워드: HEAD, origin/main, git reset, git reflog, git push --force-with-lease, Protected branches, credential.helper
• 한 줄 정의: 로컬 브랜치를 과거 커밋으로 되돌리고(reset), 원격 히스토리를 로컬 상태로 덮어써서(force push) 테스트 커밋을 흔적 없이 정리하는 방법

📝 상세 학습 내용

1. 도입 배경 (Why?)

• GitLab에 첫 커밋을 올리는 과정에서 테스트 커밋 2개가 원격까지 push됨
• 혼자 쓰는 저장소라 원격 히스토리에서도 완전히 지우고 처음부터 깔끔하게 시작하고 싶었음
• 그 과정에서 push 인증 실패, 매번 뜨는 로그인 요청 문제도 함께 해결함

2. 핵심 원리 및 특징 (What?)

HEAD와 origin/main

• HEAD: 맨 꼭대기가 아니라 지금 내가 서 있는 위치를 가리키는 포인터
• main: 로컬 main 브랜치가 가리키는 커밋
• origin/main: 원격 main 자체가 아니라 마지막으로 fetch/pull/push했을 때 기억한 원격 위치
• origin/HEAD: 원격 저장소의 기본 브랜치 표시
• 세 표시가 한 커밋에 모여 있으면 로컬과 원격이 같다는 뜻

히스토리를 바꾸는 명령어 비교

reset 모드

• --soft: 커밋만 취소, 변경사항은 staged로 남음
• --mixed(기본): 커밋 취소, 변경사항은 수정된 파일로 남음
• --hard: 변경사항까지 버림 (단, 한 번도 add되지 않은 untracked 파일은 지우지 않음)

git reflog: HEAD 이동 기록

• HEAD가 움직인 모든 기록(clone, commit, amend, reset, checkout 등)을 로컬에 남김
• 아래에서 위로(과거 → 최신) 읽으면 내가 어떤 작업을 했는지 추적 가능
• push는 HEAD를 옮기지 않으므로 reflog에 남지 않음
• 브랜치에서 사라진 커밋(amend 전 커밋, reset으로 버린 커밋)도 해시가 남아 있어 복구 가능 → git의 "휴지통"

6b00b20 HEAD@{0}: reset: moving to 6b00b209...     ← 로컬만 되돌림
5795533 HEAD@{2}: commit (amend): ✨ [feat] d번째 커밋 ← 메시지 수정, 해시 변경 (이후 push)
dd89a8b HEAD@{3}: commit: ✨ [feat] 첫번째 커밋
596f2d0 HEAD@{4}: commit: 🎉 [start] 첫번째 커밋
6b00b20 HEAD@{5}: clone: from https://gitlab.com/...

일반 push vs 강제 push

• 일반 git push: 원격 커밋 위에 내 커밋을 추가(fast-forward) 하는 것만 허용
• 로컬이 원격보다 뒤에 있으면 rejected (non-fast-forward) 또는 아무 변화 없음
• 원격 히스토리를 로컬로 교체하려면 --force-with-lease가 필요함

GitLab 보호 브랜치 (Protected branches)

• 프로젝트 생성 시 기본 브랜치(main)가 자동으로 보호되어 강제 push가 금지됨
• 에러: You are not allowed to force push code to a protected branch / pre-receive hook declined
• 이 에러가 났다면 인증은 통과한 것이고, 서버 규칙 검사에서 거절된 것
• 해결: Settings → Repository → Protected branches(또는 Branch rules) → main의 Allowed to force push 켜기
• 작업이 끝나면 토글을 다시 꺼서 실수 방지

GitLab HTTPS 인증

• 계정 비밀번호가 아니라 Personal Access Token(PAT) 을 password 칸에 입력
• clone은 public 저장소면 인증 없이 되기 때문에, push에서 처음 인증 문제가 드러날 수 있음
• credential.helper가 없으면 인증 정보를 저장하지 않아 매번 입력을 요구함

3. 실제 활용 예시 (How?)

# 1. 로컬을 Initial commit으로 되돌리기
git reset --hard 6b00b209ed15a2073b54636658402e84b36f5ab1
 
# 2. 로컬/원격 전체 히스토리 확인 (git log는 HEAD 이전만 보여줌)
git log --oneline --all
 
# 3. (선택) 내가 어떤 작업을 했는지 기록 확인
git reflog -10
 
# 4. 원격을 로컬 상태로 덮어쓰기
git push --force-with-lease origin main
# → 보호 브랜치 에러 시 GitLab에서 Allowed to force push 켜고 재실행
# 성공 메시지: + 5795533...6b00b20 main -> main (forced update)
 
# 5. 성공 시 한 줄만 남음
# 6b00b20 (HEAD -> main, origin/main, origin/HEAD) Initial commit

🔍 심화 학습 (Deep Dive)

• Q. reset 했는데 왜 원격엔 테스트 커밋이 남아 있지?

  • A. reset은 로컬 브랜치만 옮김. 원격까지 바꾸려면 강제 push가 필요함

• Q. --force 대신 --force-with-lease를 쓰는 이유는?

  • A. 내가 모르는 사이 다른 사람이 원격에 push했다면 덮어쓰지 않고 멈춰주기 때문에 더 안전함

• Q. cherry-pick으로 커밋을 지울 수 있을까?

  • A. 불가능. cherry-pick은 커밋을 가져오는 기능이지 지우는 기능이 아님

• Q. GitLab 웹에서 커밋을 지울 수 있을까?

  • A. 삭제 버튼은 없음. 웹의 Revert는 되돌리는 커밋을 추가할 뿐이고, 웹만으로 하려면 임시 브랜치로 기본 브랜치를 바꾼 뒤 main을 삭제하고 원하는 커밋에서 다시 만들어야 함

• Q. 공유 브랜치에 강제 push해도 될까?

  • A. 실제 사용자가 나 혼자이고, 다른 기기/CI에 clone된 게 없다면 괜찮음. 팀원이 생기면 main은 보호 브랜치로 두고, 작업 브랜치에서 정리 후 MR의 Squash로 합치는 방식이 안전함

• Q. 강제 push하면 커밋이 서버에서 완전히 사라질까?

  • A. 브랜치 히스토리에선 안 보이지만 해시로 한동안 접근 가능할 수 있음. 토큰 같은 민감정보를 커밋했다면 반드시 해당 키를 폐기해야 함

• Q. push할 때 입력도 안 받고 바로 인증 실패하는 이유는?

  • A. 키체인에 빈 username/password가 저장돼 있었음. git credential fill로 확인하고 erase로 삭제 후 다시 입력하면 해결됨

• Q. 내가 어떤 명령어를 쳐서 이 상태가 됐는지 어떻게 알 수 있을까?

  • A. git reflog로 HEAD 이동 기록을 확인. 단, push는 기록되지 않으므로 origin/main의 위치로 push 시점을 추론함

• Q. reset 모드(soft/mixed/hard)는 reflog에서 알 수 있을까?

  • A. reflog엔 안 나옴. git status에 되돌린 커밋의 변경사항이 남아 있으면 soft/mixed, 없으면 hard

• Q. reset 후 그냥 git push 하면 원격도 되돌아갈까?

  • A. 안 됨. 일반 push는 커밋 추가만 허용하므로 원격 히스토리를 교체하려면 강제 push가 필요함

• Q. 강제 push가 pre-receive hook declined로 거절되는 이유는?

  • A. GitLab이 기본 브랜치를 보호 브랜치로 지정해 강제 push를 막기 때문. 설정에서 잠시 허용 후 다시 꺼두면 됨

📌 오늘의 핵심 요약

• HEAD는 "현재 위치", origin/main은 "마지막으로 기억한 원격 위치"
• 커밋 없애기는 reset, 옮기기는 rebase, 복사는 cherry-pick, 안전한 되돌리기는 revert
• 원격 히스토리까지 정리하려면 reset 후 git push --force-with-lease
• git reflog는 HEAD 이동 기록이자 git의 휴지통 (push는 기록되지 않음)
• GitLab main은 기본적으로 보호 브랜치라 강제 push 전 Allowed to force push를 켜고, 끝나면 다시 끄기
• 히스토리를 다시 쓰는 작업은 영향받는 사람이 없을 때만 하기
• GitLab HTTPS push는 PAT로 인증하고, credential.helper osxkeychain으로 저장하면 매번 입력하지 않아도 됨