Git Flow & GitHub Flow

해당 포스트는 Git-Flow전략에 대한 포스트입니다.
혹시 Git에 대한 명령어에 대해 알고 싶다면 여기를 추천드립니다.

⏳ Git Flow

Git Flow란 Git을 이용하여 개발을 진행하는 전략 중에 하나입니다.

개인 혹은 팀원들과 협업을 통해서 Git을 사용한다면 팀원들 모두가 이해만 하고 있다면 어떤 전략을 사용해도 상관없습니다.
하지만 Git Flow에 대해 배우고 공부하는 이유는 많은 사람들이 사용하고 사용했던 유명한 전략이기 때문이라고 생각합니다.
그만큼 안정적이고 자료도 많으며 처음 협업하면서 어떤 전략을 사용해야 할지 감을 잡기 어려워서 일단은 유명한 전략을 공부하고 이후에 필요한 부분을 바꿔가면서 적용하자는 의도로 해당 포스트를 작성하게 되었습니다.

Git-Flow

Git Flow에는 몇 가지 브랜치와 규칙이 있습니다.
그것들에 대해서 하나씩 알아보겠습니다.

0️⃣ master

기준이 되는 브랜치입니다. ( main 혹은 master )
해당 브랜치는 항상 즉시 배포가 가능한 상태여야합니다.
또한 master는 PR을 통해서만 작업을 해야합니다. ( 바로 push하면 안됩니다. )

해당 브랜치를 기반으로 develop 브랜치를 생성합니다.

1️⃣ develop

개발 진행에 사용하는 브랜치입니다.
또한 develop도 PR을 통해서만 작업을 해야합니다. ( 바로 push하면 안됩니다. )

해당 브랜치를 기반으로 feature와 release 브랜치를 생성합니다.

2️⃣ feature

기능별 개발에 사용되는 브랜치입니다.

feature/기능명 형태로 브랜치를 만들고 해당 기능에 대한 개발을 진행합니다.
( feature 브랜치는 여러 개를 만들고 각자 기능을 작업합니다. )

한 가지 기능을 만드는 동안 필요한 커밋을 직접 push합니다.

기능 개발이 끝났다면 PR을 통해서 develop와 병합합니다. ( + review )
만약 PR에 의한 병합에 conflict가 발생한다면 feature에서 develop과 먼저 병합한 뒤 충돌 대상자끼리 협의 후 해결하고 다시 PR을 합니다.

3️⃣ release

배포전에 테스트를 진행하는 브랜치입니다.

여러 기능을 만들어 배포할 준비가 된 develop 브랜치를 기반으로 생성합니다.
배포전 테스트를 진행하고 수정할 부분을 바로 추가합니다.
테스트가 끝나고 확실하게 배포할 준비가 되었다면 PR을 통해서 master 브랜치와 병합합니다.

4️⃣ hotfix

배포 이후 즉, master와 develop을 병합하고 난 뒤에 버그를 발견하는 경우 사용하는 브랜치입니다.

master를 기준으로 생성하고 버그 수정에 필요한 부분을 바로 hotfix에서 수정하고 버그가 해결되면 master 브랜치와 병합합니다.

master가 병합되고 난 뒤에는 PR을 통해서 develop에 병합해야합니다.
master 브랜치로 부터 시작되기 때문에 develop에 적용한 충돌은 develop에서 해결해야 합니다.

5️⃣ 요약

• master: 항상 배포가 가능한 원본 브랜치
• develop: 다음 버전 개발을 진행하는 브랜치 ( 중간 다리 역할 )
• feature: 기능 단위로 개발을 진행할 때 사용하는 브랜치
• release: 배포 전에 테스트를 실행할 브랜치
• hotfix: 배포 이후에 발견된 버그를 빠르게 해결하는데 사용하는 브랜치

1. master로 부터 develop 생성
2. develop으로 부터 feature/기능명 생성
3. feature에서 각 기능 개발 후 완료 시 PR과 Review를 통해 develop과 병합
4. 원하는 기능을 모두 구현하고 배포할 준비가 되었다면 develop을 기반으로 release 생성
5. release로 배포 및 테스트 진행하고 수정할 부분은 바로 커밋
6. release에서 테스트가 끝났다면 PR로 master에 병합
7. 만약 이후에 master에서 버그가 발견되었다면 master를 기준으로 hotfix를 생성하고 버그를 해결
8. 버그를 해결하고 master에 바로 병합하고 이후 master를 develop에 병합

6️⃣ 주의 사항

1. 모든 브랜치를 병합할 때는 항상 브랜치 병합 커밋 이력을 남겨야 추적을 할 수 있기 때문에 --no-ff 옵션을 사용해서 병합해야합니다.
   
2. PR에 대한 규칙을 협의 후 정해둬야 합니다. ( 몇 명의 승인이 있어야 PR할지 등 )
3. 첫 커밋 시 태그 등록 / master와 병합하는 경우 태그 등록하기

🫗 GitHub Flow

GitHub Flow란 Git을 이용하여 개발을 진행하는 전략 중에 하나입니다.
Git Flow보다는 비교적 단순한 구조입니다.

항상 master를 기반으로 브랜치를 생성합니다.

기능 추가, 버그 해결 등 모두 master를 기반으로 생성하되 어떤 역할인지 알 수 있도록 네이밍을 해야합니다.
( 팀원끼리 협의를 통해 상황에 맞는 네이밍을 정하기만 하면 될 것 같습니다. )

특정 단위를 작업을 하고 master와 병합해야 하는 경우에는 PR을 통해서 Review 이후에 병합합니다.
( Git Flow처럼 중간 테스트 과정이 없기 때문에 확실하게 Review하고 병합해야합니다. )

대부분 GitHub Action같은 CI/CD를 통해서 자동으로 배포되도록 합니다.
만약 CI/CD를 처리하지 않았다면 수동으로 배포하면 됩니다.

• 요약
  1. 기능, 버그 등 모든 브랜치는 master를 기반으로 생성
  2. 개발이 완료되었다면 PR과 Review를 통해 해당 브랜치와 master를 병합
  3. master를 기준으로 배포

📮 레퍼런스

1. Youtube - Git Flow
2. Youtube - 테코톡 - Git 브랜칭 전략
3. Youtube - 생활 코딩 - Git Flow Model

4. inpa - 깃 브랜치 전략 정리

5. 1-blue - Git 명령어 정리
6. 1-blue - Git 명령어 정리