서론

원래는 Github flow를 통해 지속적인 CI/CD를 진행하였는데, 이는 앞으로 서비스에 반영될 기능들이 충분히 테스트 되지 못하고 배포되는 문제점을 해결하기 위해 flow를 어떻게 하면 좋을까를 고민하는 사수를 보며 구체화 되지 않은 개념들을 조금이나마 구체화하고, 이해하기 위해 정리해야겠다는 생각이 마구 들어서 개인적으로 정리하기 위한 글입니다.

잘못된 개념과 수정사항은 언제든 환영합니다!

Git Flow

구조

• 구조 : feature > develop > release > hotfix > master
• develop과 master가 base가 된다.

1. master에서 develop을 분기한다.
2. 기능 구현을 위해 develop에서 feature를 분기한다.
3. 기능 구현이 완료되면 feature를 develop에 merge한다.
4. 배포를 위해 develop에서 release를 분기한다.
5. 테스트를 진행하면서 발생하는 버그 수정은 release 브랜치에 직접 반영한다.
6. 테스트가 완료되면 release를 master와 develop에 merge 한다.

브랜치

master

• production을 위한 브랜치

develop

• base branch : master
• 개발을 위한 브랜치

feature

• base branch : develop
• 새로운 기능을 추가하기 위한 브랜치
• origin에 반영되지 않으며 local repo에만 존재

release

• base branch : develop
• 새로운 production 릴리즈를 위한 브랜치
• 현재까지의 기능들을 묶어서 develop에서 release를 따옴
  - develop에는 다음번 릴리즈를 위한 기능들을 추가
  • release의 버그는 release에 직접 반영하고, 필요하다면 변경사항을 develop에도 반영해준다.
• 릴리즈 준비가 완료되면 master에 merge 진행. 그 이후 develop에도 merge

hotfix

• base branch : master
• production에서 발생한 버그들을 fix하는 브랜치
• 수정 후 master, develop에 반영 (release가 존재한다면 release에도 반영)

Github flow

특징

• master의 role이 정확하다.
  - master는 항상 최신 상태를 유지하며, stable 하다.
  • 이는 master는 언제든 배포가 가능하다는 것을 의미한다.
• 자동화의 개념이 추가
• pull request를 통해 master에 반영(코드 리뷰 기능)
• 릴리즈의 개념이 없다.
• hotfix와 가장 작은 기능을 구분하지 않는다.
• 원격 브랜치로 수시로 push

Git flow + Github flow

구조

• develop > staging > production
• Github flow의 지속적인 merge와 Git flow의 테스트가 완료된 커밋들을 선별적으로 배포할 수 있는 구조
• Github flow에 staging 브랜치를 추가하고 interactive rebase를 이용하여 develop에서 원하는 커밋들을 staging에 반영

브랜치

develop

• 개발을 위한 브랜치(기능 구현에 초점)
  - pull request를 거친 커밋들이 자유롭게 올라간다.
• production의 배포와 관계가 없다.
  - 배포 주기에 구애받지 않는다.

staging

• develop에서 배포가 확정된 커밋들이 존재
• staging은 지속적으로 유지가 되는 브랜치
  - 배포 가능한 빌드를 staging 빌드로 테스트 가능
• 실제 production 환경에서 테스트
  - 배포 기능과 버그 수정에 집중

production

• 실제 배포가 되는 브랜치
• staging에서 테스트 후 production으로 merge가 되면 배포가 완료

정리

이번 flow 정리를 통해 사수에게 미안함을 또 한번 느끼고, 이 참에 이런 정리의 시간을 가지게 해줘서 감사의 마음을 느낍니다.

Github flow에 develop(staging 겸용)을 추가하며, git으로 삽질을 했는데.. 이런 flow 보다도 upstream이나, rebase와 merge의 차이점에 대해 공부해야겠다는 생각도 듭니다.

---

참고

• 지속적 통합/배포(CI/CD)를 위한 Git Workflow 전략