깃허브 브랜치 전략

[manNomi]

• 팀원이 늘어나면서 깃 브랜치 전략에 대해 고민이 많아졌습니다.

현재까지는 main 브랜치만 두고,
PR 머지 시 stage 배포
이후 GitHub Actions를 통해 Main에 바로 배포하는 방식을 사용해 왔습니다.
소수 인원에서는 단순하고 효율적이었지만, 인원이 늘어나면서 작업 범위가 겹치고
병합 관리에 대한 고민이 점점 커지고 있습니다.

여러분들의 의견 또는 가치관을 알려주셔도 좋을것 같아요!

제가 개인적으로 가장 중요하게 생각하는 기준은 롤백이 쉬운 구조입니다.
기능을 크게 묶어서 워터폴 형태로 배포하기보다는,
작은 단위로 계속 실험하면서 사용자 반응을 보고
점진적으로 개선해 나가는 방향을 선호합니다.

가능하다면 배포 이후에도

• 빠르게 롤백할 수 있고
• 성능을 비교·측정해보고
• Unleash 같은 Feature Flag를 활용한 A/B 테스트나 로깅도 자연스럽게 할 수 있는 구조를 가져가고 싶습니다.

이런 방향성을 기준으로 봤을 때,

• Git Flow가 적절할지
• 아니면 기존처럼 main 중심 전략을 유지하되 보완하는 게 나을지
  다른 분들의 경험과 의견을 듣고 싶습니다.

현재 팀 규모에서
병합을 깔끔하게 유지하면서도 실험과 빠른 롤백이 가능한 브랜치 전략에 대해 어떤 선택을 하셨는지 공유해주시면 감사하겠습니다.