[DevOps] Git Flow vs GitHub Flow

집중맞은 도둑력·2024년 8월 18일
0

DevOps

목록 보기
1/1
post-thumbnail

0. 🔖 목차


  1. 개발 프로세스 모델을 ARABOJA
  2. Git Flow
  3. GitHub Flow

1. 개발 프로세스 모델을 ARABOJA


Git Flow, GitHub Flow, GitLab Flow는 모두 Git을 사용하는 개발 프로세스 모델이다.

각각의 워크플로우는 목적과 사용 방식이 다른데 보통 프로젝트의 규모, 배포 방식 등에 따라 선택되는 것 같다.

2. Git Flow


브랜치 관리 전략을 체계화하여 개발, 테스트, 배포를 보다 쉽게 관리할 수 있도록 하는 워크플로우다.

장기적으로 유지보수하기 좋으며 안정성과 관리성이 좋다.

주요 브랜치는 아래와 같다.

  • master: 항상 배포 가능한 상태를 유지하는 브랜치, 릴리즈된 안정적인 코드만 포함
  • develop: 새로운 기능들이 병합되는 개발 브랜치, 이 브랜치는 다음 릴리즈를 준비하는 코드가 모임
  • feature/*: 새로운 기능을 개발하는 브랜치, 각 기능은 별도의 feature 브랜치에서 작업되며, 작업이 완료되면 develop 브랜치로 병합
  • release/*: 릴리즈 준비를 위한 브랜치, release 브랜치는 develop 브랜치에서 파생되며, 테스트와 버그 수정을 거쳐 master 브랜치에 병합
  • hotfix/*: 긴급한 버그 수정을 위한 브랜치, master 브랜치에서 파생되어, 버그 수정 후 바로 master와 develop 브랜치에 병합

3. GitHub Flow


GitHub에서 제안한 워크플로우로, 단순하고 빠른 배포를 위한 방법.

주로 작은 팀이나 CI/CD(Continuous Integration/Continuous Deployment) 환경에서 사용됨.

간단하고 CI/CD와 긴밀하게 연동되어 자동화된 배포를 쉽게 할 수 있다.

주요 브랜치는 아래와 같다.

  • master: 항상 배포 가능한 상태를 유지하는 브랜치, 모든 기능이 main 브랜치에서 개발되고 병합
  • feature or change
    - 새로운 기능을 개발할 때 main 브랜치에서 파생된 브랜치에서 작업
    - 기능 개발이 완료되면 pull request(PR)를 통해 main 브랜치에 병합을 요청
    - PR 리뷰가 완료되고 병합되면, 자동으로 배포가 이루어지거나 수동 배포가 진행
profile
틀린_내용이_있다면_말해주세요.

0개의 댓글