지금까지는 이상적인 시나리오를 다뤘습니다: 코드를 작성하고, 커밋하고, Pull Request를 만들죠. 하지만 실제로는 자주 뭔가 잘못됩니다: 코드에 실수를 할 수도 있고, 잘못된 메시지로 커밋할 수도 있으며, 단순히 방향을 잘못 잡았다는 걸 나중에 깨달을 수도 있습니다. 이 강의에서는 가장 흔한 문제들을 어떻게 해결하는지 알아봅니다.
1. Rollback — 커밋 전 변경사항 되돌리기
시나리오: 파일을 수정했는데 모든 수정이 잘못되었음을 깨닫고, 마지막 커밋 이후 상태로 파일을 빠르게 되돌리고 싶습니다.
기능 Rollback을 사용하세요:
Commit탭을 엽니다.- 되돌리고 싶은 변경된 파일을 목록에서 찾습니다.
- 그 파일을 마우스 오른쪽 버튼으로 클릭하고
Rollback을 선택합니다.
IDE가 변경사항이 사라질 거라고 경고합니다. 동의하면 파일은 즉시 Git에 마지막으로 저장된 버전으로 돌아갑니다. 로컬 변경을 취소하는 가장 간단하고 안전한 방법입니다.
2. Reset — 로컬 커밋 삭제
시나리오: 하나 또는 여러 개의 커밋을 했지만 아직 push하지 않았습니다. 그 커밋들이 잘못됐다는 걸 깨닫고, 마치 없었던 것처럼 완전히 삭제하고 싶습니다.
기능 Reset을 사용하세요:
- 커밋 히스토리를 보려면
Git -> Log탭을 엽니다. - 있고자 하는 마지막 "정상" 커밋(오류 있는 커밋들 이전의 커밋)을 찾습니다.
- 그 커밋을 마우스 오른쪽 버튼으로 클릭하고
Reset Current Branch to Here...를 선택합니다.
열리는 창에서 리셋 모드를 선택하라고 합니다. 가장 급진적인 건 Hard입니다.
주의! Hard 모드는 선택한 커밋 이후의 모든 커밋과, 그 커밋들에 포함된 코드 변경사항들을 되돌릴 수 없이 삭제합니다. 매우 조심해서 사용하고, 아직 아무도 보지 않은(즉, GitHub에 보내지 않은) 커밋에만 사용하세요.
3. Push 후에 무엇을 할까?
시나리오: push를 했고, 그 뒤에 실수를 발견했습니다.
커밋이 원격 서버에 올라가면 프로젝트의 공통 이력의 일부가 됩니다. 이력을 다시 쓰려는 시도는 동료들에게 큰 문제를 일으킬 수 있습니다. 예를 들어, 그들이 이미 당신의 변경을 내려받아 그걸 기반으로 작업을 시작했을 수 있거든요.
올바르고 안전한 해결책:
문제를 수정하는 새로운 커밋을 만들고 푸시하세요. 이건 완전히 정상적인 관행입니다. 이렇게 하면 이력이 모두에게 솔직하고 명확하게 유지됩니다.
4. 과거 들여다보기: Log 고급 사용법
우리는 이미 Git -> Log 탭을 알고 있지만, 이건 단순한 커밋 목록이 아니라 조사용으로 강력한 도구입니다.
- 커밋 해시(Commit Hash): 로그에서
a1b2c3d같은 문자와 숫자 조합을 보셨을 겁니다. 이 해시는 고유하며 프로젝트 역사상의 어느 지점을 정확히 가리킬 수 있게 해줍니다. 보통 수동으로 직접 사용할 일은 드물지만, 이게 각 코드 "스냅샷"의 고유 식별자라는 걸 아는 게 중요합니다.![]()
- 브랜치, 작성자, 날짜 또는 심지어 커밋 메시지의 단어로 이력을 필터링할 수 있습니다. 특정 기능의 누가 언제 작업했는지 빠르게 찾는 데 도움이 됩니다.
- 특정 코드 줄이 추가되거나 삭제된 커밋을 찾고 싶나요?
Log창에는 메시지뿐 아니라 변경 내용 자체의 내용도 검색하는 검색 필드가 있습니다. - 코드 편집기 왼쪽 영역을 마우스 오른쪽 버튼으로 클릭하고
Annotate with Git Blame를 선택하세요. IDE가 각 줄 옆에 누가 어떤 커밋에서 마지막으로 변경했는지 보여줍니다. 왜 코드가 그렇게 작성됐는지 이해하는 데 엄청나게 유용합니다.
5. 위험 구역: Force Push
앞서 원격에 보낸 커밋을 변경하는 건 나쁜 생각이라고 했습니다. 하지만 로컬 이력을 바꿔서(예: Reset) 서버 이력과 달라졌다면 어떻게 될까요? 일반적인 push를 시도하면 Git이 오류를 내며 공통 이력을 덮어쓰지 않도록 보호합니다.
이럴 때 쓰는 옵션이 바로 force push(강제 푸시)입니다. 이 명령은 서버에게 "네가 가지고 있던 건 잊어. 내 로컬 이력이 유일하게 옳다. 네 이력을 내 것으로 교체해"라고 말하는 겁니다.
경고! 팀 프로젝트에서 force push를 사용하는 것은 99%의 경우에 재앙입니다. 이미 동료들이 내려받아 사용 중인 커밋들을 되돌릴 수 없이 삭제할 수 있습니다. 이는 공용 도서관 책에서 페이지를 뜯어내고 자신의 페이지로 바꿔 끼우는 것과 같습니다.
절대 force push를 사용하면 안 되는 경우:
- 공용 브랜치에서는:
main,develop,master. 절대 금지. - 여러 사람이 함께 작업하는 어떤 브랜치에서도 사용하면 안 됩니다.
허용되는 유일한 시나리오:
아직 아무도 보지 않은 개인 feature 브랜치에서 작업 중인 경우입니다. 더럽게 여러 커밋을 만들고 서버에 푸시한 뒤, 그걸 Reset으로 정리하고 싶다면, Pull Request 만들기 전에 자신의 브랜치를 업데이트하기 위해 force push를 사용할 수 있습니다.
IDE에서는 이 옵션이 보통 Push 버튼 안에 숨겨져 있습니다. IDE 제작자들이 실수로 누르지 않도록 일부러 그렇게 해놨습니다.
정확히 100% 확신이 서지 않는다면 절대 force push를 사용하지 마세요. 수정을 담은 새 커밋을 만드는 편이 훨씬 안전합니다.
6. 프로젝트 업데이트
새 과제를 시작하기 전에 항상 main 브랜치에서 Update Project를 누르세요. 그러면 많은 향후 머지 충돌을 피할 수 있고, 가장 최신 코드 버전에서 작업을 시작할 수 있습니다.
GO TO FULL VERSION