TIL #9 - git branch 전략

 

TIL #9 - git branch 전략

 

 

 

 

 

📜 목표

• git branch 전략의 개념에 대해 이해한다.
• 어떠한 git branch 전략을 어떠한 상황에 적용하면 좋은지에 대해 이해한다.

 

---

 

Git Branch 전략이란?

 

여러명의 개발자가 하나의 저장소를 사용하면서 개발을 진행할 때 생기는 문제점이나 불편한 점들을 해소시킬 수 있는 방법이다.

 

당장, 팀프로젝트만 하더라도 branch가 하나밖에 없는 상황이라면 내가 개발한 코드와 같은 팀원이 개발한 코드가 뒤죽박죽 엉켜버리게 된다. 따라서, 개발 환경에 맞는 각각의 독립적인 branch를 가지고 이를 나중에 합치는(merge)식으로 진행하게되면 이러한 문제점들을 해결할 수 있게 된다. 한직선으로만 이루어져있는 flow를 가진 방식이 아닌 여러 flow의 과정들로 이루어져 최종본을 산출해내는 그러한 전략이라 할 수 있다.

 

 

대표적인 Git Branch 전략으로는 다음과 같은 것들이 있다.

• Git flow
• Github flow
• Gitlab flow

 

이에 대해서 알아보자.

---

 

Gti Flow

 

 

 

메인 브런치

• master, develop

 

보조 브런치

• feature, release, hotfix

 

 

 

 

1. feature (기능 구현 branch)

 

기능구현을 주로 담당하고 있는 branch이다. 

보통 feature/{구현한 기능명}의 명칭을 부여하며, 개발이 완료되면 develop branch로 merge 한다. 

 

 

 

2. develop (메인 branch)

 

개발을 진행하면서 메인으로 삼는 branch이다. feature 브랜치가 머지되는 장소이고 기능을 다 갖추게 되면 release branch로 merge한다.

 

 

3. realease (배포 branch)

 

배포를 위해 준비 과정을 거치는 branch이다. QA와 테스트를 진행한다.

QA와 테스트를 통해 오류 수정이 생겼다면 develop branch에도 merge한다.

최종적인 배포를 위해 테스트들을 실행하고 완료가 될 시 master branch로 merge한다.

 

 

 

4. hotfix (버그 수정 branch)

 

배포가 된 소스에 버그가 생겼을 시 사용되는 branch이다. 이 branch에서 발생한 버그들을 수정하고 수정이 완료된 소스들은 develop, release, master branch에 반영한다.

 

 

5.master (최종본 branch)

 

출시 가능한 상태만을 관리한다.

최종적인 배포 소스를 관리하게 되는 branch이다.

 

 

 

 

Gti Flow의 장단점

 

 

장점

• 소스 코드 관리에 용이함.
• 명시적으로 버전을 관리해야할 때 적합하다.

 

단점

• release와 master의 구분이 모호하다.
• 각 브런치의 담당이 명확하게 나눠진 만큼 전체적인 흐름은 복잡한 편이다.
• 웹 어플리케이션 개발에는 다소 적합하지 않다.

 

 

---

 

Github flow

 

 

앞서 소개한 Git flow는 다소 복잡한 전략이다. 따라서 탄생하게 된 것이 바로 이 Github flow이다.

 

이 전략은 master branch 하나만을 가지고 있다. 간단한 구조가 핵심인 전략이다.

 

또한, 자동화 개념을 적극 활용한다.

 

 

 

▶️ 개발 과정

1. master branch가 중심이 되는 branch. 기능 개발, 버그 수정등의 모든 과정은 이 master brach에서 생성하여 만든다.

• 브랜치명은 간결하고 정확하게 작성한다.
• master branch는 항상 stable하고 최신이어야 한다.

 

2. 기능 개발, 버그 발생에 대한 것은 issue를 작성하고 팀원 끼리 

• 원격 branch로 수시로 push한다. 이를 통해 모두에게 현재 진행상황을 알릴 수 있다.
• 커밋 메시지는 상세하게 적는다.
• 로컬에서 소스코드가 삭제되는 상황이 예기치못하게 발생하더라도 쉽게 복구할 수 있게 해주는 이점도 있다.

 

3. 코드 작성에 있어 도움이나 코드리뷰를 필요로하거나 merge를 할 단계라면 PR을 생성하여 공유한다.

• 이 단계에서 충분한 검토와 정확한 검증이 이루어져야 한다.

 

4. 모든 검토를 마치고 merge하기 전 최종 테스트를 진행한다.

 

 

5. 테스트를 통과하게 되면 master branch로 merge한다.

• master로 머지되고 푸시었다면 즉시 배포한다. (GitHub flow의 핵심)

 

 

 

 

 

장점

•  Git Flow보다 간단한 구조이다.
• 자동화 활용
• GitHub에서 사용하기 적합하다.

 

단점

• 팀원간의 충분한 의사소통 과정이 이루어지지 않는다면 예기치 못한 오류가 발생할 수 있다.

 

 

---

 

 

Gitlab flow

 

 

 

Git flow는 너무 복잡하지만, GitHub flow는 너무 단순한 부분이 있다. 

GitHub flow의 간단한 배포 이슈를 보완하기 위해 나온  방식이다.

복잡성은 줄이지만 효율은 높이는 것이 목적인 전략이다.

 

 

 

1. feature branch

 

모든 기능 개발이 이루어지는 곳이다. 

 

기능 개발이 완료되면 merge request를 통해 팀원간의 코드리뷰 및 피드백을 받는다.

 

이후 수정사항이 더이상 없다면 master branch로 merge한다.

 

 

 

2. master branch

 

다른 전략의 master branch와 달리 최종 브런치가 아니다. feature branch에서 merge된 기능들을 테스트하고 배포 준비를 끝마치면 production branch로 merge한다.

 

 

3. production branch

 

배포를 담당하는 branch이다. git flow의 master branch와 동일한 역할을 한다.

 

stable한 소스코드만을 merger 받는다.

 

 

4. pre-production branch

 

master - production 브런치 사이에 생성하여 변경된 사항을 test하고 병합한다.

 

이는 개발한 부분을 시간을 두고 반영하게 된다.

 

 

 

 

장점

• GitHub flow의 단점인 안정성과 배포 시기 조절에 대해 보완할 수 있는 전략이다.

 

 

 

---

👨‍💻 마무리

팀 프로젝트를 진행하면서 소스코드 관리를 위해 어떤 전략을 세워야할지 공부가 필요했던 부분이였다.

 

우리가 진행하고 있는 프로젝트에는 어떠한 전략을 사용하는 것이 좋을까 생각하게 된 계기가 되었다.

 

너무 명확한 것이 무조건 장점이 될 수 는 없겠구나라는 것도 새삼 깨닫고 현상황에 맞는 적당한 관리를 통해 효율적인 개발을 진행하도록 해야겠다고 느꼈다.

 

 

 

 

 

 

 

 

 

[참고 자료]

 

http:// https://tecoble.techcourse.co.kr/post/2021-07-15-git-branch/

https://hudi.blog/git-branch-strategy/

https://ujuc.github.io/2015/12/16/git-flow-github-flow-gitlab-flow/

https://inpa.tistory.com/entry/GIT-%E2%9A%A1%EF%B8%8F-github-flow-git-flow-%F0%9F%93%88-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EC%A0%84%EB%9E%B5

https://gyoogle.dev/blog/github/Git%20vs%20GitHub%20vs%20GitLab%20Flow.html