Git branch 전략이란?

Git branch 전략에 대해 알아보기 전에 Branch부터 알아보겠습니다.

 

Git branch란?

브랜치란 독립적으로 어떤 작업을 진행하기 위한 개념입니다.

영어로 나뭇가지라는 뜻을 가지며 실제로 브랜치를 사용하면 나뭇가지처럼 뻗어나가는 그림을 볼 수 있습니다.

https://backlog.com/git-tutorial/kr/stepup/stepup1_1.html

이렇게 나뭇가지처럼 뻗어나가 동시에 다양한 작업을 수행하고 나중에 다른 브랜츠와 병합함으로써 작업한 내용을 새로운 하나의 브랜치로 모을 수 있습니다.

 

보통 저장소를 처음 만들게 되면 Git은 'master'라는 이름의 브랜치를 만듭니다.

보통 새로운 브랜치를 만들어서 사용하지 않으면 모든 작업은 master 브랜치에서 이루어집니다.

https://backlog.com/git-tutorial/kr/stepup/stepup1_1.html

우리는 브랜치를 사용할때 master로부터 다양한 브랜치를 뻗어나갈 수 있습니다.

A개발자는 새로운 기능을 추가하기 위해 브랜치를 새로 만들었습니다.

B개발자는 비디오 표시 버그를 수정하기 위해 브랜치를 새로 만들었습니다.

C개발자는 사이드바를 추가하기 위해 브랜치를 새로 만들었습니다.

이후에 작업이 끝난 개발자들은 master 브랜치에 자신의 브랜치의 변경 사항을 적용합니다.

 

 

Git Branch 전략이란?

Git Branch 전략은 여러 개발자가 하나의 저장소를 사용하는 환경에서 브랜치를 효과적으로 활용하기 위한 전략입니다.

즉, 브랜치 생성에 규칙을 만들어서 협업을 유연하게 하는 방법론을 말합니다.

 

가장 널리 사용되는 2가지 브랜치 전략에 대해 알아보겠습니다.

 

1. git-flow 전략

git-flow 전략에는 5가지의 branch가 존재합니다.

 

항상 유지되는 메인 브랜치들(master, develop)과 일정 기간 동안만 유지되는 보조 브랜치들(feature, release, hotfix)가 있습니다.

 

• master : 제품으로 출시될 수 있는 브랜치
• develop : 다음 출시 버전을 개발하는 브랜치
• feature : 기능을 개발하는 브랜치
• release : 이번 출시 버전을 준비하는 브랜치
• hotfix : 출시 버전에서 발생한 버그를 수정하는 브랜치

https://techblog.woowahan.com/2553/

 

처음에는 master와 develop 브랜치가 존재합니다.

 

develop 브랜치도 master로부터 파생된 브랜치입니다.

 

develop 브랜치에는 상시로 버그를 수정한 커밋들이 추가됩니다.

 

새로운 기능 추가 작업이 있는 경우 develop 브랜치에서 feature 브랜치를 생성합니다.

 

feature 브랜치는 언제나 develop 브랜치에서 시작됩니다.

 

기능 추가 작업이 완료되었다면 feature 브랜치는 develop 브랜치로 merge 됩니다.

 

develop에 이번 버전에 포함되는 모든 기능이 merge 되었다면 QA를 하기 위해 develop 브랜치로부터 release 브랜치를 생성합니다.

 

QA를 진행하면서 발생한 버그들은 release 브랜치에 수정됩니다.

 

QA를 무사히 통과했다면 release 브랜치를 master와 develop 브랜치로 merge 합니다.

 

마지막으로 출시된 master 브랜치에서 버전태그를 추가합니다.

 

2.Github-flow 전략

github flow는 git flow의 브랜치 전략이 너무 복잡하고 적응하기 어렵다고 생각하여 생겨난 브랜치 전략입니다.

github flow는 master 브랜치 하나만을 가지고 진행하는 방식입니다.

master 브랜치는 어떤 기능을 구현하든, 오류가 수정되는 모두 master에 머지되어 항상 update 된 상태를 유지합니다.

github flow 흐름도(https://ujuc.github.io/2015/12/16/git-flow-github-flow-gitlab-flow/)

처음에는 master 브랜치가 존재하고 master 브랜치에서 개발이 시작됩니다.

 

기능 구현이나 버그가 발생하면 issue를 작성합니다.

 

팀원들이 issue 해결을 위해 master 브랜치에서 생성한 feature/{ 구현기능} 브랜치에서 개발하고 commit log를 작성합니다.

 

push를 하면 pull request를 날릴 수 있습니다.

 

pull request를 통해 팀원들 간의 피드백, 버그 찾는 과정이 진행됩니다.

 

release 브랜치가 없으므로 이 과정이 탄탄하게 진행되어야 합니다.

 

모든 리뷰가 이루어지면 merge 하기 전에 배포를 통해 최종 테스트를 진행합니다.

 

테스트까지 진행되면 master 브랜치에 머지합니다.

 

브랜치전략이 단순하여 master 브랜치에서 pull ->  기능 구현 -> 머지의 반복입니다.

 

따라서 CI/CD를 통한 배포 자동화를 적용하는 것이 좋으며 pull reqeust에서 팀원 간의 충분한 리뷰와 피드백이 진행되지 않으면 배포된 자체에서 버그가 발생할 수 있으므로 주의해야 합니다.

 

github-flow의 특징

브랜치 전략이 단순하고 git을 처음 접하는 사람에게도 유용합니다.

CI(지속적 통합), CD(지속적 배포)가 자연스럽게 이루어집니다.

 

 

위에서 다룬 간단한 깃명령어에 대해서 설명하겠습니다.

git push : 로컬 저장소에서 원격 저장소로 코드 변경분을 업로드하기 위해 사용하는 명령어

git pull request : 코드를 무장적 병합하기전에 내가 수정한 코드를 가져가 검토 후 병합해달라는 의미입니다. (보통 push 권한이 없는 오픈 소스 프로젝트에 기여할 때 많이 사용합니다)

git pull : 원격 저장소의 최신 내용을 로컬 저장소로 가져오면서 병합합니다.

 

git-flow vs github flow 무엇을 적용하는 것이 좋을까?

한 달 이상의 긴 호흡으로 개발하여 주기적으로 배포하고 QA 및 배포, hot fix 등을 수행할 수 있는 여력이 있는 팀이라면 git-flow가 적합합니다.

 

항상 릴리즈되어야 할 필요가 있는 서비스와 지속적으로 테스트하고 배포하는 팀이라면 github-flow와 같은 간단한 workflow가 적합합니다.

 

출처

https://techblog.woowahan.com/2553/

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그

https://backlog.com/git-tutorial/kr/stepup/stepup1_1.html

누구나 쉽게 이해할 수 있는 Git 입문~버전 관리를 완벽하게 이용해보자~ | Backlog

https://tecoble.techcourse.co.kr/post/2021-07-15-git-branch/

git 브랜치 전략에 대해서