[Git] Git 브랜치 전략 (Git Flow/GitHub Flow)

Git Flow를 사용해보고 싶다는 생각이 들어 앞으로의 프로젝트에 있어서 적용해보려고 시도해보았다.

물론 나의 개인프로젝트는 규모가 아주아주아아아주 작고 귀엽기 때문에 필요없긴 하지만 취업 후 나중엔 아주 유용할거라는 생각을 하며! (같은 생각으로 MSA도 미리 도전해보려고 한다.) 아무튼 삽질 시작!

 

 

Git의 장점 중 하나는 효율적인 Brach 관리로, 브랜치를 통해 기능추가, 버그 수정 그리고 브랜치들을 쉽게 Merge할 수 있다. 

그래서 나온 전략인 Git Flow를 사용하면 더 복잡하고 큰 소프트웨어 개발 작업도 아주 체계적으로 관리할 수 있다.

그러니까 쉽게 말해서 개발을 혼자하는게 아닌 이상 여럿이 함께 한다. 근데 메인 브랜치를 하나를 사용하면 내가 작업중인데 다른 누군가가 작업중인 파일을 만들지고 있고, 우연하게 잘 피해서 커밋하고 푸쉬하고 잘 했다고 해도 commit history가 다 섞여서 rollback하기도 어렵다 !!! 그러니까 난장판이 되는 거다.  그래서 우리는 브랜치 기능을 사용해서 다른 브랜치에 영향받지 않는 독립적인 환경에서 병렬적으로 개발 및 수정을 하는 것이다.

근데 이게 또 규칙없이 마구잡이로 각자 브랜치를 생성해서 개발을 진행하면 이게 왜, 어디서 사용된 브랜치인지 모른다. 다 물어보고 다닐 수도 없는 것이다. 그러면 이게 또 프로젝트가 난장판이 되는 것이다.

 

 

Git 브랜치 전략은 프로젝트의 Git 브랜치를 효과적으로 관리하기 위한 워크플로우인데 그 중에서 나는 Git Flow를 사용할 것이다. 

 

 

Git Flow

Git Flow

 

Git Flow에 조금이라도 관심을 가졌었다면 이 사진을 봤을 것이다.

뭐 Git을 사용해본 사람이라면 대충 이해는 될 것이다. (나 또한)

근데 막상 해보려고 하니 잘 못하겠던데,, 나만 그런 거일 수도,,,

아무튼 아주아주 쉽게 설명할 것이니 그러나 누군가 한명은 도움을 받길 바란다 !

 

Git Flow는 Vincent Driessen이 블로그에 2010년에 올린 A successful Git branching model 이라는 글이 인기를 끌며 대중적으로 사용되게된 브랜치 전략이라고 한다.

 

Git Flow는 크게 Main 브랜치, Develop 브랜치, Supporting 브랜치로 구분하여 브랜치를 관리한다. 이때, Supporting 브랜치는 또 다시 Feature 브랜치, Release 브랜치, Hotfix 브랜치로 나뉜다.

 

- master(Main)

- develop (Develop)

- feature (Supporting) 

- release (Supporting)

- hotfix (Supporting)

 

 

Main 브랜치와, Develop 브랜치는 개발 프로세스 전반에 걸쳐 항상 유지되는 브랜치이다. 반면, Supporting 브랜치는 필요할 때마다 생성되고, 역할을 다하면 삭제된다. Supporting 브랜치 덕분에 팀이 병렬적으로 업무를 할 수 있게된다. 

 

 

 

Master

 

master 브랜치는 배포될, 즉 사용자에게 제공되는 안정적인 버전의 소스코드를 포함하고 있다.

Main 브랜치는 프로젝트 시작 시 생성되며, 개발 프로세스 전반에 걸쳐 유지된다. master 브랜치의 HEAD는 최신 배포판의 소스 코드 버전이 있다. 그리고  배포된 각 버전을 태그(tag) 형태로 관리된다. 이 태그를 이용하여 각 릴리즈 버전의 소스코드를 빠르게 확인할 수 있다.

 

---

Develop

 

develop 브랜치에는 끊임 없이 새로운 기능들과 버그 수정들이 병합된다. 새로운 기능을 개발하는 여러 개발자들은 develop 브랜치를 기준으로 feature 브랜치를 생성해서 작업을 한다음 다시 develop 브랜치로 내용을 병합한다. 그러니까 다음 릴리스를 위한 개발이 이루어지는 곳으로, 개발자들이 함께 작업중인 기능들이 이 브랜치에서 통합된다. 따라서 develop 브랜치에는 끊임없이 새로운 내용들이 병합된다. (여기서 개발이 완료되면 Main 브랜치(master)로 merge 된다. ) 

 

---

Feature

 

feature 브랜치는 새로운 기능 개발을 개발하는 곳이다. develop 브랜치를 기반으로 생성되며 기능 개발이 완료된 다음 다시 develop 브랜치로 병합된다. (새로운 기능을 위한 Feature branch는 develop branch의 HEAD에서 생성)merge할때 주의점은 Fast-Forward로 머지하지 않고, Merge Commit을 생성하며 머지를 해주어야 한다. 이렇게해야 히스토리가 특정 기능 단위로 묶이게 된다. (PR)

 

네이밍 : feature/branch-name 

 

예를 들어, 게시판에 새로운 기능으로 댓글 작성 기능을 추가하려고 한다면 'feature/comment' 브랜치에서 해당 기능을 개발한다. 개발이 완료되면 develop 브랜치로 PR요청을 해서 merge한다. 

---

Release

 

release 브랜치는 다음 버전의 게시판을 릴리스하기 전에 여러 작업이 이루어지는 곳이다. 그러니까 배포하기 전에 준비를 위한 브랜치라고 이해하면 된다. Develop 브랜치에서 생성하여 버전 이름과 같은 데이터를 수정하거나 배포하기 전에 버그를 수정하기 위해 사용된다. (기능이 개발되어 develop 브랜치로 병합되면 그 이후 release 브랜치를 생성함)

배포 준비가 완료되었다면 Master와 Develop 브랜치에 둘다 머지한다. 이때, Master 브랜치에는 태그를 이용하여 버전을 표시한다.

Release 브랜치를 따로 사용함으로써, 배포 업무와 관련없는 팀원들은 병렬적으로 Feature 브랜치에서 이어서 기능을 개발할 수 있게된다. (Realease 브랜치가 생성된 이후 반영된 수정사항들은 develop 브랜치에도 반영된다)

 

네이밍 : release/v1.1 

---

Hotfix

 

Hotfix 브랜치는 정기적인 릴리즈 이외에 긴급하게 수행되어야 할 버그 수정을 반영하기 위해 생성되는 브랜치로 이미 배포된 버전에 문제가 생겼을 때 사용하는 branch이다. 정기적인 릴리즈 계획과 별도로 치명적인 버그가 발견되어 다음 릴리즈 프로세스를 기다릴 수 없을 정도로 (그냥 최대한 빨리 수정해야할 때) 이 브랜치를 사용한다. hotfix 브랜치는 master 브랜치를 기반으로 생성된다. 생성된 hotfix 브랜치에 긴급 패치들이 반영된다. 이 후 다시 master 브랜치로 병합되고 태그를 생성한다. 마찬가지로 수정 사항은 develop 브랜치로도 병합되어 긴급 수정 사항이 이후 릴리즈에도 반영되도록 한다. Release 브랜치와 마찬가지로 Hotfix 브랜치를 따로 사용함으로써, hotfix 업무와 관련없는 팀은 병렬적으로 기능 개발을 할 수 있다.

 

네이밍 :  hotfix/v1.0.1

 

 

 

설치 및 실습 (Mac)

1. 설치 및 초기화

// 설치
brew install git-flow-avh

// 초기화
git flow init

 

2. 실습 (새로운 기능 개발)

# 새로운 기능 브랜치 생성
git flow feature start feature_example

# 기능 개발 (예: 새 파일 생성)
echo 'Hello, Git Flow!' > new_file.txt
git add new_file.txt
git commit -m "Add new_file.txt"

# 기능 완료 및 통합
git flow feature finish feature_example

 

3. 실습(릴리즈 생성)

# 릴리스 브랜치 생성
git flow release start release_v1.0

# 릴리스에서 필요한 작업 수행 (예: 버전 번호 업데이트)

# 릴리스 완료
git flow release finish release_v1.0

 

4. 실습(버그 수정)

# 버그 수정 브랜치 생성
git flow bugfix start bugfix_example

# 버그 수정 작업 수행 (예: 버그 수정 파일 수정)
echo "Fixed bug" >> new_file.txt
git add new_file.txt
git commit -m "Fix bug in new_file.txt"

# 버그 수정 완료
git flow bugfix finish bugfix_example

 

5. 실습(릴리즈 후 Push)

git push origin master
git push origin develop
git push origin --tags

 

 

---

 

 

 

이렇게 각 브랜치는 특정한 역할을 수행하며, Git Flow를 통해 이러한 브랜치 간의 효율적인 협업과 개발 주기를 유지할 수 있다.

근데 내가 이걸 웹 프로젝트에 적용해보려니까 잘 안됐다.. 릴리즈와 hotfix 브랜치가 사용되지 않기도 했고 굳이.. 인 느낌이 들어 찾아보니 웹에는 맞지 않더라 ......... 앱 프로젝트에 적합한 것이었다 ㅎ 헤헤 (그래도 괜찮다.. Flutter를 이용해서 취미로 앱도 만들고 싶으니까 ..)...

아무튼 깃 플로우 안녕 ..

 

그래서 찾아낸 GitHub Flow

 

대부분의 웹 애플리케이션은 여러 버전을 관리하지 않고, 가장 최신 버전 하나만을 사용자가 사용하게 된다. 개발팀이 소규모 애자일 팀이고, 제품이 단일 릴리즈 버전밖에 존재하지 않는다면 Github Flow가 적절하다고 한다 !!!  (+ Git Flow보다 훨씬 간단함)

 

 

---

GitHub Flow

Github Flow

 

Github Flow는 이름 그대로 Github 환경에서 사용하기 적합한 브랜치 전략으로 주로 웹 기반 호스팅 서비스인 GitHub에서 개발자들이 사용하는 워크플로우로서, 지속적인 통합과 배포에 중점을 둔다. 그리고 자동화를 적극 활용하기도 한다.

 

 

 

Main(Master) Branch

 

항상 Stable한 상태여야 한다. 즉, Main의 모든 커밋은 언제 배포하든 문제 없어야하고, 언제든 브랜치를 새로 만들어도 문제가 없어야 한다. Main 브랜치의 모든 커밋은 빌드가 되고, 테스트를 통과해야한다. 

---

Topic Branch

 

새로운 기능을 개발할 때에는 Topic 브랜치를 Main 브랜치로부터 생성한다. (Git Flow의 Feature 브랜치와 동일한 역할을 한다. 또한 별도로 Hotfix 브랜치를 관리하지 않으며, 버그 수정도 Topic 브랜치에서 진행한다.)

이때, Topic 브랜치의 이름은 기능을 설명하는 명확한 이름으로 네이밍 해야한다 !!!

 

Topic 브랜치의 커밋은 기능이 완성되지 않았더라도 꾸준히 Push 한다. (코드가 유실되는 것을 막아준다.) 이것보다 더 중요한 이유는 꾸준히 Push 함으로써 구성원 모두가 끊임없이 커뮤니케이션 할 수 있게 해준다.

 

Github에서는 PR(Pull Request)라는 유용한 기능이 존재한다. 개발자는 기능을 개발하는 중 언제든 상관없이 PR을 개설할 수 있다. 심지어 코드의 변경이 없더라도 아이디어를 공유하고 싶을 때에도 PR을 개설한다. 개발자들은 개설된 PR에서 토론을 하고, 코드의 특정 라인을 선택해 코멘트를 남겨 코드리뷰를 주고 받는다.

 

토론과 리뷰가 끝났으면, 다른 사람들의 동의(Approve)를 얻고 Main 브랜치에 자신의 Topic 브랜치를 머지한다. 단, 이때 Topic 브랜치는 자동화된 CI 빌드를 통과해야 merge가 가능하다.

 

 

실습 

 

1. 기능 개발

작업을 시작하기 전에 항상 main 브랜치로 이동하여 최신 코드를 가져온다.

git checkout main
git pull origin main

새로운 기능이나 수정할 내용을 위한 새로운 브랜치 생성

git checkout -b feature/new-feature

 

2. 커밋하기

변경 사항을 작업 중에는 작은 단위로 자주 커밋한다 !!!

* 커밋 컨벤션을 이용하면 더욱 효과적이다.  https://myste-leee.tistory.com/108

git add .
git commit -m "Implement new feature"

 

3. 원격 저장소로 Push

변경사항이 완료되면 해당 브랜치를 원격 저장소로 푸시한다.

git push origin feature/new-feature

 

4. PR (Pull Request) 생성

GitHub에서 해당 브랜치로 이동해서 PR을 생성한다. (코드 변경에 대한 설명과 함께 다른 개발자들이 리뷰할 수 있도록 공유)

 

5. 리뷰 및 병합

PR에서 리뷰하고, 완료되면 main 브랜치로 Merge한다. 

 

6. 배포

main 브랜치에 변경 사항이 merge되면 CI/CD 파이프라인이 실행되어 자동으로 테스트하고 배포하도록 한다. 

 

 

 

 

 

 

 

 

 

정리하고 보니 내가 하던거네 헤헷 다음에는 Git Action으로 CI/CD 파이프라인하는 법이나 삽질해봐야겠다.