[10분 테크톡] 렉스의 Git 브랜칭 전략 후기

 

 

새로운 팀 프로젝트에 앞서 개발자는 2명 뿐이지만 어떤 브랜치 전략을 도입해야할지 고민하던 찰나 잘 정리된 영상을 보게 되어 정리해보았다.

물론 이와 관련해서 검색하면 더 나오긴 하지만 Git 브랜치 전략은 늘 다시 보게 되고, 늘 헷갈리는 것 같다.

다시 한 번 헷갈리지 않고 정확히 이해하기 위해 이번 영상을 정리해본다.

 

목차

• Branch 전략이란?
• Github flow란?
• Git flow란?
• 우린 무엇을 사용해야할까?

 

Branch 전략

1. 평상시 우리의 branch 사용 유형
   1. 혼자 개인 프로젝트 개발을 할 때 -> 문제도 자신이, 규칙도 자신이 책임진다
      1. 코드의 수정, 기능 개발 등을 할 때만 branch를 여는 유형
      2. 하나의 branch만 사용하는 유형
   2. 팀으로 프로젝트 개발을 할 때
      1. branch명에서 생성자와 생성목적이 드러나지 않을 때
      2. branch의 사용이 끝났는지 여부를 알 수 없을 때
      3. 새로 개발을 하고 싶은데 어떤 브랜치를 사용해야하는지 알 수 없을 때 => 많은 불편함과 문제점이 발생
   1. 여러 명의 개발자가 1개의 저장소를 사용하는 환경에서 효과적으로 사용하기 위해 나온 개념
   2. 거의 모든 기업들이 사진들의 상황에 맞는 전략을 사용하고 있다
   3. 대표적인 전략 : Github flow, Git flow, GitLab flow

 

Github flow

1. Github에서 만든 단순한 구조의 브랜치 전략
2. Master 브랜치를 중심으로 운영되며, 기능 개발 버그 수정 등의 작업용 브랜치를 구분하지 않는 단순한 구조
3. 수시로 배포가 일어나는 프로젝트에 유용하다
4. 3주의 주기로 출시하던 2016년 1월부터 2017년 6월까지 우아한형제들(안드로이드 모바일 파트)에서도 사용한 전략이다
5. 생명 주기
   1. 브랜치 생성
      1. Master로부터 기능추가, 버그 수정 작업을 위한 새로운 브랜치를 생성한다
      2. 이때 commit 메시지와 브랜치 이름은 정확하고 간결하게 작성해야 한다
      3. 기능 추가, 버그 수정 작업을 하는 모든 브랜치는 master로부터 나온다
   2. 기능 개발, 버그 수정
      1. 작업을 하며 기능별로 commit을 한다
      2. commit 메시지는 정확하고 간결하게 작성해야 한다
      3. commit은 서버의 동일한 브랜치에 push해줘야 한다 (Git flow와 차이점)
   3. Pull Request
      1. 기능 또는 오류 수정이 완료되었으면 PR을 보낸다
   4. 리뷰와 논의
      1. PR을 통해 팀원과 작성한 코드에 대한 리뷰와 논의를 한다
         예) 코딩 스타일이 프로젝트 가이드라인에 맞지 않는다. 메소드 위치가 올바르지 않은 것 같다.
   5. 공개 및 테스트
      1. Github에서는 Master에 합치기 전에 브랜치에서 코드를 공개 및 테스트 할 수 있다
      2. PR상의와 테스트가 끝난 경우 (테스트 버전으로) 공개할 수 있다
      3. 오류가 발생하 경우 원래의 master 브랜치를 다시 배포하여 roll back한다
   6. 합치기
      1. Branch의 검증이 완료되면 메인 브랜치에 합친다

 

Git flow

1. Git flow는 Vincent Driessen이 2010년에 제안한 Branch Model을 기반으로 만들어졌으며 현재는 많은 기업에서 표준으로 사용하는 브랜치 전략이다
2. Github flow와는 다르게 크게 5개의 브랜치를 운영하며 관리를 한다
   1. 메인 브랜치 : master, develop
   2. 보조 브랜치 : feature, release, hotfix
3. 배포 주기가 길고 팀의 여력이 있는 경우 적합하다
4. 우아한형제들(안드로이드 모바일 파트)도 2017년 6월 Github flow에서 Git flow로 전략을 변경하였다
5. 메인 브랜치들의 특징
   1. Master와 Develop 브랜치가 있다
   2. 두개의 브랜치는 항상 남아있는다
   3. Master 브랜치 : 제품으로 배포할 수 있는 브랜치
   4. Develop 브랜치 : 개발자들이 개발을 하는 브랜치
6. 보조 브랜치의 특징
   1. feature, release(QA), hotfix 브랜치가 있다
   2. 사용을 마치면 브랜치를 삭제한다
   3. Feature 브랜치
      1. 브랜치가 분기/머지 되는 곳 : develop
      2. 이름 : master, develop, release-*, hotfix-*를 제외한 이름 가능
      3. feature 브랜치는 하나의 새로운 기능을 만들 때 생성한다
      4. develop에 merge 후에는 삭제!
      5. merge할 때는 --no-ff를 사용하여 기록을 그룹화한다
      6. --no-ff : Fast-forward관계에 있어도 merge commit을 생서아여 해당 브랜치가 존재하였다는 정보를 남길 수 있고, commit기록을 되돌리기 편해짐
         1. 사용하지 않으면 브랜치의 존재 여부를 몰라 어떤 commit부터 해당 기능을 구현했는지 확인하기 어렵다
   4. Release 브랜치
      1. 브랜치가 분기 되는 곳 : develop
      2. 브랜치가 머지 되는 곳 : develop & master
      3. 이름 : release-*
      4. 다음 버전 출시를 위해 QA를 진행하는 브랜치
      5. 버그 수정 및 버전 번호, 빌드 날짜와 같은 메타 데이터를 준비하며 기능 개발은 금지된다
      6. merge할 때는 --no-ff를 사용하여 기록을 그룹화한다
      7. master로 merge 후에는 tag 명령을 통해 버전을 명시한다
   5. Hotfix 브랜치
      1. 브랜치가 분기 되는 곳 : master
      2. 브랜치가 머지 되는 곳 : develop & master
      3. 이름 : hotfix-*
      4. Production에 버그가 발생하면 빠른 수정을 위해 생성하는 브랜치
      5. Production 코드를 수정하는 중에도 develop에서는 계속 개발을 할 수 있다는 장점이 있다
      6. master로 merge 후에는 tag 명령을 통해 이전 버전보다 높은 버전을 명시한다
         예) 1.2 -> 1.2.1
   6. 전체적인 흐름 요약 (iOS 업데이트 예시)
      1. 애플의 개발 전략은 비공개이며 이해를 돕기 위해 대입한 예시

 

우린 무엇을 사용해야할까?

1. 팀의 브랜칭 전략은 조직의 규모, 서비스의 특징 등을 고려하여 협의를 통해 전략을 결정해야한다
2. Production의 공식 배포 주기가 길고 QA, 테스트, hotfix 등의 여력이 있으면 Git flow가 적합하다
3. 지속적으로 테스트 및 배포를 하는 팀의 경우 간단한 Github flow를 사용하는 것이 좋다
4. Work-flow를 필요 이상으로 복잡하게 만드는 것은 좋지 않다

 

참고자료

GitHub flow - GitHub Docs

 

Git 브랜칭 전략 : Git-flow와 Github-flow