머지를 revert한 브랜치를 다시 머지했는데 변경이 하나도 안 들어온 이유

문제 발생

기능 브랜치를 main에 머지했다가 문제가 생겨 되돌렸습니다. 먼저 git revert가 거부했습니다.

error: commit 9f2c... is a merge but no -m option was given.
fatal: revert failed

-m 1을 주니 되돌아갔습니다. 며칠 뒤 브랜치를 고쳐 다시 머지했는데, 머지는 성공했다고 나오는데 파일에는 아무 변경도 없었습니다.

원인 분석

두 가지가 겹쳤습니다.

첫째, 머지 커밋에는 부모가 둘이라 "무엇을 되돌릴지"가 자명하지 않습니다. Git 문서 그대로 — 보통은 머지의 어느 쪽을 mainline으로 볼지 알 수 없어 머지를 revert할 수 없으며, 이 옵션이 부모 번호(1부터)를 지정해 그 부모를 기준으로 변경을 되돌리게 한다고 합니다. -m 1은 대개 머지를 받은 쪽(main)입니다.

둘째, 그 revert의 의미가 일회성 취소가 아닙니다. 문서가 분명히 경고합니다 — 머지 커밋을 revert한다는 것은 그 머지가 가져온 트리 변경을 앞으로도 절대 원하지 않는다는 선언이며, 그 결과 이후의 머지는 앞서 revert된 머지의 조상이 아닌 커밋이 만든 변경만 가져온다는 것입니다.

두 번째 머지가 조용했던 이유가 이것입니다. Git 입장에서 그 커밋들은 이미 머지된 이력이고, 되돌린 것은 나중에 만든 별개의 커밋입니다. 다시 머지해도 새로 가져올 커밋이 없습니다.

해결 방안

1. 부모 번호를 확인하고 revert합니다. 감으로 1을 넣지 않습니다.

git log -1 --pretty='%h %p %s' 9f2c...   # 두 번째 열이 부모들
git revert -m 1 9f2c...

2. 다시 넣을 때는 revert를 revert합니다. 가장 단순하고 이력에도 의도가 남습니다.

git revert <revert-커밋>   # 되돌림을 취소
git merge feature/x        # 이후 새 커밋들이 정상적으로 따라온다

3. 또는 브랜치를 새 커밋으로 다시 만듭니다. git rebase나 cherry-pick으로 같은 변경을 새 커밋 해시로 올리면 revert 판정과 무관해집니다. 이력이 지저분해지는 대신 판단이 단순합니다.

4. 머지 직후 잘못을 알았고 아직 push 전이라면 revert가 아닙니다. 그때는 git reset --hard ORIG_HEAD로 머지 자체를 없애는 편이 뒤탈이 없습니다. 이미 공유된 이력에는 쓰지 않습니다.

5. 이 판단을 커밋 메시지에 남깁니다. "왜 revert했고 다시 넣을 계획인지"가 없으면, 몇 주 뒤 조용한 머지 앞에서 같은 시간을 다시 씁니다.

공식 문서

• Git: git-revert — -m / --mainline
• Git How-To: Reverting a faulty merge