IT[Study] 깃 브랜치 전략(git-branch-strategy)

 

브랜치(branch)

나뭇가지라는 뜻으로, 버전 관리 시스템에서는 나무가 가지에서 새 줄기를 뻗듯이 여러 갈래는 퍼지는 데이터 흐름을 가리키는 말로 사용한다.

---

❔브랜치가 필요한 이유

 

 브랜치를 따로 생성하지 않고 메인 브랜치에서만 작업을 한다고 가정하자. 이 곳에 기능을 개발하면서 커밋을 진행하게 될 것이다. 만약 여러명이서 협업을 한다고 한다면, 이렇게 한 곳에서 개발을 하다가 다른 사람이 작성한 코드를 건드린다거나(수정, 삭제 시 문제 발생), 커밋(롤백 시 문제 발생) 또한 뒤죽박죽이 될 것이다.

 

 브랜치를 사용하면 협업 시 독립적인 환경에서 기능을 개발할 수 있고, 버그를 수정할 수 있게된다. 마치 프로젝트 폴더를 복사해서 각자 작업하는 것처럼 말이다. 즉, 협업 시 효율을 높이는 방법이라고 생각하면 쉬울 것 같다!

 

 기능을 개발할 때 브랜치를 생성하고, 코드를 작성하며 커밋 메세지를 남긴다. 이후 기능 개발이 완료가 되면 메인 브랜치에 머지를 하여 안전하게 개발을 할 수 있는 환경을 만들어 준다. 기획이 변경된다고 해도 간단하게 브랜치만 삭제해버리면 되기 때문에 여러 시도를 해 볼 수 있다는 장점도 가진다.

---

❕Git 브랜치 전략

• 어떤 목적으로 생성된 브랜치지?
• 어떤 브랜치에서 브랜치를 생성해야하지?
• 어디에 병합을 해야하지?
• 어떤 브랜치가 최신 브랜치지?
• 어떤 브랜치가 배포된 버전이지?

---

 브랜치 전략이 없다면 위와 같은 의문점이 생길 것이다. 이런 상황을 최소화하기 위한 것이 바로 브랜치 전략이다.

 Git 브랜치 전략은 프로젝트의 저장소를 효과적으로 활용하기(관리하기) 위한 워크플로우(work-flow)이다. 브랜치의 생성, 삭제, 병합 등 git의 유연한 구조를 활용해서, 각 개발자들의 혼란을 최대한 줄이며 다양한 방식으로 소스를 관리하는 역할을 한다. 쉽게 말해서, 브랜치 생성에 규칙을 만들어서 협업을 유연하게 하는 방법론이라고 생각하면 된다.

 

가장 널리 사용되는 2가지 브랜치 전략을 보려고 한다.

1. git-flow 전략
2. github-flow 전략

---

1. git-flow 전략

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

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

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

git-flow

• main
  • 라이브 서버에 제품으로 출시되는 브랜치. 즉, 출시 가능한 프로덕션 코드를 모아두는 브랜치이다.
  • main 브랜치는 프로젝트 시작 시 생성되며, 개발 프로세스 전반에 걸쳐 유지된다.
  • 배포된 각 버전을 Tag를 이용해 표시해둔다.
• develop
  • 다음 출시 버전을 대비하여 개발하는 브랜치. 즉, 다음 버전 개발을 위한 코드를 모아두는 브랜치이다.
  • 개발이 완료되면, main 브랜치로 머지된다.
• feature
  • 추가 기능 개발 브랜치. 즉, 하나의 기능을 개발하기 위한 브랜치이다.
  • develop 브랜치에서 생성하며, 기능이 개발 완료되면 다시 develop 브랜치로 머지된다.
  • 머지할 때 주의점은 Fast-Forward로 머지하지 않고, Merge Commit을 생성하며 머지를 해주어야 한다. 이렇게해야 히스토리가 특정 기능 단위로 묶이게 된다.
  • 네이밍은 feature/branch-name 과 같은 형태로 생성한다.
• release
  • 다음 버전 출시를 준비하는 브랜치. 즉, 소프트웨어 배포를 준비하기 위한 브랜치이다.
  • develop 브랜치를 release 브랜치로 옮긴 후 QA, 테스트를 진행하고 main 브랜치로 합친다.
  • develop 브랜치에서 생성하며, 버전 이름 등의 소소한 데이터를 수정하거나 배포전 사소한 버그를 수정하기 위해 사용된다.
  • 배포 준비가 완료되었다면 Main과 Develop 브랜치에 둘다 머지한다.
  • 이때, Main 브랜치에는 태그를 이용하여 버전을 표시한다.
• hotfix
  • master 브랜치에서 발생한 버그를 수정하는 브랜치.
  • 이미 배포된 버전에 문제가 발생했다면, Hotfix 브랜치를 사용하여 문제를 해결한다.
  • Main 브랜치에서 생성하며, 문제 해결이 완료되면 Main과 Develop 브랜치에 둘다 머지한다.
  • Release 브랜치와 마찬가지로 Hotfix 브랜치를 따로 운용 ➡️ 핫픽스 업무와 관련없는 팀은 병렬적으로 기능개발을 할 수 있다.
  • 네이밍은 hotfix/v1.0.1 과 같은 형태로 생성한다.

---

💠 git-flow 특징

1. 주기적으로 배포하는 서비스에 적합하다.

2. 가장 유명한 전략인 만큼 수 많은 IDE에서 시각화 도구, GUI 도구를 지원해준다.

3. 웹 어플리케이션에는 적합하지 않다.

---

웹 어플리케이션은 일반적으로 롤백되지 않고, 지속적으로 제공(Continuous Delivery)되므로 여러 버전의 소프트웨어를 지원할 필요가 없다.

 

웹 어플리케이션은 내가(Vincent Driessen) 10년전 블로그 글을 쓸때에는 염두해둔 소프트웨어 유형이 아니다. 팀이 소프트웨어를 지속적으로 제공한다면, Git Flow 대신 Github Flow와 같은 더 단순한 워크플로우를 채택할 것을 제안한다.

 

그러나 명시적으로 버전을 관리해야하는 소프트웨어를 개발한다면, 여전히 Git Flow가 적합할 수 있다.

---

Vincent Driessen은 A successful Git branching model을 작성하고 10년이 지난 2020년에 해당 포스팅 위에 반성의 글(Note of Reflection)을 적는다. 그 내용을 요약하면 위와 같다.

 

 

---

2. github-flow 전략

Github Flow는 이름 그대로 Github 환경에서 사용하기 적합한 브랜치 전략이기도하다.

• Git flow가 좋은 방식이지만 GitHub에 적용하기에는 복잡하다는 Scott Chacon의 판단에 따라 만들어진 새로운 깃 관리 방식이다.
• 자동화 개념이 들어가 있다라는 큰 특징이 존재하며 만일 자동화가 적용되어 있지 않은 곳에서만 수동으로 진행하면 된다.
• Git flow에 비해 흐름이 단순해짐에 따라 그 규칙도 단순해졌다.
• 기본적으로 master branch에 대한 규칙만 정확하게 정립되어 있다면 나머지 가지들에 대해서는 특별한 관여를 하지 않으며 pull request기능을 사용하도록 권장한다.

github-flow

 

1️⃣ 브랜치 생성

1. 브랜치 생성

Github-flow 전략은 기능 개발, 버그 픽스 등 어떤 이유로든 새로운 브랜치를 생성하는 것으로 시작된다.

단, 이때 체계적인 분류 없이 브랜치 하나에 의존하게 되기 때문에 브랜치 이름을 통해 의도를 명확하게 드러내는 것이 매우 중요하다.

• master 브랜치는 항상 최신 상태며, stable 상태로 product에 배포되는 브랜치다. 이 브랜치에 대해서는 엄격한 role과 함께 사용한다
• 새로운 브랜치는 항상 master 브랜치에서 만든다
• Git-flow와는 다르게 feature 브랜치나 develop 브랜치가 존재하지 않는다.
• 그렇지만, 새로운 기능을 추가하거나 버그를 해결하기 위한 브랜치 이름은 자세하게 어떤 일을 하고 있는지에 대해서 작성해주도록 하자

 

2️⃣ 개발, 커밋(commit), 푸시(push)

2. 개발, 커밋, 푸시

개발을 진행하면서 커밋을 남긴다.

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

• 커밋메시지를 명확하게 작성하자
• 원격지 브랜치로 수시로 push 하자
• Git-flow와 상반되는 방식
• 항상 원격지에 자신이 하고 있는 일들을 올려 다른 사람들도 확인할 수 있도록 해준다
• 이는 하드웨어에 문제가 발생해 작업하던 부분이 없어지더라도, 원격지에 있는 소스를 받아서 작업할 수 있도록 해준다

 

3️⃣ PR(Pull Request) 생성

3. Pull Request 생

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

• pull request는 코드 리뷰를 도와주는 시스템
• 이것을 이용해 자신의 코드를 공유하고, 리뷰받는다.
• merge 준비가 완료되었다면 master 브랜치로 반영을 요구한다.

 

4️⃣ 리뷰, 토의

4. 리뷰, 토

Pull-Request가 master 브랜치 쪽에 합쳐진다면 곧장 라이브 서버에 배포되는 것과 다름 없으므로, 상세한 리뷰와 토의가 이루어져야 한다.

 

5️⃣ 테스트

5. 테스

리뷰와 토의가 끝났다면 해당 내용을 라이브 서버(혹은 테스트 환경)에 배포해본다.

배포시 문제가 발생한다면 곧장 master 브랜치의 내용을 다시 배포하여 초기화 시킨다.

 

6️⃣ 최종 Merge

6. 최종 Merge

라이브 서버(혹은 테스트 환경)에 배포했음에도 문제가 발견되지 않았다면 그대로 master 브랜치에 푸시를 하고, 즉시 배포를 진행한다.

대부분의 Github-flow 에선 master 브랜치를 최신 브랜치라고 가정하기 때문에 배포 자동화 도구를 이용해서 Merge 즉시 배포를 시킨다.

master로 merge되고 push 되었을 때는, 즉시 배포되어야한다

• GitHub-flow의 핵심
• master로 merge가 일어나면 자동으로 배포가 되도록 설정해놓는다. (CI / CD)

---

💠 github-flow 특징

1. 브런치 전략이 단순하며 git을 처음 접하는 사람도 쉽게 접근할 수 있다.

2. CI / CD 가 자연스럽게 이루어 진다.

• CI(Continuous Integration) - 소스코드 변경 사항이 정기적으로 빌드 및 테스트되어 remote 저장소에 통합되는, 즉 빌드 및 테스트의 자동화를 의미한다. 지속적인 통합을 통해서 코드의 품질을 유지시키며, 여러 개발자가 동시에 소스코드 수정작업을 할 때 충돌을 최대한 줄여준다.
• CD(Continuous Deployment) - 배포를 일일히 개발자가 하면 힘드니까 자동화 시키는 것, 즉 배포의 자동화다.
• Github-flow는 하나의 master 브랜치에 의존하기 때문에 자연스럽게 CI/CD가 진행된다.

3. release branch가 명확하게 구분되지 않은 시스템에서의 사용이 유용하다.

• GitHub 자체의 서비스 특성상 배포의 개념이 없는 시스템으로 되어있기 때문에 이 flow가 유용하다.
• 웹 서비스들에 배포의 개념이 없어지고 있는 추세이기 때문에 앞으로도 Git flow에 비해 사용하기에 더 수월할 것이다.

4. hotfix와 가장 작은 기능을 구분하지 않는다.

• 모든 구분사항들도 결국 개발자가 전부 수정하는 일들 중 하나이기 때문이다.
• 이 대신 구분하는 것은 우선 순위가 어떤 것이 더 높은지에 대한 것이다.

 

---

 

이외에도 Gitlab Flow, Trunk-based Development 와 같은 여러 전략이 있지만, 아직 나에게는 많이 생소하여 다루지는 않았다. 아직은 잘 모르겠지만 해보면서 늘겠지 생각하며 정리를 마친다 😎

 

---

https://blog.naver.com/ju_ble/223447544546

네이버 블로그에 2024. 5. 15. 17:12 작성했던 글을 티스토리에 보기 편하게 옮김 !

[Study] 깃 브랜치 전략(git-branch-strategy)