Git Branch 전략

Git flow

  Git은 프로젝트 코드를 효과적으로 관리할 수 있도록 소스코드와 히스토리를 저장하는 버전 관리 시스템이다. SVN과 달리 소스 코드를 중앙서버가 아닌 여러 로컬 PC와 저장소에 저장함으로써 좀 더 안전하고 용이하게 코드를 관리할 수 있다. 

 

  Git을 잘 쓰는 것을 협업을 원활하게 할 수 있다는 것과 연관이 있다. Git을 잘쓰기 위해선 Git의 개념, 키워드 뿐만 아니라 Git Branch전략, Git Commit Message 작성방법 등에 대한 고민이 필요하다. 오늘은 Git Branch 전략에 대한 포스팅을 작성해본다.

 

1. Branch

Brach

  Branch란 나뭇가지라는 뜻이다. 나무가 나뭇가지를 통해 분기하며 뻗어나가듯이 코드도 브랜치라는 지점을 통해 분기하여 다른방향으로의 작업을 이어나간다.

 

  Git으로 init된 프로젝트에서 브랜치를 만들면 현재 코드(원본)의 복사본이 생성된다. 생성된 브랜치에서 코드 작업을 할 때 원본의 코드에는 영향을 끼치지 않는다. 하나의 프로젝트에 여러 사람이 협업할 때 브랜치를 만들어 작업하므로써 각자 독립된 코드환경에서 작업하거나 코드를 관리할 수 있다.

 

  Git 저장소를 효과적으로 관리하기 위해 어떤 역할을 하는 브랜치를 만들지에 대한 즉, 브랜치 생성에 대한 규칙을 만드는 것이 Git Branch 전략이다. 브랜치 전략이 없다면 여럿이서 협업하는 상황에서 어떤 브랜치가 최신 브랜치인지, 어떤 브랜치에 코드를 push해야할지, 기능 수정 요청에 대해 어떤 Branch의 코드를 수정해야할지 혼란스러울 것이다.

 

  이 포스팅에서는 git-flow전략과 github-flow에 대해 정리할 것이다. git-flow 전략은 5종류의 브랜치를 사용하는 전략, github-flow는 master 브랜치만을 사용하는 전략이다.

 

2. Git flow

Git flow

  GIt flow는 가장 대중적인 브랜치 전략이다. 핵심인 master, develop 브랜치를 항상 유지하고, 필요에 따라 feature, release, hotfix 브랜치가 추가되며 이들은 작업 후에 핵심 브랜치에 머지되고 삭제된다. 각 브랜치의 역할은 다음과 같다.

 

[Branch 종류]

• master: 프로덕션으로 배포될 수 있는 브랜치
• develop: 최신 개발 변경사항이 반영되어있는 브랜치(현재 개발중인 코드 반영)
• feature: 새로운 기능을 개발을 위한 브랜치
• release: 배포를 준비하기 위한 브랜치
• hotfix: 출시 버전에서 발생한 버그를 수정하는 브랜치

 2-1. master / develop

    Git의 프로젝트는 기본적으로 master 브랜치를 갖고 있으며 dev는 개발을 위해 master로부터 분기된 브랜치이다. dev의 코드가 안정성이 검증되면 master 브랜치로 merge한다. 이 때 master 브랜치는 버전을 태그를 지정하는 것이 버전관리에 편리하다.

 

 2-2. feature

  feature 브랜치는 새로운 기능을 추가하기 위한 브랜치로 develop 브랜치로 분기되고 기능 개발이 종료되면 develop 브랜치로 merge되어 제거된다. 예를 들어 로그인 기능을 추가한다면 dev 브랜치에서 feature-login과 같은 형식으로 분기 가능하다. 나의 경우 이슈 번호를 붙여 feature-123 과같은 형식으로 작업했었던 경험이 있다.

 

 2-3. Release

  release 브랜치는 배포 준비를 수행하는 브랜치이다. 배포를 위한 기능개발이 완료되었다면 develop 브랜치에서 release 브랜치를 생성한다. release 브랜치에선 버그 수정, 매뉴얼 작성과 같은 배포를 위한 작업이 수행된다. 배포를 위한 작업이 종료되어 모든 동작이 정상 동작함을 확인한 후 develop와 master 브랜치에 merge한다. Release 브랜치는 release-1.2 와 같이 버전 번호를 반영하는 이름을 붙인다.

 

 2-4. hotfix

  제품(master 브랜치)에 즉시 해결해야할 오류가 발견되었을 때 master 브랜치에서 hotfix 브랜치를 작성한다. develop에서 브랜치를 만들기에는 develop의 기능들이 확실히 검증되지 않았기 때문에 검증된 master 브랜치에서 hotfix 브랜치로 분기하여 해당 부분만 수정하는 것이다. 오류 수정 후에는 master 브랜치에 merge 후 재배포한다. 이 때 hotfix 브랜치는 develop 브랜치에도 병합되어야 한다. hotfix 작업 후 제품이 재배포되었다면 1.2 -> 1.2.1과 같이 버전을 업데이트하고 master 브랜치에 태그를 지정하는 것이 좋다.

 

3. GitHub flow

GitHub flow

  GitHub flow는 master 브랜치만을 항상 유지하고, 필요에 따라 feature, bug 등 다양한 브랜치를 생성한 후 master 브랜치에 merge하는 것이다.

 

 3-1. Create Branch

  GitHub flow에는 master 외에는 dev, feature와 같이 정해진 branch 종류가 없다. 개발자가 자유롭게 자신의 의도를 가장 잘 나타낼 수 있는 브랜치를 작성한다. 예를 들어 refactor-authenication 과같은 이름도 가능하다.

 

 3-2. Pull Request

  GitHub flow의 개발과정에서는 언제든지 Pull Request를 열 수 있다. 완성된 코드가 아니더라도 조언이 필요할 때, 코드 리뷰가 필요할 때 Pull Request를 통해 다른 팀원들과 개발에 대해 토의할 수 있다. 토의를 진행하며 이에 따라 코드를 변경한 후 Commit한다. 토의가 끝나고 최종 코드가 완성되면 관리자가 Pull Request를 merge한다. 

 

 3-3. Deploy

  GitHub flow의 master 역시 Production으로 배포될 수 있는 브랜치를 의미하므로 master 브랜치로 merge되었다면 배포를 수행해야한다. 이 뿐만이 아니라 타 브랜치에서 Pull Request 이후 제품의 테스트를 위해 테스트 서버로의 배포를 수행 후 master로 merge하는 전략을 취할 수도 있다. 따라서 GitHub Flow에서는 배포 자동화를 권장한다. 

 

4. 비교

  이제 나의 프로젝트는 어떤 전략을 취하는 것이 좋을지 생각해보자. 내 생각엔 git-flow는 흐름이 복잡하지만 branch를 체계적으로 관리할 수 있다. 따라서 긴 호흡으로 개발을 진행하며, 주기적으로 배포하고 QA, 배포, hot fix를 수행할 수 있는 여력이 있을 때 git flow를 추천한다. 반대로 github flow는 작업 과정이 매우 단순하다는 장점이 있다. 따라서 Git을 처음 접하는 인원이 많거나 지속적으로 테스트하고 빠르게 배포되어야하는 서비스라면 github flow가 더 나아보인다.

 

---

git branch model: https://nvie.com/posts/a-successful-git-branching-model/

git branch 종류: https://gmlwjd9405.github.io/2018/05/11/types-of-git-branch.html

github flow: https://guides.github.com/introduction/flow/

영상: https://www.youtube.com/watch?v=jeaf8OXYO1g