Trunk-Based..?

2024.09.11. 일 자 8시 경에 PR 올리다가 메인 브랜치가 여차저차하다가 터져버렸다. 선배님들이 도와주셔서 문제점을 찾을 수 있었다.

그냥 뭔가.. 잘못 쓰고 있었다!

1. 셋이서 Featrue/#n 으로 의미가 보이게 표시하지도 않은 채로 브랜치를 파고
2. 무진장 많은 작업을 한 뒤에
3. 한번에 PR후 메인에 머지하려니까
4. 펑! 터져버렸다.

선배님 말로는 메인에 머지하는게 아니라 서로서로 머지하고 쓰다가 메인에 올리려니까 터졌다고 하셨던 것 같다.

이번 일로 생각한 것은..

깃허브 공부를 하는 시간이 조금 필요할 것 같다.
그래서 선배님들이 알려주신 Trunk-Based-Development 전략을 공부하려고 여러 벨로그도 뒤져보고 티스토리도 찾아보며 배웠다.

Trunk-Based?

쉽게 말해서 하나의 일관된 코드 라인 ( Trunk 혹은 Master ) 에서 잦은 커밋과 병합을 하는 버전 관리 방법이다.
이 방식은 큰 기능 개발이나 수정 사항 등이 있을 때, 장기간 동안 분리된 브랜치에서 작업하는 대신에 짧게짧게 브랜치를 파서 작업하고 Trunk에 병합하는 것을 목표로 한다.

1. main 브랜치를 Trunk로 두고
2. 기능 개발이나 수정 시에 짧은 생명주기의 브랜치를 판다. ( 보통 하루나 삼일 정도 내 )
3. 개발이나 수정을 끝내고
4. PR 올려서 코드리뷰
5. main 브랜치에 머지

이거 무한반복하면 된다고 한다.

그래서 이거 왜 쓰는데?

1. 병합 시에 충돌이 적게 나서 고치기가 쉽다.
2. 작은 단위의 커밋은 코드 리뷰 하기 좋다.
3. main에 항상 배포 가능한 코드가 존재한다.

참고한 페이지들

https://velog.io/@freejak5520/Trunk-Based-Development
https://velog.io/@draco94/%ED%98%91%EC%97%85%EC%9D%84-%EC%9C%84%ED%95%9C-%EA%B9%83-Trunk-Based-Development-%EC%A0%84%EB%9E%B5