[Git] 브랜치 전략 - Github flow

브랜치 전략이란?

브랜치 전략이란 여러 개발자가 1개의 저장소를 사용하는 환경에서 효과적으로 활용하기 위해 나온 개념입니다. 브랜치 생성, 병합 등의 git 구조를 활용해 보다 효율적으로 소스를 관리하고 협업을 원활하게 할 수 있도록 도와줍니다.

브랜치 전략은 Git flow, GitLab flow, Github flow 3개로 보통 사용하고 있습니다.

Github flow

github flow는 git flow가 github에서는 사용하기가 복잡하다고 하여 나온 전략으로 위 3개의 전략 중 가장 간단한 전략입니다.

Github flow

Github flow 예제

위의 flow가 단순한 만큼 사용법도 단순합니다. master 브랜치의 역할만 확실히 지켜진다면 다른 브랜치에 대해 관여를 하지 않습니다. 즉, master 브랜치를 제외하고 feature, hotfix, bugfix 등등의 브랜치를 구분하지 않습니다. 또한 pull request 기능을 사용하도록 권장을 하며 수시로 배포가 발생하므로 CI/CD가 자동화 되어 있는 환경에서 사용하기 좋습니다.

사용법

master 브랜치는 언제든지 배포 가능 상태 유지

master는 항상 최신 상태를 유지해야 하며 production(live) 환경에 배포할 수 있어야 합니다. 또한 해당 브랜치에 merge를 하기 전에 충분한 테스트를 거쳐야 합니다.

브랜치 생성 시, 이름을 명확히 작성

브랜치는 항상 master 브랜치에서 생성해야 합니다(큰 이유가 없다면). 즉, git flow에 존재하는 feature 브랜치나 develop 브랜치가 존재하지 않습니다. 그러므로 새로운 기능 추가, 버그픽스와 같은 브랜치 이름은 자세하게 어떤 일을 하는지에 대해 작성해야 합니다.

• jira와 같은 툴을 사용하고 있다면 JIRAKEY-브랜치명 으로 지어주면 좀 더 수월할 것 같음

origin 브랜치에 수시로 push

내 작업물을 수시로 서버에 push하여 다른 사람들이 확인할 수 있도록 합니다. 이는 github 뿐만 아니라 git 사용에 공통적인 부분입니다.

도움, 피드백, master에 merge를 준비할 때 Pull Request를 생성

Pull Request는 코드 리뷰를 도와주는 시스템으로 가장 핵심입니다. 내가 짠 코드를 공유하고 팀원들에게 리뷰를 받고 완료되었다면 master 브랜치로 merge를 진행합니다.

master 브랜치에 merge가 되고 push가 되었을 때, 즉시 배포

여기서 CI/CD를 자동화하여 master 브랜치에 배포되었을 때, 테스트와 빌드를 자동으로 거친 후 이상이 없다면 production에 자동으로 반영이 되어야 합니다.

해당 전략은 master 브랜치에 merge가 수시로 발생하므로 수동으로 하기엔 적절하지 않습니다.

merge한 이후 요청한 브랜치는 삭제

merge한 이후 요청한 브랜치를 삭제하는 것은 작업이 완료되었음을 나타내며 팀원이나 내가 실수로 오래된 브랜치를 사용하는 것을 방지할 수 있습니다.

브랜치 삭제는 간단하게 진행할 수 있으며, 삭제한 브랜치를 복원하는 것 또한 간단하게 처리할 수 있습니다.

merge가 완료된 브랜치 삭제

삭제한 브랜치 복원

요약

Github flow는 CI/CD 자동화가 이뤄진 소규모 팀에서 사용하기 좋은 전략입니다. Github이 제공하고 있는 Pull Request와 Github Action을 사용하여 간단하게 전략을 짤 수 있어 빠르게 도입하기가 좋습니다.