Git Branch 전략

SSAFY에서 프로젝트를 진행하다 처음으로 Git을 제대로 써본 것 같아 정리할 겸 공유 차원에서 Git Branch 전략에 대해 작성하기로 마음먹었다.

 

참고로 SSAFY에서는 보안 문제 때문에 Git Lab에서 Private 하게 작업했지만 원리는 같으므로 Git Hub에서도 똑같이 적용된다.

 

본 포스팅은 기본적으로 Git이 설치되어 있고 IDE와 Repository가 연동되어 있단 가정하에 설명하는 것이며 코드 수정부터 Merge까지 익숙하지 않은 사람들은 밑에 있는 더보기를 확인하면 될 것이다.

 

Git은 Local Git과 Remote Git이 있다.

 

Local Git은 말 그대로 Local, 즉 자신 PC의 Git 저장소를 뜻하고 Remote Git은 Git Hub 나 Git Lab 같이 Online Server를 뜻한다.

 

기본적인 원리는 다음과 같다.

1. Local Git을 수정하기 전, Remote Git의 코드를 Pull 받아와서 Local Git에 합친다.

2. 수정한 코드를 Local Git에 합친다.

3. Local Git을 Remote Git으로 Push 한다.

 

이때 Branch란 개념이 있는데 처음엔 Main Branch로 시작한다.

 

필요에 따라 여러 가지 Branch를 생성할 수 있고 Main에 병합하는 방식으로 진행하는데 이때 조심해야 할 점은 같은 파일을 서로 다른 사람이 수정하게 되면 충돌이 나므로 상호 간의 의사소통이 중요하다.

 

필자의 경우를 기준으로 설명하겠다.

 

Git Bash를 이용해 해당 프로젝트 폴더로 이동한다.

 

작업을 시작하기 전 Remote Git으로부터 작업된 코드들을 Pull 받아온다.

git pull origin main

 

이후 코드 수정 작업을 하면 Local Git에 추가한다. (변경된 파일을 전부 추가하는 코드)

git add .

 

Local Git에 추가한 내용을 Commit 하며 Commit Message를 작성한다.

이때 Commit Message는 미리 약속된 형식으로 작성하는데 필자는 "Feat : 작성 내용" 이런 식으로 통일했었다.

git commit -m '커밋 메시지'

 

Local Git에 Commit 했다면 이제 Remote Git으로 Push 하면 끝이다.

git push origin main

 

Git Branch 전략엔 Git Flow, GitHub Flow, GitLab Flow 이렇게 3가지가 있다.

 

이 전략들은 Branch를 어떻게 구성하고 사용하는지에 따라 나뉘므로 Git Flow부터 설명하도록 하겠다.

 

Git Flow 전략

---

Git Flow 전략에는 5가지 Branch가 있다.

 

Feature, Develop, Release, Hotfix, Master Branch이며 Master와  Develop이 Main Branch라 생각하면 된다.

 

실제 우아한 형제들에서 사용하고 있으며 아래의 그림이 가장 Git Flow 전략을 잘 나타낸 것 같다고 한다.

 

Git Flow

 

Feature Branch는 단위 기능을 구현하여 Develop Branch에서 파생되고 머지한다.

 

Develop Branch는 개발의 중심이 되는 Branch로써 Feature Branch로 몸집을 키워나간다고 생각하면 된다.

 

Release Branch는 개발한 내용을 배포하기 위해 준비하는 Branch로 충분한 테스트와 검증을 통해 오류를 수정하고 수정한 내용은 Develop Branch로, 완료되면 Master Branch로 반영한다.

 

Hotfix Branch는 배포된 내용에서 버그가 발견될 경우 Master로부터 분기되는 Branch로 버그를 수정하고 Develop과 Release, Master Branch에 반영한다.

 

Master Branch는 배포되어 서비스하는 가장 핵심의 Branch다.

 

필자는 Git Flow를 똑같이 진행하진 않았지만 Front, Back, Develop, Main Branch로 나눠서 코드 관리를 하였으며 Git을 많이 써본 팀원이 있어 필자가 GitLab에 Merge Request를 생성하면 해당 팀원이 검수하여 Merge 하는 방식으로 프로젝트를 진행하였다.

 

GitHub Flow 전략

---

GitHub Flow는 Git Flow 전략이 GitHub에서 사용하기엔 너무 복잡하다고 해서 나온 Branch 전략이다.

 

GitHub Flow

 

Master Branch는 배포되는 Branch로 최신 상태로 유지하며 안정적인 상태를 위해 Merge 하기 전 충분한 테스트 과정을 거쳐야 한다.

 

모든 Branch는 Master Branch로부터 파생되며 해당 Branch의 역할과 커밋 메시지를 명확하게 작성해야 한다.

 

Git Flow 전략과는 다르게 Feature나 Develop Branch가 존재하지 않기 때문에 기능 구현인지 버그 수정인지 확실히 작성해야 하기 때문이다.

 

또한 파생된 모든 Branch가 Master Branch로 Merge 되기 때문에 Pull Request를 통해 코드를 공유하고 리뷰를 받을 수 있도록 해야 한다.

 

GitLab Flow 전략

---

GitLab Flow는 너무 단순한 GitHub Flow 전략을 복잡한 이슈에 대해 보완하기 위해 나온 전략이다.

 

GitLab Flow

 

먼저 GitLab Flow에서는 모든 기능이나 버그 수정을 Master Branch에서 파생된 Feature Branch에서 작성하고 Merge 한다.

 

Master에서 충분히 테스트를 하고 Staging을 위해 Pre-Production Branch로 Merge 한다.

 

Pre-Production Branch에서는 Test Server에 배포하여 테스트하거나 시간을 두고 Production Branch로 Merge 한다.

 

Production Branch는 배포하기 위한 Branch다.

 

GitLab Flow 전략은 너무 복잡하지도, 너무 단순하지도 않은 중간 정도의 전략이라고 생각하면 된다.