ADR‐003: 브랜치 전략 - Moadong/moadong GitHub Wiki

작성일: 2025-11-17 | 상태: Accepted
결정일자: 2025-01-12

[문제 상황 설명]

모노레포 방식을 선택하면서 브랜치 전략이 더욱더 중요해졌다.

[선택한 해결책]

깃 플로우 전략에서 release 브랜치를 제거하고, 해당 역할을 develop으로 위임했다.

1. release 두지 않아도 되는 이유: 고정된 사용자가 없다. 그래서 QA에서 hotfix를 할 일이 크게 없다고 판단했다.

2. develop/fe와 develop/be로 나눈 이유: 모노레포 방식이기에 충돌을 최대한 피하고자 했다. 
추가로 머지 조건에 최소 1명 approve해야 머지되는 조건을 설정하여 휴먼에러를 방지했다.

다른 대안들:

• ❌ 정석 깃플로우 따라가기: 표준이 정답이 아니기에 팀에 맞는 브랜치 전략을 선택했다.

이 결정으로 얻는 장점과 감수해야 할 단점

장점:

• [장점 1]: 코드가 섞이는 사고가 없었다. (무려 10개월간)
• [장점 2]: 머지 규칙으로 휴먼에러 방지에 성공했다.

단점/트레이드오프:

• [단점 1]: 점점 사용자가 들어올수록 release 브랜치 부재가 느껴졌다. 릴리즈 버전관리와 QA시 hotfix방식을 정하지 않았어서 불편했다.

• [링크 또는 관련 문서]