이번에 팀플을 하게 되었는데 깃,깃허브 사용법이 헷갈려서 이번에 정리 해볼려고 한다.

깃(Git) 브랜치 전략

여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용하기 위한 work-flow

📌 Git-Flow 전략

기본적으로 5가지로 분류된다.

• feature
• develop
• release
• hotfixes
• master

5가지 중, 항시 유지되는 메인 브랜치 master, develop 2가지와 merge가 되면 사라지는 보조 브랜치 release, hotfixes,feature가 존재한다.

🤔 주로 작은 프로젝트는 feature에서 작업을 하고 -> develop에 PR을 날리고 master 브랜치로 합치는 방식을 많이 사용하는 것 같다.(제 개인적인 생각이니 틀린 부분이 있으면 말씀해주세요....)

Git-Flow Branch

• master : 라이브 서버에 제품으로 출시되는 브랜치
• develop: 다음 출시 버전을 대비하여 개발하는 브랜치
• feature: 추가 기능 개발 브랜치, develop 브랜치에 들어간다.(작업 완료 시 develop에 PR)
• release: 다음 버전출시를 준비하는 브랜치, develop 브랜치를 release 브랜치로 옮긴 후 QA,테스트를 진행하고 master브랜치로 합친다.(릴리즈 완료 후 develop에도 변경사항 동기화)
• hotfix: master 브랜치에서 발생한 버그 수정하는 브랜치

메인 브랜치

master 브랜치와 develop 브랜치 두 종류를 말한다. 요즘에는 인종차별(?) 문제로 master 브랜치가 아니라 main 브랜치라고 부르고 사용하는 경우가 많은 것으로 알고 있다.

• master 브랜치는 배포 가능한 상태만을 관리하는 브랜치
• develop 브랜치는 다음에 배포할 것을 개발하는 브랜치

보조 브랜치

• feature 브랜치
• develop에서 뻗어나오고 합쳐지는 브랜치로 기능 추가를 할 때 사용
• 기능을 다 완성할 때까지 유지, 다 완성되면 develop 브랜치로 merge 하고 해당 코드를 사용할지 판단한다.

릴리즈 브랜치

배포를 위한 최종적인 버그 수정등의 개발을 수행하는 브랜치

핫픽스 브랜치(hotfix)

배포한 버전에서 긴급한 수정이 필요할 때, master 브랜치에서 분리하는 브랜치

• hotfix 브랜치에서의 변경 사항은 develop 브랜치에서도 merge 하여 문제가 되는 부분을 처리해야한다.
• 보통 버그를 해결하면 제거하는 일회성 가지

😭 팀플을 하다가 팀원 분이 머지를 하다가 내 코드가 사라져서 hotfix 로 고쳐야 하는 부분이 있었는데 빠르게 해야해서 당황해서 hotfix 브랜치를 생성안하고 dev 브랜치에서 고쳐서 그냥 push 했었다... 이건 진짜 반성을 해야겠다.

Git flow 흐름

• master 브랜치와 develop 브랜치는 둘 모두 운용을 해야한다.
• 나머지 feature, release, hotfix 브랜치는 사용하지 않는다면, 지우더라도 크게 상관이 없다.
• 대부분의 작업은 develop 브랜치에 취합한다고 생각하면 되고, 테스트를 해보고 master 브랜치로 merge 를 진행하면 된다.

1) 신규 기능 개발

• 개발자는 develop 브랜치로부터 본인이 신규 개발할 기능을 위한 feature 브랜치를 생성
• 기능이 완성되면 develop 브랜치로 merge

2) 라이브 서버로 배포

• feature 브랜치들이 모두 develop 브랜치에 merge 되었다면 QA를 위해 release 브랜치를 생성
• release 브랜치를 통해 오류가 확인된다면 release 브랜치 내에서 수정을 진행
• QA와 테스트를 모두 통과했다면, 배포를 위해 release 브랜치를 master 브랜치 쪽으로 merge
• 만일 release 브랜치 내부에서 오류 수정이 진행되었을 경우 동기화를 위해 develop 브랜치 쪽에도 merge를 진행

🤔 QA란?

• 품질 검증

3) 배포 후 관리

📌 Github Flow

자동화 개념이 들어가 있다라는 큰 특징이 존재하며 만일 자동화가 적용되어 있지 않은 곳에서만 수동으로 진행

브랜치 생성

• 기능 개발, 버그 픽스 등 어떤 이유로든 새로운 브랜치를 생성하는 것으로 시작
• 브랜치 이름을 통해 의도를 명확하게 드러내는 것이 매우 중요
• Git-flow와는 다르게 feature 브랜치나 develop 브랜치가 존재하지 않는다.

개발, 커밋, 푸쉬

• 브랜치와 같이 커밋 메세지에 의존해야 하기 때문에, 커밋 메세지를 최대한 상세하게 적어주는 것이 중요

PR(Pull Request) 생성

• 피드백이나 도움이 필요할 때, 그리고 merge 준비가 완료되었을 때는 pull request(PR)를 생성

github flow vs git flow

• 1개월 이상의 긴 호흡으로 개발하여 주기적으로 배포, QA 및 테스트, hotfix 등 수행할 수 있는 여력이 있는 팀이라면 git-flow가 적합
• 수시로 릴리즈 되어야 할 필요가 있는 서비스를 지속적으로 테스트하고 배포하는 팀이라면 github-flow 와 같은 간단한 work-flow가 적합

참고

• [GIT] 📈 깃 브랜치 전략 정리 - Github Flow / Git Flow
  
• How to use git flow