🌲 Git 브랜치 꼬임 경험과 전략 정비 (feat. dev, main, PR)

이번에는 기능 구현보다도 Git 브랜치 히스토리가 꼬인 경험과 그걸 정리한 과정을 회고해보려고 한다. 협업하면서 누구나 한 번쯤 겪게 되는 상황이고, 같은 실수를 반복하지 않기 위해서..

❌ 상황: 브랜치가 얽히고 커밋이 반복되기 시작했다

Git 커밋 그래프를 보다가 아래와 같은 현상을 발견했다.

• 같은 커밋 메시지가 여러 번 등장 (put login folder into components folder)

• 오류 수정 커밋(correction error)이 중복

• 브랜치 간 merge 방향이 일관되지 않음 (main → COP-32, dev → main 등 다양하게 섞임)

• 그래프 선이 뒤엉켜 가독성이 떨어짐

당시에는 기능별로 브랜치를 나누고 머지를 진행했지만,
PR 대상 브랜치가 명확하지 않았고,
머지 후 정리 없이 새 작업을 이어가면서 히스토리가 복잡해졌다.

🔍 원인 분석

각자 다른 브랜치에서 작업하고, 서로 다른 기준 브랜치로 PR을 보냄

머지 후 커밋 정리를 하지 않아, 중복 커밋과 불필요한 수정이 쌓임

rebase가 아닌 merge만 사용해서 커밋 히스토리가 분기됨

브랜치 전략이 명확하지 않아 서로 다른 기준으로 작업

✅ 해결 전략: main 기준 PR → rebase → dev로 푸시

꼬인 브랜치를 정리한 뒤, 브랜치 전략을 아래와 같이 정리했다:

• COP 브랜치에서 작업

• 원격 main 브랜치로 PR 보내고 머지

• 로컬에서 main을 기준으로 rebase

• dev로 푸쉬

이 과정을 팀원들과 공유해서 앞으로는 dev 브랜치에 올릴 작업도 항상 main 기준으로 머지한 뒤, 그 결과를 가져와서 작업하도록 통일했다.

덕분에 충돌도 줄고, 그래프도 깔끔해지고, 리뷰도 훨씬 수월해졌다.

💡 회고

처음엔 그냥 merge만 해도 문제없다고 생각했는데, 팀원이 늘고 브랜치가 많아지면서 히스토리 관리가 중요하다는 걸 깨달았다.

커밋 메시지도 신경 써야 나중에 문제 발생 시 빠르게 추적할 수 있다.

PR 후에 또 rebase하고 push하는 게 비효율처럼 느껴졌지만, 실제로는 팀원들과 작업 내용을 main에서 안정적으로 리뷰하고, 이후 dev로 테스트용으로 반영하는 이중 구조였다.

덕분에 main은 깔끔한 기능 단위 히스토리, dev는 실제 화면 테스트용 스테이징 역할로 나뉘어, 충돌도 줄고 리뷰 속도도 훨씬 빨라졌다.

앞으로는 작업 시작 전에 항상 최신 브랜치로 rebase 하고 , PR 대상 브랜치를 명확하게 확인하고 작업할 것.

다음에는 rebase + squash를 더 적극적으로 활용해 커밋 히스토리를 한눈에 보기 좋게 정리하고 싶다.