Git 브랜치 전략 - Git Flow, Github Flow

 

 Git은 협업을 위한 툴이다. 그래서 나도 지금까지 프로젝트를 할 때마다 나름의 커밋 컨벤션도 세우고, 작업마다 브랜치를 파서 작업한 후 pr을 올리고 merge conflict를 체크하고, 간단한 코드리뷰를 통해서 approve받은 후에야 develop으로 머지하는 프로세스들을 익히고 지켰다. 하지만 확실한 규칙을 설정하고 진행한 것이 아니기 때문에 reset --hard를 한다거나, 같은 branch에서 conflict가 난다거나 한다는 문제들이 발생했다. 그래서 브랜치 전략이라는 패턴에 대해서 간단히 정리해보고자 한다.

 

 

브랜치 전략이란?

 

 효율적인 협업을 위해서 Git을 사용하는데, 협업하는 팀원들간에 스타일의 차이가 있기 때문에 사용방식의 통일을 주기 위해서 사용되는 전략을 말한다. 크게 Git Flow와 Github Flow 두가지 전략이 존재하는데, 각각에 대해 정리해보겠다.

 

 

Git Flow

 

 Git Flow 전략은 상용 서비스를 진행중인 경우에 많이 사용된다. master와 develop이라는 항상 존재하는 메인 브랜치가 존재하고, hotfix, release, feature와 같이 메인 브랜치의 필요에 따라서 생성, 삭제되는 보조 브랜치가 있다. 

 

 

 master 브랜치는 라이브 서비스되고 있거나 당장 배포 가능한 상태의 브랜치를 말하고, develop 브랜치에서는 다음 배포 기능을 개발하는 브랜치이다. 일반적으로 develop 브랜치를 default 브랜치로 지정하여 이것을 중심으로 작업하고, develop에서 문제가 발생하지 않음을 확인했다면 master브랜치를 업데이트한다.

 

 feature 브랜치는 기능을 추가를 목적으로 하는 브랜치로, 작업이 끝나면 develop 브랜치로 머지한다.

 

 release 브랜치는 master에서 서비스 중이고, 기능 추가(feature)가 적당히 완료된 경우 새로운 버전 출시를 준비하기 위한 브랜치이다. release 브랜치가 분기된 경우 버그 수정과 같은 릴리즈 관련 작업들이 수행되며, 배포 가능한 상태가 된다면 master 브랜치에 merge한다.

만약 release단계에서 버그가 발견되어 수정한 경우에는 develop브랜치쪽에도 merge를 진행하여 오류를 수정한다.

+ 버전별로 릴리즈를 관리할 경우 'release-*'나 'release/*'와 같이 이름짓는다. (ex. release-4.0.0, release/v4.0.0-feat-0907)

 

 

 hotfix 브랜치는 release 브랜치까지 잡아내지 못해 라이브서버에 버그가 존재할경우 버그를 수정하기 위한 브랜치이다. release 브랜치와 비슷하게 'hotfix-*'과 같이 버전별로 관리할 수 있으며, 버그를 해결하면 제거한다.

 

 

 보조 브랜치는 메인 브랜치의 필요에 의해서 생성된다. 메인 브랜치는 기존에 잘 작동하는 개발코드가 담기며, 보조 브랜치는 기능의 추가, 버그 수정 등으로 새로 변경되는 코드를 분리하고 보존하는 역할을 한다. 

 

 

 

Git Flow 전략 작업 예시

 

<커밋>

1. 작업 시작전에 작업용 브랜치를 파고 작업을 시작한다.

  git branch origin release/v4.0.0-fix-0905

  git checkout origin release/v4.0.0-fix-0905

 

2. 작업이 끝나면 git fetch를 통해서 동일한 브랜치명을 다른 사람이 사용하는 방식으로 브랜치를 만들 경우, 원격 저장소의 변경 사항이 생겼는지 확인한다.

 참고로 작업이 끝난 후 로컬서버가 돌고있다면 중단해주는 것이 좋다

3. git pull을 통해서 원격 저장소의 최신 데이터를 로컬로 가져온다.

4. commit convention대로 git commit한다.

  git commit -am "feat: 기능 ~추가, Related to: #AOP-1234

5. git push하면 작업내용이 원격 저장소로 push된다.

 

<배포>

6. 팀 슬랙이나 카톡방에 배포사실을 알린다. (ex. dev서버 release/v4.0.0-fix-0905 브랜치 배포예정)

7. clean-build

8. 터미널에서 (mvn사용시) mvn package jib:build 통해서 이미지를 생성해준다. 생성된 이미지 여기서 문제가 발생했다면 clean-build를 다시 해주고 재실행한다.

9. 이미지 생성을 확인한다.

10. argocd에서 서버를 restart해주면 올라간 이미지를 바탕으로 서버가 재실행된다.

 

 

 

GitHub Flow

 

 GitHub Flow 전략은 간단하게 상용 서비스를 위한 master 브랜치와, master 브랜치에서 만들어지는 브랜치, 이렇게 2개의 브랜치만이 존재한다. 따라서 master 외 새로 생성하는 브랜치는 목적을 알 수 있도록 명명 규칙을 잘 세워야 한다.

 먼저 개발이 시작되면 master로부터 새로운 브랜치를 만들고 작업한다. 그리고 기능 개발이 완료되는 등 merge 준비가 완료되는 경우 pull request를 생성한다. 이것을 이용해서 코드리뷰를 진행하고, 문제가 없다고 생각하면 배포한다.

 

 

GitHub Flow 전략 작업 예시

 

1. 작업 시작 전에 브랜치를 파고 작업한다.

  git branch origin feat/drawer-yb/0905

  git checkout origin feat/drawer-yb/0905

 

2. 작업이 끝나면 git fetch와 git update를 통해서 변경내역을 확인한 후, 원격 저장소에 add commit push한다.

3. 해당 단위 스프린트가 끝나면 pr을 날린다.

4. pr 내용가지고 코드리뷰를 진행하고, merge conflict 여부를 확인하고 수정할 수 있다.

5. 문제가 없다면 master 브랜치로 합친다.

 

 

정리

 

- 긴 호흡단위로 개발하며, 주기적으로 릴리즈, QA, 테스트, 핫픽스 등을 수행할 수 있는 기업단위 프로젝트라면 git-flow가 적합하다.

- 수시로 릴리즈 되어야 하는 서비스를 지속적으로 테스트하고 배포하는 스타트업이나, 프로젝트 시작단계라면 github-flow를 통해서 생산성을 향상시킬 수 있다.