배경

우선 우리의 브랜치 전략에 대해 먼저 설명해보자면.. 크게 3가지의 브랜치를 사용중이다.

• feat : feat/[이슈번호] 와 같이 큰 기능 이슈별로 dev 에서 따와 feat 브랜치를 만들어 사용 중이다.
• dev : 만든 feature를 main에 merge하기 전에 거쳐가는(?) 브랜치이다.
• main : 실제로 github action으로 서버에 배포가 일어나는 브랜치이다.

이렇게 총 3가지 브랜치를 사용해서 개발을 진행하고 있다.

• 사건의 진행상황(이라 쓰고 지난 날의 바보들..) 바보 같은 상황을 구경하고 싶다면 눌러주세요^_^

Squash and Merge

Squash and Merge는 merge가 되는 브랜치에 존재하는 모든 새로운 커밋을 하나로 묶은 새로운 커밋을 대상 브랜치에 추가해줍니다.

장점

• commit 이력이 하나로 합쳐지기 때문에 commit 이력이 깔끔해진다.

  (이 장점만 듣고 제대로 찾아보지 않았지..)

단점

• 브랜치를 한 번 merge한 다음부터는 해당 브랜치를 재사용하기 어렵다.

squash는 원래는 커밋을 합치는 기능이고 당연하게도 커밋을 어디부터 어디까지 합칠 것인지도 정할 수 있다. 하지만 github에 있는 Squash and Merge 도 당연히 하나의 브랜치를 다른 브랜치로 붙이는 것이기 때문에 브랜치의 모든 변경 사항을 squash 하는 행동을 하는 것이다.

즉, 처음 main 이 생기고 난 후 바로 dev 를 따서 작업을 한 후 dev -> main 으로 Squash and Merge 를 하게 되면 (중간에 dev 를 다시 따는 일이 일어나지 않는 이상) dev가 생기고 나서 발생한 모든 commit을 main과 관계 없이 그냥 계속 합치는 것이기에 당연하게도 첫 commit부터 들어가게 되는 것이다.

하지만 우리는 이것을 눈치채지 못하고 main의 최신 상태와 dev의 최신 상태를 비교해서 변경 사항만 squash 해주겠지라고 안일하게 생각을 했었다.(ㅠㅠㅠㅠ)