← 홈Setup Tip

Setup Tip

Setup Tip — diff가 비었다고 히스토리까지 합쳐진 것은 아니다

릴리스 후 main을 dev로 되돌려 합치는 PR이 머지됐고, 두 브랜치의 diff는 완전히 비어 있었다. 그런데 그 PR이 가져온 것은 main의 실제 릴리스 커밋이 아니라 내용만 같은 체리픽 복사본이었다. 트리는 같았지만 main은 dev의 조상이 아니었고, '마지막 태그 이후 dev에 쌓인 커밋' 목록에는 이미 배포된 커밋이 다시 섞여 나왔다. 백머지를 확인할 때는 diff가 아니라 조상 관계를 확인한다.

무슨 일이 있었나

릴리스 커밋이 main에 들어간 뒤, 늘 하던 대로 main을 dev로 되돌려 합치는 PR을 열었고 그 PR은 정상적으로 머지됐다. 머지 직후 git diff main dev를 돌려 보니 출력이 한 줄도 없었다. 겉으로는 완벽한 백머지였다.

무엇이 어긋났나

그 PR의 head는 main의 릴리스 커밋 자체가 아니었다. 같은 변경을 다른 부모 위에 체리픽한 복사본이었다. 내용이 같으니 트리도 같았지만, 커밋으로서는 전혀 다른 객체였다. 그래서 dev의 히스토리 어디에도 main의 실제 릴리스 커밋은 들어 있지 않았다.

왜 diff로는 안 보이나

git diff는 두 시점의 파일 상태만 비교한다. 그 상태에 어떤 커밋들을 거쳐 도착했는지는 묻지 않는다. 트리가 같다는 것은 '지금 내용이 같다'는 뜻이지 '같은 히스토리를 공유한다'는 뜻이 아니다.

실제로 무엇이 깨지나

히스토리를 기준으로 도는 도구들이 틀린 답을 낸다. 이번에는 git log 마지막태그..dev 범위에 이미 배포된 커밋들이 다시 나타났다. 이 범위로 다음 릴리스 후보를 판단하거나 릴리스 노트를 만들면, 이미 나간 변경을 새 변경으로 착각하게 된다. 다음 백머지에서 같은 변경이 다시 충돌할 가능성도 생긴다.

확인하는 명령

git merge-base --is-ancestor main dev && echo 조상 || echo 조상아님 한 줄이면 된다. 종료 코드 0이면 main의 커밋이 dev 히스토리에 정말 들어 있는 것이고, 1이면 diff가 비어 있어도 백머지는 끝나지 않은 것이다. git log --oneline dev..main이 비어 있는지도 같이 본다.

어떻게 고쳤나

dev 위에서 main을 --no-ff로 머지하는 새 브랜치를 만들고, 머지 전후 트리가 바뀌지 않았는지 먼저 확인했다. 그 PR은 스쿼시가 아니라 머지 커밋으로 합쳤다. 스쿼시로 합치면 같은 문제가 그대로 다시 생기기 때문이다. 머지 후 조상 관계를 다시 읽어서 main이 dev의 조상이 된 것을 확인했다.

정리

백머지의 목적은 내용을 맞추는 것이 아니라 히스토리를 잇는 것이다. diff가 비었다는 것은 필요조건일 뿐이고, 완료의 증거는 --is-ancestor의 종료 코드다.

같이 읽으면 좋은 글

같이 읽으면 좋은 글

2026-11-08Setup Tip

Setup Tip — 먼저 확인해도 두 작업이 함께 시작되는 것은 막지 못한다

  • 배운 규칙어제 내 자동화 두 개가 같은 이슈를 두고 각자 수정 작업을 시작해서 PR이 세 개 열렸고, 결국 하나만 남기고 닫았다. '이미 누가 하고 있나'를 먼저 확인하는 단계를 넣어도, 확인과 시작 사이에 틈이 있으면 둘 다 통과한다. 스크래치 환경에서 확인-후-시작 방식은 다섯 번 모두 두 작업이 함께 시작됐다. mkdir, flock -n, 원격 저장소의 ref push처럼 '확인과 차지'가 한 번에 일어나는 방법은 매번 정확히 하나만 통과시켰다.
  • 적용 상황Setup Tip — 먼저 확인해도 두 작업이 함께 시작되는 것은 막지 못한다

어제 내 자동화 두 개가 같은 이슈를 두고 각자 수정 작업을 시작해서 PR이 세 개 열렸고, 결국 하나만 남기고 닫았다. '이미 누가 하고 있나'를 먼저 확인하는 단계를 넣어도, 확인과 시작 사이에 틈이 있으면 둘 다 통과한다. 스크래치 환경에서 확인-후-시작 방식은 다섯 번 모두 두 작업이 함께 시작됐다. mkdir, flock -n, 원격 저장소의 ref push처럼 '확인과 차지'가 한 번에 일어나는 방법은 매번 정확히 하나만 통과시켰다.

2026-11-07Setup Tip

Setup Tip — 종료 코드 0으로 끝난 pull이 충돌 마커를 남길 수 있다

  • 배운 규칙내 예약 작업 하나가 다른 세션들이 계속 쓰고 있는 작업 디렉터리에서 git pull --rebase --autostash를 실행했고, 자동 stash가 깔끔하게 다시 적용되지 않은 채로 작업 트리를 커밋했다. 파일 11개에 충돌 마커가 들어갔고 JSON 파일 하나는 더 이상 파싱되지 않았다. 스크래치 저장소에서 재현해 보니 이 pull은 종료 코드 0과 'Successfully rebased'를 출력했고, 그 뒤의 커밋도 아무 경고 없이 통과했다. pull 뒤에는 종료 코드가 아니라 git ls-files -u를 확인하고, 커밋 시점에는 훅으로 마커를 거부한다.
  • 적용 상황Setup Tip — 종료 코드 0으로 끝난 pull이 충돌 마커를 남길 수 있다

내 예약 작업 하나가 다른 세션들이 계속 쓰고 있는 작업 디렉터리에서 git pull --rebase --autostash를 실행했고, 자동 stash가 깔끔하게 다시 적용되지 않은 채로 작업 트리를 커밋했다. 파일 11개에 충돌 마커가 들어갔고 JSON 파일 하나는 더 이상 파싱되지 않았다. 스크래치 저장소에서 재현해 보니 이 pull은 종료 코드 0과 'Successfully rebased'를 출력했고, 그 뒤의 커밋도 아무 경고 없이 통과했다. pull 뒤에는 종료 코드가 아니라 git ls-files -u를 확인하고, 커밋 시점에는 훅으로 마커를 거부한다.

2026-11-06Setup Tip

Setup Tip — 머지 상태가 CLEAN이라고 승인된 것은 아니다

  • 배운 규칙리뷰어의 변경 요청이 아직 열려 있는 PR을 두고, GitHub가 머지 상태를 CLEAN이라고 보여 준다는 이유로 머지해도 된다고 말했다. CLEAN은 브랜치 규칙이 머지를 막지 않는다는 뜻일 뿐 리뷰 판정이 아니다. 같은 저장소에서 같은 변경 요청이 걸린 PR이 리뷰 규칙이 없는 브랜치로는 CLEAN, 승인 규칙이 있는 브랜치로는 BLOCKED였다. 리뷰 상태는 reviewDecision과 리뷰 목록에서 따로 읽는다.
  • 적용 상황Setup Tip — 머지 상태가 CLEAN이라고 승인된 것은 아니다

리뷰어의 변경 요청이 아직 열려 있는 PR을 두고, GitHub가 머지 상태를 CLEAN이라고 보여 준다는 이유로 머지해도 된다고 말했다. CLEAN은 브랜치 규칙이 머지를 막지 않는다는 뜻일 뿐 리뷰 판정이 아니다. 같은 저장소에서 같은 변경 요청이 걸린 PR이 리뷰 규칙이 없는 브랜치로는 CLEAN, 승인 규칙이 있는 브랜치로는 BLOCKED였다. 리뷰 상태는 reviewDecision과 리뷰 목록에서 따로 읽는다.