<aside> 💡 프론트와 백엔드에서 사용하는 깃 브랜치 이름을 통일할 필요가 있다는 의견이 있어 문제점을 파악 및 문제 해결을 위한 문서입니다.

</aside>

문제점😢

• 프론트와 백엔드에서 사용하는 이름의 차이로 프론트 개발시 어떤 브랜치에서 서버를 띄워야 하는지 모호하다.

  → develop? release? 이름에서 나오는 모호함

백엔드에서 사용하는 깃 전략

• 브랜치를 뽑아내는 부분에서의 버전 통일이 일어나는가?

  스프린트 및 개발 요청이 들어와서 모든 개발자들이 특정 시점(같은 커밋 주소)에서 피쳐 브랜치를 생성하는가?

• 원치않는 버전의 코드가 배포 상태로 흘러가는 것을 막을 수 있는가?

  로컬에서 테스트를 완료한 피쳐들은 무조건 develop와 머지된다. 하지만, develop에서 테스트 도중에 문제가 발생했다는 것을 확인했을 때의 처리 방침은?

• 브랜치의 수를 줄일 수는 없을까?

  이 부분은 딱히 해당사항은 없다고 생각하나. 개수로만 따지면 프론트와 차이는 없으며, 실제 서버의 배포환경에 해당하는 브랜치와 개발용으로 쓰는 브랜치 총 3개로 적당하다고 판단된다.

Git 전략

프로트에서 사용하는 전략을 백엔드와 비교해보면서 개선점을 생각해보자. 각자가 사용하는 전략은 상이하지만 일단 전반적인 브랜치의 이름은 다음과 같다.

프론트에서 사용하는 깃전략

• 로컬 브랜치 → feature/<name>_<issue>
• 개발 브랜치 → develop
• 스테이징 → staging
• 운영 브랜치 → release
• 핫픽스 → hotfix

현재 프론트에서 이뤄지고 있는 깃 전략

1. 개발 단계

   staging에서 feature/<name>_<issue>의 형식으로 브랜치 생성

2. 테스트 단계(개발 서버 배포)

   로컬 서버에서 테스트한 피처 브랜치를 개발 서버에서 테스트

   → 문제가 없다 판단할 경우 staging에 MR을 보낸다.

3. 적용 단계(운영 서버 배포)

   스프린트에서 합쳐진 모든 브랜치를 release로 전달 한다.