[레벨3] Git 브랜치 전략

먼저 이 글에서 main 브랜치는 master 브랜치를 의미합니다!

'main 브랜치 == master 브랜치 ' 로 생각하고 글을 읽어주세요 :)

 

---

Git-flow

Git-flow는 빈센트 드리센(Bincent Driessen)이 2010년에 제안한 브랜치 전략 모델입니다.

우선 알아야 할 것은 빈센트 드리센도 2020년 3월 5일에 2010년에 작성한 글에 코멘트를 작성했습니다.

내용을 요약하면 10년이 지난 모델이고 웹 애플리케이션 같은 경우는 여러 버전의 소프트웨어로 관리될 필요가 없고 지속적으로 제공해도 문제가 되지 않으므로 복잡한 모델인 Git-flow 모델보다 Github-flow 같은 간단한 브랜치 전략 모델을 사용할 것을 추천하고 있습니다.

 

Git-flow 에 대한 내용은 아래부터 시작하겠습니다. 우선은 간단한 용어부터 보고 넘어가겠습니다.

upstream Repository / origin Repository / local Repository 

• 저장소 (Repository)
  • upstream : 최신의 소스 코드가 저장되어 있는 Repository
  • origin : upstream 을 Fork 한 원격 개인 저장소
  • local : 내 컴퓨터에 저장되어 있는 저장소
• 브랜치 (Branch)
  • Main - 최종 배포 브랜치
  • Release - 배포버전 QA를 진행하고 발생하는 버그를 처리하는 브랜치
  • Develop - 개발한 기능들이 모이는 main line 브랜치
  • Feature - 기능을 개발하는 브랜치
  • Hot-Fix - 배포한 버전에서 발생한 버그를 수정

Git-flow 모델의 간략한 흐름

• 태초에 main 과 develop 브랜치가 있었더라
• develop 브랜치는 main 브랜치에서 탄생한 브랜치
• develop 브랜치에는 상시로 버그를 수정한 커밋들이 추가될 수 있슴당
• 새로운 추가 작업이 있는 경우 develop 브랜치에서 feature/xxxxx 브랜치를 생성합니다.
• 기능 추가 작업이 완료됐다면 feature 브랜치는 develop 브랜치로 merge 합니다.
• develop 에서 이번 버전에 포함할 기능이 모두 merge 됐다면 QA로 가기위해 develop 브랜치로부터 release 브랜치를 생성합니다.
• QA를 진행하면서 발생한 버그는 release 브랜치에서 수정합니다. (QA에서 발견한 버그를 해결한 commit 은 release 브랜치에 추가)
• QA를 무사히 마쳤다면 release 브랜치를 main브랜치와 develop브랜치에 merge 시킵니다.
• 출시된 main 브랜치에 태그를 추가합니다.

 

이슈(jira 에서는 티켓) 처리하기

'로그인 레이아웃 생성' 이라는 이슈를 처리하려는 상황입니다.

 

하나의 이슈는 하나의 커밋으로 처리 라는 말은 기능을 구현하기 전에 작업을 여러개의 이슈로 나누는 것을 의미 (기능을 여러개의 이슈로 쪼개서 최대한 작은 작업 단위로 만들자)

 

feature-user 브랜치에서 작업 브랜치 bfm-100_login_layout 를 생성

(feature-user)]$ git checkout -b bfm-100_login_layout --track upstream/feature-user

• (feature-user)]$ git fetch upstream
• bfm-100_login_layout 브랜치에서 작업 ⚒️
• 작업 내용을 커밋

만약 커밋이 불필요하게 여러개로 나눠졌다면 squash 를 진행

• 커밋을 왜 하나로 만드나요?
• 꼭 하나일 필요는 없지만 여러개의 커밋이 나눠질 필요가 없거나 코드리뷰에 나눠진 커밋이 큰 도움이 되지 못할 때 커밋은 굳이 나누지 않고 하나로 합치는 것이 좋습니다.
• 하나의 이슈에 대한 작업이라도 커밋이 분리되어 있는것이 좋다고 생각하면 2개의 커밋으로 놔둬도 괜찮음

(bfm-100_login_layout)]$ git rebase -i HEAD~2

bfm-100_login_layout 브랜치의 작업 내용을 feature-user 브랜치에 pull —rebase 진행

• rebase 를 진행하는 이유
• 커밋을 순차적으로 만들기 위한 작업 - rebase

(bfm-100_login_layout)]$ git pull --rebase upstream feature-user

Develop 브랜치에 새로운 기능에 대한 브랜치(Feature)를 합치기 전에 Develop 의 변경사항을 Feature 브랜치에 가져오기

feature-user 브랜치에 upstream/develop 브랜치를 merge 합니다.

(feature-user)]$ git fetch upstream
(feature-user)]$ git merge –no-ff upstream/develop

upstream/develop의 변경사항이 merge된 feature-user를 upstream에 push 합니다.

(feature-user)]$ git push upstream feature-user

배포하기

• release 브랜치를 최신으로 갱신 (upstream에서 local의 release 브랜치로 push)
• release 브랜치를 develop 브랜치로 merge하고 upstream의 develop 브랜치로 push
• release 브랜치를 main 브랜치로 merge하고 upstream의 main 브랜치로 push
• main 브랜치에 태그를 추가

---

Github-flow

Git-flow는 Github 에서 사용하기에 복잡하다고 생각하여 나온 브랜치 전략이 Github-flow 입니다.

main 브랜치에만 엄격한 role을 적용합니다.("pull request 를 날려서 완벽한 검증을 거쳐야 한다"와 같은 role을 의미)

• main 브랜치는 어떤때든 Product로써 배포가 가능한 상태여야 한다. (stable 한 상태여야 한다.)
• main 브랜치에만 엄격한 role 을 적용합니다. (이외의 브랜치는 자유롭게 사용)
  • main 에서 새로운 작업을 시작하거나 버그를 수정한다면 브랜치 이름에 어떤 일을 하는지 명확하게 작성합니다.(ex. user-login)
  • Github-flow 에서는 develop, feature 브랜치가 존재하지 않습니다.
  • 커밋 메세지는 명확하게 작성해야 합니다.
  • main 브랜치에 merge 하기 전에 충분히 테스트해야 합니다.
• 원격지 브랜치에 수시로 Push 하여 팀원들이 나의 작업을 확인할 수 있도록 해야합니다.
  • 이는 하드웨어에 문제가 생겨 작업한 코드가 소실되도 원상 복구해서 작업할 수 있도록 도와줍니다.
• 도움이 필요하거나 작업이 완료되면 pull request 를 작성하고 리뷰를 받습니다.
• main 브랜치로 merge가 되면 자동으로 배포되도록 한다.

과정 요약

1. main 브랜치에서 새로운 기능이나 버그에대한 브랜치 생성(브랜치 이름에 작업내용, 버그내용 명확하게 명시)

2. 도움이 필요하거나 작업을 마치면 main 브랜치로 pull request 생성

3. 코드 리뷰, 피드백, 테스트 진행

4. CI까지 통과하면 main 브랜치에 머지시킨다.

5. main 브랜치는 merge 됐을 때 자동으로 배포되도록 한다.

---

놀토에서 사용하는 브랜치 전략

Repository(저장소)

• upstream(최신의 소스코드가 있는 원격 저장소)
• origin(개인 원격 저장소)
• local(로컬 저장소)

Branch(브랜치)

• main : Product 로 배포되는 브랜치
• release : 다음 배포버전 QA를 진행하고 QA 중 발생하는 버그를 처리하는 브랜치 (아직 release 브랜치의 존재 가치를 느끼지 못함)
• develop : 개발한 기능들이 모이는 main line 브랜치
• feature : 기능을 개발하는 브랜치
• hot-fix : 배포한 버전에서 발생한 버그를 수정

정해놓은 규칙

• 새로운 기능은 develop 브랜치로 부터 feature 브랜치를 만듭니다.
  • feature 브랜치를 만들기 전 develop 브랜치를 rebase 해서 최신의 상태로 만듭니다.
  • 프론트엔드는 feature/frontend/[작업이름] , 백엔드는 feature/backend/[작업이름] 으로 생성합니다.
• 기능 개발이 끝난 feature 브랜치는 origin 저장소로 push 합니다. (이때도 upstream의 develop 브랜치에 변경이 있을 수 있으므로 pull rebase 또는 pull 을 사용해서 코드를 가져옵니다. 코드 충돌이 있다면 해결합니다.
  • ~feature/backend/xxxx$ git push origin feature/backend/xxxx
• origin에 올라간 feature 브랜치를 upstream의 develop 브랜치로 pull request 를 작성합니다.
• pull request 에 대해 코드 리뷰를 요청합니다.
• 코드 리뷰가 완료되면 github 의 Squash and merge 기능을 사용해서 merge를 진행합니다.
• 새로운 버전 배포시에는 develop 에서 release-v0.0.0같은 브랜치를 생성
• release 에서 태그 작업, QA후에 release 브랜치에서 main 브랜치에  pull request작성하고 merge
  • main으로 merge 시킬때는 github의 create a merge commit 기능 사용
• main 에서 최신화된 내용을 develop 에도 적용