일단 어그로까지는 아니지만 약간의 정정을 하자면,
예상했겠지만 브랜치가 진짜 아무 이유없이 갑자기 뿅 사라진 것은 아니었다.
그치만 내가 겪었던 브랜치 자동 삭제 이슈 상황을 그대로 마주한 사람들에게 도움이 될 수 있을 것 같아 이렇게 남겨본다.
문제 상황
기능 개발을 완료한 후 여느 때처럼, 작업한 feat/.. 브랜치를 GitHub에 push하고,
feat -> release -> dev 흐름으로 PR을 생성하고 merge까지 완료했다.
이때까지는 브랜치가 사라진 사실을 알아채지 못했다.
바로 다음 작업으로 버그를 잡고 또다시 PR을 생성한 후 release 브랜치로 머지를 하려는데 아무리 찾아도 base에 해당 브랜치가 보이지 않는 것이다. 혹시 내가 compare를 release로 설정했나 싶어서 확인하니까 역시 그건 아니었다 ㅋ,,
(레포에 기능 개발 브랜치가 많이 남아있는 상태이긴 했다. 정리를 한다고 했는데 어느 순간 보면 또 브랜치가 한가득 늘어나 있는 상황이었다.)
아무튼 이 많은 브랜치들을 뒤져도 release가 보이지 않자 내가 뭘 잘못 건드렸나 하는 불안감이 들 수밖에 없었다.
이전 PR 내역을 통해 release 브랜치에 접근하니까 404 Not Found 페이지가 뜨고, GitHub에서도 브랜치가 완전히 사라진 상태임을 확인할 수 있었다.
아무리 생각해 봐도 특이점이 전혀 없었다. 평소와 조금도 다를 것 없는 프로세스였는데 도대체 왜?
원인 분석
확인해보니 문제의 원인은 이 설정이었다.
GitHub 레포지토리 > Settings > General > Pull Requests
☑️ Automatically delete head branches
해당 설정이 활성화되어 있으면
PR이 머지되는 순간 해당 브랜치(= PR의 source 브랜치)가 자동으로 원격에서 삭제된다.
release -> dev 로 머지하면서 release 브랜치가 자동으로 삭제된 것이다.
앞서 이야기했듯 너무 많은 브랜치 때문에 .. PR 대상 브랜치를 찾을 때 문제가 되어 팀원분께서 해당 설정을 켜두었는데, 오랜만에 작업해서 이 사실을 모르고 있었다 🫠
해결 방법
삭제된 브랜치는 release 브랜치였고
로컬에는 존재하지 않았고, 원격 저장소(GitHub)에만 존재했던 브랜치였다.
방법 1: GitHub의 "Restore branch" 버튼
가장 쉬운 방법이다 :)
머지 후 브랜치가 자동으로 삭제되고 나면, PR 페이지 하단에 Restore branch 버튼이 보일 것이다.
이 버튼을 클릭하면 해당 브랜치를 한 번의 클릭으로 복구할 수 있다.
커밋 이력도 그대로 유지된다.
방법 2: 수동 복구
이 방법은 GitHub UI에서 Restore 버튼이 보이지 않을 때 사용할 수 있다.
release 브랜치가 머지된 커밋 해시를 기준으로 복원하는 방법이다.
# 1. 커밋 해시 찾기 (PR 머지 커밋)
git log --oneline --graph
# 2. 복원할 브랜치 생성
git checkout -b release <머지 커밋 해시>
git push origin release
단, 실수 방지를 위해 정확한 커밋 해시 확인이 필요하다.
그럼 브랜치 자동 삭제 옵션은 꺼두는 게 맞을까?
사실은 아래와 같은 이유들로 켜두는 게 일반적이라고 한다.
-
브랜치 정리 자동화를 통해 오래된 기능 브랜치를 수동으로 지우지 않아도 된다.
-
브랜치 목록이 넘쳐나는 걸 방지해 저장소를 깔끔하게 관리할 수 있다.
-
브랜치는 삭제되더라도, 머지된 커밋은
main이나dev에 그대로 남아 있어 이력은 안전하게 유지된다.
다만, release, hotfix처럼 재사용 가능성이 있는 브랜치는
머지 후 Restore branch 버튼을 눌러 다시 살려두는 프로세스를 갖추면 된다.
평소에는 자동 삭제를 켜두고, 필요한 브랜치만 복원하는 전략이 가장 효율적이다.
처음엔 "내 브랜치 어디갔어!" 라며 당황했지만, 알고 보니 GitHub의 자동 정리 기능 덕분이었다.
브랜치 전략과 GitHub 설정을 잘 이해하면, 협업도 더 깔끔하고 안전하게 할 수 있을 것이다.
모든 이들의 Git 저장소와 브랜치가 안전하길 바란다.(진심이다) 😊
