Git & GitHub #6 - 실무에서의 Git 브랜치 전략 및 Zone 구별

git commit -m "Blog Posting #6🫡"
개발자협업의 필수 도구

---

실무에서 Git 브랜치 전략 및 Zone 구별

실제 현업에서는 개발, 테스트, 배포를 위한 Zone을 구분하여 관리한다고 한다. 이를 효율적으로 운영하기 위해 다양한 Git 브랜치 전략을 사용하며, 대표적인 전략중 하나가 git-flow 이다.

 

개발 결과물을 테스트하기 위한 Develop Zone과 실제 유저들이 사용하기 위해 배포하는 Production Zone 그리고 이러한 Zone과 연동하여 관리하는 Git 브랜치 전략을 알아보도록 하겠다. (전략을 git-flow라고 명함)

https://techblog.woowahan.com/2553/

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그

실제로 위 링크를 보면 우아한형제들의 Git-flow 전략을 볼 수있다. 

 

현업에서의 테스트 및 배포를 위한 Zone 구성

• Local:
  • 개발자가 코드를 작성하고 초기 테스트를 수행하는 환경.
  • 로컬 데이터베이스를 사용하며 개인적인 데이터나 작은 규모의 데이터를 활용한다.
  • 로컬 브라우저에서 프론트엔드를 테스트하거나, Postman 등을 사용해 백엔드를 테스트한다.
• Develop Zone:
  • 모든 개발자들이 함께 사용할 수 있는 테스트환경.
  • 로컬에서 완료된 기능이 여기에서 통합 테스트를 받는다.
  • 이 환경에서 발견된 버그를 수정하고, 다른 개발자들과의 충돌을 해결한다.

※ 주의: Develop Zone에서 버그가 발생하고, 그곳에서 버그를 찾는 것을 너무 당연하게 생각해선 안됨

• 우리는 누군가가 먹을 수 있는 수준의 음식을 만들고 시음을 하지, 시음으로 맛을 찾아가진 않는다.
  • 어쨌거나 로컬만이 세부 디버킹 및 로그 확인이 가능한 가장 투명한 디버깅 공간이다.

• Staging Zone:
  • 실제 운영 환경과 가장 유사한 환경이다.
  • 최종 배포 전에 전체 시스템의 통합 테스트를 수행하며 성능이나 보안 문제를 점검한다.
  • 대규모 데이터베이스와 실제 네트워크 환경에서 테스트를 진행한다.
• Production Zone:
  • 실제 유저가 사용하는 환경으로 가장 안정적인 코드만이 배포된다.
  • 배포 후에 문제가 발생할 경우 신속하게 롤백할 수 있는 대응을 마련해야함.

Git 브랜치 전략 (git-flow)

 

원칙은 모든 배포는 격리된 브랜치에서 작업을 완료한 후 PR을 통해 배포를 위한 브랜치에 머지해야한다.

 

git-flow 전략은 여러 명이 협업 할 때 효율적으로 브랜치를 관리할 수 있도록 도와준다. 이 전략엔 세 가지 타입의 브랜치로 나누어진다.

• Master/Main: 배포 브랜치
  
  • 버그 발생에 대한 불확실성이 낮고 무결하여 운영존에 치명적 문제 발생 시 롤백할 수 있는 커밋들의 집합.
  • 배포 가능한 안정적인 코드를 유지하는 브랜치.
  • 모든 기능은 이 브랜치에 병합되기 전에 철저히 테스트 되어야 한다.
• Develop:테스트 브랜치
  • '테스트'의 의미는 로컬에서 테스트 및 개발을 완료한 뒤 마지막 테스트
  • 개발자들이 공동으로 작업하는 브랜치로 모든 새로운 기능과 버그 수정이 이 브랜치에서 시작한다.
  • Staging Zone에서의 최종 테스트를 위해 사용
• Feature: 개발 브랜치 - Develop 브랜치를 기점으로 새 브랜치를 만들어 개발
  1.  `feature/HELLO~001`: 기획과 디자인에 따라 개발자에게 발행된 티켓으로 브랜치 명
  2. `feature/login-with-oauth`: 어떤 작업인지 바로 알 수 있도록, 기능 내용에 대한 요약 브랜치명
     • `cheonsang/login-with-oauth`: 브랜치명에 개발자 명을 붙여넣기도한다.
     • 로컬에서 개발을 완료한 경우 Develop 브랜치에 PR요청을 하여 마지막 테스트를 준비한다.
       • PR요청을 통해 로컬에서 완료된 개발 코드를 개발자들에게 최초 노출하여 코드 리뷰를 받을 수 있다.
       • PR요청을 통해 Github Workflow로 CI(테스팅) 파이프라인을 연결하였다면, 코드 유효성 테스트 가능

Git Commit 메세지도 신경 써서 작성

할당된 티켓이 명확히 있다면 그 티켓명을 앞에 적어주고, 어떤 작업인지에 대한 요약 설명을 제목으로 쓴다.

• 예) `[HELLO-001]테스트 코드 작성을 위한 준비`

(선택) 그 아래엔 어떤 세부 작업이 있는지 나열하는 것이 좋다. 너무 구체적일 필요는 없으나 언제봐도 알 수 있도록 작성하는게 Key Point.

[HELLO-001] 테스트 코드 작성을 위한 준비

- 새로운 테스트 케이스 추가
- 기존 테스트 코드 리팩토링
- Mock 데이터 업데이트

 

할당된 티켓을 명시하지 않고, 어떤 작업인지에 대한 타입을 앞에 명시하고, 상세 내용을 작성해낸다.

• 예) `Feat: 테스트 코드 작성을 위한 준비`

---

ℹ️참고

[ASAC 6기 강의자료]

 

https://techblog.woowahan.com/2553/

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그