기술 · 실용 가이드
Git push가 non-fast-forward로 거절됐나요? 수정 전에 원격 ref를 증명하세요
거절은 그래프 안전 신호이지 강제 푸시 지시가 아닙니다. 정확한 대상 ref와 OID를 보존하고 감사 ref로 가져온 뒤 merge, rebase 또는 승인된 명시적 lease를 선택하세요.
non-fast-forward는 대상 브랜치가 제안 커밋의 조상이 아니라는 뜻입니다. 수락하면 원격 커밋 하나 이상이 브랜치의 보이는 기록에서 사라집니다. 먼저 정확한 대상 ref와 원격 tip을 보존해야 합니다.
폐기 가능한 로컬 실험에서 공통 기반 15c1b740f8f4, 원격 tip ff5235c58d12, 갈라진 로컬 tip 220186e6d9a6을 만들었습니다. 일반 push와 오래된 lease는 거절됐고, 관찰한 현재 OID에 명시적으로 묶은 승인된 테스트만 성공했습니다.
실험은 동작을 증명할 뿐 권한을 주지 않습니다. 팀 정책, 보호 규칙, PR 규칙과 원격 커밋의 의미가 통합 또는 재작성 여부를 결정합니다. lease는 보지 못한 변경을 보호하지만 기록 손실을 정당화하지 않습니다.
기록을 바꾸기 전에 대상을 확정하세요
remote URL, 현재 브랜치, upstream, push refspec과 refs/heads/main 같은 정확한 대상을 기록합니다.
ls-remote --heads로 OID와 시각을 저장합니다. 결과가 없으면 이름, 권한과 ref 종류를 확인하고 오래된 tracking ref로 대체하지 마세요.
관찰한 tip을 감사 ref로 가져오세요
전용 audit ref로 fetch하고 OID 일치를 확인한 뒤 양쪽 고유 커밋을 읽습니다. 배경 fetch가 origin/main을 바꿔도 증거는 남습니다.
merge-base --is-ancestor의 0은 원격 tip 포함, 0이 아니면 뒤처짐 또는 분기를 뜻합니다. 정책 선택 전에 양쪽을 검사하세요.
공유 기록을 보존해야 하면 통합하세요
저장소 정책에 따라 audit ref를 merge하거나 게시되지 않은 로컬 커밋만 rebase합니다. 충돌 해결, 테스트, 그래프 검토 뒤 일반 push를 합니다.
OID 기록 전 blind pull은 피하세요. 설정에 따라 merge 또는 rebase가 실행되어 증거보다 먼저 작업 브랜치를 바꿀 수 있습니다.
승인된 재작성에만 명시적 lease를 쓰세요
관리자 승인 뒤에만 --force-with-lease=refs/heads/main:<observed-oid>를 사용합니다. 실험에서 오래된 lease는 거절됐습니다.
push 뒤 대상을 다시 읽고 이전/새 OID, 승인과 이유를 기록합니다. lease 거절 시 자동 갱신하지 말고 검사를 다시 시작하세요.
