[DEPLOY] 배포 후 백 머지 실행

[i-meant-to-be]

🚩 연관 이슈

#417, #418, #431

📝 작업 내용

핫픽스 배포에 따른 백 머지를 진행합니다.

백 머지란?

백 머지는 상위 브랜치를 하위 브랜치에 병합하는 것을 말합니다.

원래는 하위 브랜치(dev)에서 상위 브랜치(main)으로 향하는 게 일반적이나, 백 머지의 경우는 그 방향이 반대이기 때문에 백이라는 이름을 붙이게 됩니다. 이 저장소에서는 main > develop 방향의 머지가 백 머지입니다.

왜 필요한가?

main과 dev의 헤드가 일치하지 않기 때문입니다.

왜 일치하지 않게 되었는가? #418 PR 때문입니다. 고려대학교 FEDC의 템플릿 수정 요청을 신속히 반영하는 과정에서 develop 브랜치를 거치지 않고 바로 main 브랜치로의 병합을 진행했습니다. 즉, develop 브랜치는 main 브랜치에서 발생한 변경 사항을 전혀 모르는 상태입니다. develop 브랜치 역시 핫픽스 내용을 알 수 있게, 그리고 브랜치 헤드를 일치시켜 추후 배포를 진행할 때 충돌이 일어나지 않게, 백 머지를 통해 main 브랜치의 헤드를 develop 브랜치에 일치시켜 주는 것이 백 머지의 의의입니다.

‼️매우 중요한 안내 사항‼️

백 머지 시에는, 평소처럼 Squash commit이 아닌 Merge commit을 생성해줘야 합니다!

이 저장소에서는 feature 브랜치 > develop 브랜치로의 병합은 Squash commit으로 진행하고 있습니다. 그러나 이 경우, 정확히는 main 브랜치 > develop 브랜치로의 백 머지는 반드시 Merge commit으로 진행해주어야 합니다. 왜냐하면 백 머지의 목적은 동일한 Merge commit을 develop 브랜치와 main 브랜치의 공통 헤드로 둠으로써, 향후 발생할 수 있는 코드 손실이나 충돌을 방지하기 위함이기 때문입니다.

특히, main > develop 백 머지 시에 Squash를 사용하면, 기존 히스토리 연결 고리가 끊어지고 완전히 새로운, 공유되지 않은 단일 커밋이 생성되어 버립니다. 이렇게 되면 다음 배포 시 Git이 두 브랜치의 공통 조상을 찾지 못해 큰 충돌이 발생하게 됩니다. 따라서 두 브랜치의 히스토리 노드를 그대로 연결해 주는 Merge commit을 사용하여 안전하게 공통 헤드를 만들어 주어야 합니다.

🏞️ 스크린샷 (선택)

없음

🗣️ 리뷰 요구사항 (선택)

추후 다음 페이즈 진행할 시, 이와 관련하여 제가 다시 명확히 회의에서 설명을 드리도록 하겠습니다! 핫픽스 배포가 이번이 처음이었어서, 백 머지라는 개념 자체에 대해 팀이 논의할 기회가 없었던 것 같아요. 따라서 팀 내에서도 의견 공유를 해야 할 것 같습니다.

[gemini-code-assist]

Note

Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported.

[github-actions]

🚀 Preview 배포 완료!

환경	URL
Preview	열기
API	Dev 환경

PR이 닫히면 자동으로 정리됩니다.

[github-actions]

🧹 Preview 배포가 정리되었습니다.