Git

깃 브랜치 전략 / Git Branching Strategy / workflow

Aburger 2024. 4. 30. 18:48

0. Branch

버전 관리와 소프트 구성 관리에서 버전 관리 하에 놓인 오브젝트(소스 코드 파일 또는 디렉토리)를 복사하는 과정 또는 복사된 오브젝트.

Git Branching Strategy 깃 브랜치 전략

Git을 사용하여 프로젝트를 관리하고 개발하는데 사용되는 브랜치 관련 접근 방식이나 전략을 나타낸다.

개발자들은 깃허브를 통해 협업을 하기 위한 작업방식, 프로세스를 미리 정의해서 체계적으로 개발한다.

 

깃 브랜치 전략이란 용어는 워크플로우를 포함하는 개념이며 브랜치 생성에 규칙을 만들어 협업을 유연하게 하는 방법론이다.

 

0-1. 브랜치 전략의 종류

워크플로우는 매우 다양하며 프로젝트의 크기, 복잡성, 협업 방식 등 프로젝트의 특성과 팀의 요구사항에 따라서 다양하게 구성될 수 있다.

  • Git Flow
  • Github Flow
  • Gitlab Flow
  • Feature Branch WorkFlow
  • Tunk-based Development
  • Forking Workflow
  • ...

 

1. Github Flow vs Git Flow

https://techblog.woowahan.com/2553/  - 우아한형제들 기술블로그

우아한 형제들은 Github-flow에서 Git-flow로 넘어가게 되었다.

무슨 차이점이 있기에 작업방식이 바뀌게 된것인가.

 

자세한 내용은 해당 사이트 'Git-flow를 사용하게된 이유' 를 참조

 

초기 배달의 민족 모바일 앱 개발자들은  2~3명으로 구성되어 3주 주기마다 앱을 릴리스 했다.

그러나 지속적인 채용과 개발기간 3주 이상의 작업들이 많아지며 기존 개발 프로세스에서 변화하게 된다.

 

1-1. 특징

  • GitHub-Flow
    • release branch가 명확하게 구분되지 않은 시스템에서의 사용이 유용하다.
    • GitHub자체의 서비스 특성상 배포의 개념이 없다.
    • 웹 서비스에 배포 개념이 없어지고 있는 추세이고 이에 유용하다.
    • HotFix와 작은 기능들을 구분하지 않는다.
      • 모든 구분사항들 또한 결국 개발자가 수정하는 일들 중 하나이기 때문이다.
      • 이 대신 어떤 것이 더 작업 우선순위가 높은지에 대하여 구분한다.
    • 지속적인 배포와 우선순위에 따른 작업을 수행해야 하는 환경에서 사용하며 작은팀, 중소규모의 프로젝트에서 유용하다.
  • Git-Flow
    • release를 준비하며 배포하는 데 중점을 둔다. 배포할 준비가 끝나면 Main Branch로 병합한다.
    • HotFix 브랜치를 사용하여 긴급한 버그를 수정한다.
    • 각각의 브랜치가 명확한 역할을 수행하도록 Strict하게 규정한다.
    • 안정된 버전을 관리하고 배포와 개발을 분리한다.
    • 릴리스, 버전관리를 효과적으로 수행해야 할때 사용하며 대규모 프로젝트에 유용하다

가장 많이 사용되는 Git-Flow부터 알아보도록 하자.

2. Git Flow 전략

기본적인 가지의 이름은 아래 5가지로 구분된다.

master > hotfix > release > develop > feature

  • 오른쪽으로 갈 수록 구체적이며 왼쪽으로 갈 수록 포괄적이다.
  • master branch를 병합할 경우 오른쪽에 있는 hotfix 등 모든 가지들에 있는 커밋들도 병합된다.
  • 항시 유지되는 메인 브랜치 master, develop 2가지와 merge되면 사라지는 보조 브랜치 feature, release, hotfix 3가지로 구성된다.

2-1. Git-Flow의 브랜치 구조

  • master: 라이브 서버에 제품으로서 출시되는 브랜치.
  • develop: 다음 출시 버전을 대비하여 개발하는 브랜치.
  • feature: 추가 기능 개발 브랜치. develop 브랜치에 포함된다.
  • release: 다음 버전 출시를 준비하는 브랜치. develop 브랜치를 releaes 브랜치로 옮긴 후 QA, 테스트를 진행하고 master브랜치로 합친다.
  • hotfix: master 브랜치에서 발생한 버그를 수정하는 브랜치.

메인 브랜치

master branch, develop branch 두 종류를 말한다.

master branch는 배포 가능한 상태만을 관리하는 브랜치를 말하며,

develop branch는 다음에 배포할 것을 개발하는 브랜치이다.

즉, develop브랜치는 통합 브랜치의 역할을 하며, 평소에는 이 브랜치를 기반으로 개발을 진행한다.

 

보조 브랜치

보조 브랜치는 피처 브랜치(feature branch) 또는 토픽 브랜치(topic branch)를 말한다.

  • 가지가 뻗어나오는 곳: develop
  • 뻗어나온 가지가 다시 합쳐지는 곳: develop
  • 이름 설정: master, develop, release_*, hotfix_* 를 제외한 자유로운 이름 설정이 가능하다.
  • 새로운 기능을 추가할 때 주로 사용하는 branch이다.

master 브랜치에서 develop 브랜치를 만들었고,

develop 브랜치에서 다시 feature 브랜치로 나누어 작업을 한다.

 

develop 브랜치에는 기존에 잘 작동하는 개발 코드가 담겨있으며,

보조 브랜치는 새로 변경될 개발코드를 분리하고 각각 보존하는 역할을 한다.

즉, 보조 브랜치는 기능을 다 완성할 때까지 유지하고, 다 완성되면 develop 브랜치로 merge하고 결과가 좋지 못하면 버리는 방향을 취한다.

 

보조 브랜치는 보통 개발자 저장소에만 있는 브랜치고, origin에는 push하지 않는다.

 

릴리스 브랜치 release branch

배포를 위한 최종적인 버그 수정 등의 개발을 수행하는 브랜치를 말한다.

  • 가지가 뻗어 나오는곳: develop
  • 뻗어나온 가지가 다시 합쳐지는 곳: develop, master
  • 이름 설정: release_*
  • 새로운 제품을 배포하고자 할 때 사용하는 가지이다.

develop branch에 버전에 포함되는 기능이 merge되었다면, QA(Quality Assurance)를 위해 develop 브랜치에서부터 release 브랜치를 생성한다.

 

배포 가능한 상태가 되면 master 브랜치로 병합시키고, 출시된 master 브랜치에 버전 태그(v1.0, v0.2 등)를 추가한다.

release 브랜치에서 기능을 점검하며 발견한 버그 수정 사항은 develop 브랜치에도 적용 해주어야 한다.

그러므로 배포완료 후 devlop 브랜치에서도 merge작업을 수행해야 한다.

 

핫픽스 브랜치 hotfix branch

배포한 버전에서 긴급하게 수정할 필요가 있을 때 master 브랜치에서 분리하는 브랜치를 말한다.

  • 가지가 뻗어 나오는곳: master
  • 뻗어나온 가지가 다시 합쳐지는 곳: develop, master
  • 이름 설정: hotfix_*
  • 제품에서 버그가 발생했을 경우에는 처리를 위해 이 가지로 해당 정보들을 모아준다.
  • 버그에 대한 수정이 완료된 후에는 develop, master에 곧장 반영해주며 tag를 통해 관련 정보들을 기록한다.

버그를 잡는 사람이 일하는 동안에도 다른 사람들은 develop 브랜치에서 하던 일을 계속할 수 있다.

 

이 때 만든 hotfix브랜치에서의 변경 사항은 develop 브랜치에도 merge하여 문제가 되는 부분을 처리해줘야 한다.

 

release가지가 생성되어 관리되고 있는 상태라면 해당 가지에 hotfix정보를 병합시켜 다음번 배포 시 반영이 정상적으로 이루어질 수 있도록 해준다.

 

Hotfix 브랜치는 긴급한 버그를 고치기 위해 생성되는 브랜치이다. 고로 버그 해결시 보통 제거하는 일회성 가지이다.

 

2-2. Git flow 흐름

  • 서술한 기본 구조 5개 중 가장 많이 사용되는 가지는 메인 브랜치인 master와 develop이 되며 정상적인 프로젝트를 진행하기 위해서는 둘 모두를 운용해야 한다.
  • 나머지 feature, release, hotfix branch는 사용하지 않는다면 지우더라도 오류가 발생하지 않기 때문에 깔끔한 프로젝트를 원한다면 지워뒀다가 해당 가지를 활용해야 할 상황이 왔을 때 만들어줘도 괜찮다.
  • 대부분의 작업은 develop에서 취합한다 생각하면 되며 테스트를 통해 정말 확실하게 더 이상 변동사항이 없다 싶을 때 maser로 병합하도록 한다.
  • master가 아닌 branch들은 master의 변동사항을 꾸준히 주시하여야 한다.

 

신규 기능 개발

  • 개발자는 develop 브랜치로부터 본인이 신규 개발할 기능을 위한 feature branch를 개설한다.
  • feature branch에서 기능을 완성하면 develop branch에 merge를 진행한다.

 

라이브 서버로 배포

  • feature branch들이 모두 develop branch에 merge되었다면 QA를 위해 release branch를 생성한다.
  • release branch를 통해 오류가 확인된다면 release branch 내에서 수정을 진행한다.
  • QA와 테스트를 모두 통과했다면, 배포를 위해 release branch를 master branch 쪽으로 merge한다.
  • 만일 release branch 내부에서 오류 수정이 진행되었을 경우 동기화를 위해 develop branch 쪽에도 merge를 진행한다.

 

배포 후 관리

 

  • 만일 배포된 라이브 서버(master branch)에서 버그가 발생 된다면, hotfix branch를 생성하여 버그 픽스를 진행한다.
  • 그리고 종료된 버그 픽스를 master와 develop branch 양쪽에 merge하여 동기시킨다.

3. Github-Flow 전략

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

 

3-1.  GitHub-Flow 구조

  • Main(master, remote): GitFlow와 유사하게 main브랜치에는 프로젝트에 배포 가능한 모든 코드가 포함되어 있다.
  • feature branch: 새로운 기능에 대한 작업을 위하여 만든 branch

 

3-2. GitHub-Flow 흐름

브랜치 생성 Create Branch

  • 기능 개발이나 버그 수정 작업 등 어떤 이유로든 작업을 수행하기 위해선 새로운 브랜치를 생성한다.
  • 체계적인 분류 없이 브랜치 하나에 의존하기에 브랜치의 의도를 명확히 드러내는 이름을 지어주는 것이 중요하다.
    • master branch는 항상 최신 상태며, stable상태로 product에 배포되는 브랜치이다. 이 브랜치에 대해서는 엄격한 role과 함쎄 사용한다.
    • 새로운 브랜치는 항상 master 브랜치에서 만든다.
    • Git-Flow와는 다르게 feature 브랜치나 develop 브랜치가 존재하지 않는다.
    • 그렇지만, 새로운 기능을 추가하거나 버그를 해결하기 위한 브랜치 이름은 자세하게 어떤 일을 하고 있는지에 대해서 작성해주자.

Develop&Commit&Push

  • 브랜치에서 개발 및 수정 변경 사항을 커밋을 남긴다.
    • 수정내용 또한 커밋 메시지에 의존한다. 때문에 커밋 메시지를 최대한 상세하게 적어주도록 한다.
      • 커밋은 작업의 단위이며, 코드 변경 내용을 기록한다.
    • main branch로 수시로 push하도록 한다. / Git-flow와 상반된 방식이다.
    • 항상 main branch에 자신이 하고 있는 일들을 올려 다른 사람들도 확인할 수 있도록 한다.
      • 하드웨어에 문제가 발생해 작업하던 부분이 없어지더라도, remote에 있는 소스를 받아서 작업할 수 있도록 해준다.

Pull Request

  • 변경 사항을 본래 브랜치로 병합하기 위해 pull request를 생성한다.
    • 자신의 코드를 공유하며, 리뷰 받는다.
    • 코드 검토, 토론, 테스트 등을 수행할 수 있다.
    • merge 준비가 완료 되어다면 master 브랜치로 반영을 요구한다.

Review

  • 풀 리퀘스트가 생성 후 master branch 병합 전 상세한 리뷰와 토의가 이루어져야 한다.
    • master branch에 병합한다는 것은 곧장 라이브 서버에 배포되는것과 다름 없다.

Test

  • 리뷰와 토의가 끝나면 해당 내용을 라이브 서버에 배포해본다.
  • 배포시 문제가 발생한다면 곧장 master 브랜치의 내용을 다시 배포하여 초기화 시킨다.

Merge

  • 라이브 서버(혹은 테스트 환경)에 배포했음에도 문제가 발견되지 않는다면 그대로 master 브랜치에 push를 하고, 즉시 배포를 진행한다.
  • 대부분의 Github-flow에선 master 브랜치를 가장 최신 브랜치로 가정하기 때문에 배포 자동화 도구를 이용해서 Merge 즉시 배포를 시킨다.
  • master로 merge되고 push되었을 때는, 즉시 배포되여야 한다.(CI continunous integration / CD continuous delivery)

4. 무엇을 사용할 것인가.

  • 1개월 이상의 긴 개발기간. 주기적으로 배포, QA, Test, Hotfix 등을 수행할 여력이 있는 팀.
    • Git Flow
  • 수시로 release 되어야 할 필요가 있는 서비스. 지속적으로 테스트하고 배포하는 팀.
    • GitHub Flow
반응형
저작자표시 (새창열림)