[Git] 브랜칭 전략

Git branch 전략을 알아보자

1. Git Flow

2. Github Flow

3. GitLab Flow

Git Flow란

고수준의 저장소를 관리하기 위한 Git의 확장 모듈이다.

터미널 환경에서도 사용할 수 있으며 보통 Git GUI 프로그램인 SourceTree에서 지원하여 사용되고 있다.

 

Git-flow는 브랜치를 크게 4가지로 나누어 개발하는 전략이다.

• 마스터/메인 브랜치(Main branch)

• 피처 브랜치(Feature branch)

• 릴리스 브랜치(Release branch)

• 핫픽스 브랜치(Hotfix branch)

가장 중심이 되는 브랜치는 master와 develop 브랜치이다
.merge된 feature, release, hotfix 브랜치는 삭제하도록 한다.

---

Master(Main) branch

제품으로 배포/출시 할 수 있는 상태만을 관리하는 브랜치이다.

가장 퓨어해야하는 영역이다.

 

Develop branch

다음 출시 버전을 개발하는 브랜치이다.

기능 개발을 위한 브랜치들을 병합하기 위해 사용하는 브랜치다.

원하고자 하는 기능을 추가하고 디버깅(QA)까지 하여 문제없이 동작된다고 판단될 경우

이 브랜치를 main브랜치에 Merge 한다.

첫번째 단계는 master 브랜치에서 develop 브랜치를 생성하고 서버로 푸시하는 것이다.

 

만약 1.0 카카오톡을 메인에서 클라이언트들에게 배포를 마친 다음 개발자들은 무슨 일을 해야할까?

개발자는 이제 2.0을 준비하면 된다. 그동안 개발자들은 Devlop 브랜치에 PR을 계속 날리고 있을것이다.

따라서 실제로는 main에서 feature를 따지 않고 Devlop 에서 브랜치를 따서 사용해야 한다.

---

Feature branch

기능을 개발하는 브랜치로 develop 브랜치로부터 분기하여 사용한다.

그 기능을 완성할때까지 유지하며 완성하게 될 경우 develop로 merge한다.

feature 브랜치는 절대로 master 브랜치와 직접적으로 상호작용하지 않는다.

---

Release branch

develop 브랜치가 출시를 위한 개발이 완료되었다 판단될 경우 develop 브랜치로 부터 Release 브랜치를 분기하여 사용한다.

Release 브랜치는 출시를 위한 준비를 하는 브랜치로 기능 개발을 추가 할 수 없으며 버그 수정 및 QA용도로 사용된다.

출시가 가능하다 생각되면 master 브랜치로 병합하고 master 브랜치에 버전 태그를 추가한다.

Release 브랜치에서 점검하고 발견한 버그 수정사항은 develop 브랜치에도 적용해줘야 한다. 

즉, Release 브랜치 개발이 완료되었다면 master 와 develop 브랜치와 병합 시킨다.

---

Hotfix branch 

출시한 버전에서 긴급 수정이 필요해야할 경우 master 브랜치에서 분기하여 사용한다.

따라서 버그를 수정하는 동안 devleop 브랜치를 통해 하던 일을 계속 할 수 있다.

이때 만든 Hotfix 브랜치의 변경사항은 master 와 develop 브랜치와 병합시킨다.

---

Github Flow란

Git Flow가 Github에서 사용하기 복잡하다는 의견으로 나온 브랜칭 전략이다.

master 브랜치에 대한 Role만 정확하다면 나머지 브랜치들에 대해서는 관여하지 않는다.

즉, Git Flow에서 사용한 다른 브랜치들을 구분하지 않는다. 대신 Pull request 기능을 사용하여 병합하는 것을 권장한다.

(Github Flow는 자동화의 개념이 들어가 있어 수시로 배포가 일어나며 자동회되어있는 프로젝트에 유용하다.)

---

Github Flow를 사용하는 방법은 Git Flow와 비교해봤을때 상대적으로 굉장히 간단하다.

1. master 브랜치는 어떤 때든 배포가 가능한 상태로 엄격한 Role이 함께 적용되어 사용되어야 한다.

2. master를 제외한 나머지 브랜치들에 대해 관여하지 않기때문에 브랜치의 이름을 명확하게 작성해야 한다.

3. 원격(Remote) 브랜치로 수시로 push를 한다.

git flow 와 가장 상반되는 방식이다. 항상 원격에 자신이 하고 있는 일들을 올려 다른 사람들도 확인할 수 있도록 해준다.
이 방법의 좋은 점은 하드웨어에 문제가 발생하여 작업하던 부분이 없어지더라도 원격지에 있는 소스를 받아서 작업을 할 수 있도록 해준다.

 

4. Pull request를 생성하여 도움과 코드 리뷰를 받을 수 있다.

Github Flow에서는 PR 리뷰를 통해 master에 merge 하기 전 충분한 테스트와 논의를 거쳐 merge해야 한다.

왜냐하면 master 브랜치로 언제든지 배포가 가능해야 하기 때문이다.

 

5. master로 머지되고 푸시되었을 때는 즉시 배포되어야 한다.

GitHub Flow의 핵심으로 master로 merge가 일어나면 hubot*을 이용하여 자동으로 배포가 되도록 설정해놓는다.

여기서 hubot이란 Github 사내용으로 제작된 쳇봇을 말한다.(Node 기반으로 Slack에 최적화되어있다고 한다)

---

GitLab Flow

Github에서 말하는 flow는 너무나도 간단하여 배포, 환경 구성, 릴리즈, 통합에 대한 이슈를 남겨둔 것이 많았다. \

그것을 보안하기 위해 GitLab Flow 라는 것도 있음을 알고 추후 다뤄보도록 하자.

 

출처

Git 브랜칭 전략 : Git-flow와 Github-flow :: 갓우리코딩 (tistory.com)

Git 브랜칭 전략 : Git-flow와 Github-flow

TIL#121 Git-flow / Github-flow (velog.io)

TIL#121 Git-flow / Github-flow

잘 밤에 쓸데없는 생각하기... / Git flow, GitHub flow, GitLab flow (ujuc.github.io)

Git flow, GitHub flow, GitLab flow