꼬인 깃 상태 되돌릴 명령어 받기

확인 질문 2개(수정 중인 파일도 함께 옮길지, 새 브랜치 이름)가 먼저 왔다. 원격 여부는 status 로 확인돼 묻지 않았고, 강제 푸시나 하드 리셋은 나오지 않았다.

git branch feature/x → 지금 위치를 가리키는 새 브랜치를 만듭니다. 파일은 바뀌지 않습니다. git reset --keep origin/main → main 을 원격과 같은 위치로 되돌립니다. 커밋 3개는 새 브랜치에 남습니다.

--keep 이 거부되면 먼저 stash 하라는 안내까지 붙었다.

git 명령어를 chatgpt 에 물을 때 가장 위험한 것은, 상태를 보여 주지 않은 채 "되돌려 줘" 라고만 하는 것입니다. AI는 가장 흔한 상황을 가정하고 답하는데, 그 가정에는 대개 강제 푸시나 하드 리셋이 들어 있습니다. 그대로 실행하면 아직 커밋하지 않은 수정이나 동료의 커밋이 조용히 사라집니다.

맥락 을 두 조각으로 나눠 넣은 이유가 여기 있습니다. 사람이 쓴 상황 설명은 틀릴 수 있습니다. "브랜치를 판 줄 알았다" 는 말 자체가 이미 착각이니까요. 반면 git status 결과는 사실입니다. 두 가지를 함께 주고 출력 형식 의 ①번에서 "제 말이 아니라 status 결과를 근거로" 다시 설명하게 하면, 착각이 먼저 걸러집니다.

되묻기 문단이 안전장치의 절반을 담당합니다. 원격에 올라갔는지, 다른 사람이 같은 브랜치를 쓰는지에 따라 안전한 명령이 완전히 달라지는데, 이 정보는 status 결과만으로는 알 수 없습니다. 질문을 먼저 받으면 위험한 명령을 추천받을 일이 크게 줄어듭니다.

제약 의 세 줄은 각각 다른 사고를 막습니다. 경고 요구는 커밋 취소하는 법을 찾다가 이력을 날리는 일을, 한 줄에 이어 붙이지 말라는 요구는 앞 명령이 실패했는데 뒤 명령이 실행되는 일을, "참고용 다른 방법을 덧붙이지 말라" 는 요구는 여러 방법 중 아무거나 골라 섞어 쓰는 일을 막습니다. 붙여 넣는 자료를 """ 로 감싼 것은 로그에 섞인 커밋 메시지가 지시로 읽히지 않게 하기 위해서입니다.

상태를 모르니 AI가 가장 일반적인 답, 즉 하드 리셋과 강제 푸시를 알려 줍니다. 커밋하지 않은 수정이 함께 날아가거나, 이미 원격에 올라간 커밋을 지워 동료의 저장소와 어긋납니다. 명령이 무엇을 바꾸는지 설명이 없어 실행한 뒤에도 무엇이 사라졌는지 모르고, 되돌리려고 또 검색한 명령을 치다 상태가 한 번 더 꼬입니다.