기술 · 실용 가이드
Git rebase가 커밋을 건너뛰었나요? 다시 적용하기 전에 패치를 확인하세요
해시가 생략되어도 코드 손실의 증거는 아니다. 상위 동등 패치, 재적용 후 빈 커밋, 수동 skip과 GitHub 제한을 구분해야 한다.
Git이 이미 적용한 커밋을 건너뛰었다고 보고하면 실제 리베이스 대상 상위 브랜치와 변경을 비교하자. 기본 리베이스는 커밋 ID가 달라도 상위에 있는 동등한 깨끗한 cherry-pick을 생략할 수 있다. 이전 커밋 수를 복원하려고만 추가 플래그로 재실행하지 말자.
원래 팁, 대상 팁과 정확한 생략 패치로 증거를 정리한다. 로컬 Git과 GitHub PR 버튼은 별도 확인이며 경고만으로 호스팅 병합 제한의 원인을 진단할 수 없다.
작업을 기록하고 원래 팁 확인
전체 경고, 생략 ID, 원래 명령, Git 버전과 대상 브랜치를 보관한다. `git status`로 리베이스 진행 여부를 확인하자. 이미 적용된 자동 생략, 재적용 후 빈 커밋, 충돌 커밋 수동 skip은 별도 사건이므로 모두 커밋 손실로 부르지 말고 실제 단계를 기록한다.
완료 후 `git reflog show --date=iso YOUR_BRANCH`에서 YOUR_BRANCH를 실제 이름으로 바꿔 작업 순서로 원래 팁을 찾는다. 특정 reflog 번호가 항상 맞는다고 생각하지 말고 정확한 이전·대상 해시를 기록한다. reflog는 로컬 기록이며 만료될 수 있다. 원래 객체가 없다면 멈추고 다른 보존 자료를 찾자.
올바른 상위 대상에 대해 패치 비교
기록한 해시로 `git cherry -v UPSTREAM_HASH OLD_TIP_HASH`를 실행한다. 빼기 표시는 상위에 동등한 패치가 있고 더하기는 없다는 뜻이다. Git 문서의 비교는 공백과 줄 번호를 제거하며 메시지나 이전 ID 일치 검사가 아니다. 생략 패치 자체도 읽자. 표시는 동등성 증거이며 모든 의도한 결과의 보장은 아니다.
명령은 커밋된 패치만 검사하며 미커밋 편집은 포함하지 않는다. 이후 커밋이 변경을 되돌렸는지도 증명하지 못한다. 파일과 기대 동작을 확인하자. 격리 Git 2.51.1 합성 예제에서 cherry-pick 기능은 빼기로 표시되어 리베이스에서 생략되지만 최종 파일에 남았고 별도 미일치 커밋도 유지됐다. 독자의 저장소 시험 결과는 아니다.
시리즈를 비교한 뒤 재적용 판단
완료 작업의 베이스·팁이 알려지면 `git range-diff OLD_BASE_HASH..OLD_TIP_HASH NEW_BASE_HASH..NEW_TIP_HASH`의 네 자리표시자를 실제 해시로 바꿔 확인한다. 미일치·변경 항목을 상위 패치 비교와 함께 읽는다. 새 토픽 범위에 없는 패치가 새 베이스에 있을 수 있어 부재만으로 손실을 판단할 수 없다. range-diff는 사람이 읽는 비교이며 복구 명령이나 안정된 기계 검증 형식이 아니다.
`--reapply-cherry-picks`는 깨끗한 상위 동등 패치의 사전 생략을 바꾼다. 재적용해도 빈 커밋이 될 수 있으며 `--empty`가 그 단계를 제어한다. 둘 다 빠진 동작 복구를 보장하지 않는다. 실제 누락이면 현재 작업을 보존하고 의도한 이력에 합의한 뒤 복구하자. 재리베이스, hard reset이나 force push를 진단으로 사용하지 말자.
GitHub 버튼은 별도 분기
로컬 성공에도 GitHub가 Rebase and merge를 거부하면 PR의 베이스·헤드 해시, 커밋 수와 정확한 메시지를 기록한다. 현재 공식 문서는 이 방법을 100개 커밋까지 제한한다. 초과는 별도 확인 가능한 조건이지만 이하라고 다른 병합 조건이 충족된 증거는 아니다. 생략 경고가 호스팅 거부 원인이라고 단정하지 말자.
모든 의도한 변경이 상위에 존재, 의도적 제거 또는 검토된 복구 필요 중 하나로 설명되어야 한다. 최종 파일과 프로젝트 검증 후 허용된 병합 정책으로 호스팅 제한을 처리한다. 이전·새 팁, 명령, 생략 ID, 패치 비교와 미해결 변경을 관리자에게 남기자. 안내를 숨기거나 커밋 수를 되돌리는 것은 검증이 아니다.
