Git amend: 스테이지를 확인하고 마지막 커밋 수정
각 블록은 다른 경우이며 하나의 실행 스크립트가 아닙니다. 저장소에 맞는 경우를 선택하고 브랜치 이름, 경로와 VERIFIED_COMMIT을 바꾸세요. 중단 명령은 해당 작업이 진행 중일 때만 사용하며 두 대안을 모두 실행하지 마세요.
핵심 답변
commit --amend는 현재 끝을 새 커밋으로 바꾸며 원본 객체를 편집하지 않습니다. 스테이지를 검토한 뒤 로컬 마지막 커밋의 메시지나 내용을 고칩니다. 이미 공유했다면 추가 수정 커밋이 이력 재작성보다 조정하기 쉬운 경우가 많습니다.
예시와 전제 조건
예시는 메시지 오타와 src/parser.js의 누락된 변경이 있는 일반 로컬 커밋입니다. 메시지만 수정하거나 내용도 수정하는 것은 다릅니다. 과거 커밋, 첫 커밋이나 merge 예시가 아닙니다. 파일과 메시지를 실제 값으로 바꾸고 현재 끝에서 시작합니다.
변경 전에 상태 확인
status, 마지막 커밋과 diff --cached를 확인합니다. 일반 amend는 인덱스를 쓰므로 다른 작업의 스테이지 파일이 섞일 수 있습니다. 미스테이지 변경도 검토해 제외되는 것을 이해하세요. 원본이 push·통합되었거나 동료의 기준인지 확인한 뒤 ID를 바꿉니다.
git status --short
git log -1 --oneline
git diff --cached
git diff참조나 별도 체크아웃 보존
HEAD에 rescue/before-amend를 만들어 원본을 비교 가능하게 유지합니다. 모든 로컬 파일을 저장하는 것은 아니므로 필요한 편집은 별도 보관합니다. reflog는 남아 있는 예전 참조를 찾도록 도울 수 있지만 영구 객체 보관이나 미커밋 편집의 백업을 보장하지 않습니다.
git branch rescue/before-amend HEAD첫 번째 절차
메시지만 고칠 때 경로 없는 --amend --only는 기존 스테이지 변경을 제외합니다. -m은 수정 메시지입니다. 이후 커밋과 인덱스를 확인해 기존 스테이지 작업이 별도 커밋용으로 남았는지 봅니다. 인덱스도 포함하는 것은 amend를 쓰더라도 별도 절차입니다.
git commit --amend --only -m "Fix parser error message"
git diff --cached다른 결과를 의도적으로 선택
빠뜨린 파일은 해당 경로를 스테이지하고 전체 인덱스 diff를 읽은 뒤 --amend --no-edit로 메시지를 유지합니다. 다른 스테이지 파일도 명시적으로 제외하지 않으면 들어갑니다. 프로젝트 검사를 실행하세요. 특정 hunk 선택도 최종 결합 커밋의 정확성까지 보장하지는 않습니다.
git add -- src/parser.js
git diff --cached
git commit --amend --no-edit제한과 예외
공유한 끝에는 새 수정 커밋을 우선합니다. 바뀐 끝을 공개하려면 조정이 필요하고 보호 브랜치에서 금지될 수 있습니다. 일반 force push 명령은 제공하지 않습니다. 팀이 허용한 재작성은 lease, 브랜치와 협업자 검사를 포함한 별도 정책을 따르세요.
git add -- src/parser.js
git diff --cached
git commit -m "Correct parser handling"충돌과 정리
amend에는 보통 자체 충돌 계속 절차가 없습니다. hook 실패나 커밋 거부라면 메시지와 상태를 검토하며 reset --hard를 자동 실행하지 않습니다. 잘못된 내용은 먼저 rescue/before-amend와 비교하세요. 수정 reset 전에는 로컬 편집의 검증된 복사를 보존합니다.
결과 확인
두 커밋의 파일과 메시지를 비교합니다. ID 차이는 정상입니다. 메시지만 고쳤다면 트리는 같아야 하고 내용 수정은 의도한 패치만 달라야 합니다. 남은 스테이지 작업을 확인하고 검토한 대체 커밋이 원하는 이력에 안전하게 포함될 때까지 구조 참조를 유지하세요.
git show --stat HEAD
git diff rescue/before-amend HEAD
git status --short자주 묻는 질문
no-edit는 내용 변경을 막지 않습니다. 메시지를 유지할 뿐 스테이지 내용은 반영됩니다. 이전 커밋을 직접 amend하는 것은 아니며 별도 이력 편집이 필요합니다. push 후에는 명시적인 공유 이력 정책을 따르고 추가 수정 커밋을 고려하세요.
FluxGit에서 작업 검토
FluxGit의 시각적 이력과 변경 보기로 작업과 관련 커밋을 검토하세요. 이 예시의 브랜치, 공유 여부와 로컬 파일 검사를 유지합니다. 다운로드 페이지에서 현재 제공되는 빌드와 플랫폼을 확인할 수 있습니다.