GitHub - branch 전략(Git Flow, GitHub Flow)

branch

사용 목적

1. 동시 개발: 여러 개발자가 동시에 작업하는 경우, 브랜치를 사용하여 각 개발자가 독립적으로 작업하고 다른 개발자의 작업에 영향을 미치지 않도록 합니다.

2. 새로운 기능 개발: 새로운 기능 또는 모듈을 개발할 때 브랜치를 사용하여 기존 코드베이스와 분리하여 개발할 수 있습니다. 이렇게 하면 새로운 기능의 개발이 완료되기 전에도 원래 코드베이스를 유지할 수 있습니다.

3. 버그 수정: 버그 수정을 위한 브랜치를 만들어서 원래 코드베이스를 변경하지 않고 버그를 수정하고 테스트할 수 있습니다.

4. 안정한 버전 유지: 메인 브랜치 또는 마스터 브랜치를 사용하여 안정적인 버전을 유지하고 배포합니다. 브랜치를 사용하여 새로운 변경 사항을 테스트하고 배포하기 전에 안정성을 유지합니다.

5. 작업 분리: 서로 다른 작업을 분리하고 관리하기 위해 브랜치를 사용합니다. 예를 들어, 프론트엔드 및 백엔드 개발은 별도의 브랜치에서 진행할 수 있습니다.

6. 실험 및 테스트: 브랜치를 사용하여 새로운 아이디어, 실험 또는 테스트를 수행할 수 있습니다. 실험을 브랜치로 유지하면 실패하거나 중단할 수 있으며, 성공한 경우 메인 코드베이스로 병합할 수 있습니다.

7. 협업: 여러 개발자가 한 프로젝트에서 작업할 때 브랜치를 사용하여 협업 및 충돌 관리를 용이하게 합니다.

• 정리하자면 여러 기능을 병렬적으로 개발하고, 버전 관리의 용이성을 위해서 브랜치를 사용합니다.

Git Flow

• 웹사이트 제작 시 Git 브랜치 전략은 협업과 버전 관리를 효율적으로 관리하기 위해 중요한 역할을 합니다. 웹사이트 프로젝트의 규모, 팀 구성 및 개발 프로세스에 따라 다양한 브랜치 전략을 선택할 수 있으며, 아래에 몇 가지 일반적으로 사용되는 브랜치 전략을 설명합니다:

1. Main 브랜치: 프로젝트의 안정한 버전을 관리하는 메인 브랜치입니다. 이 브랜치는 배포 가능한 버전의 코드만을 포함해야 합니다. 주로 운영 환경에서 사용됩니다.

2. Development 브랜치: 새로운 기능과 변경 사항을 개발하는 데 사용되는 브랜치입니다. 이 브랜치는 Main 브랜치로부터 파생됩니다. 개발자는 여기에서 작업하며 테스트가 완료되면 Main 브랜치로 병합됩니다.

3. Feature 브랜치: 각각의 기능 또는 모듈은 별도의 Feature 브랜치에서 개발되어야 합니다. 이 브랜치는 Development 브랜치로부터 파생됩니다. 예를 들어, "챔피언 정보 조회" 또는 "아이템 조회"와 같은 각각의 기능에 대한 브랜치를 생성할 수 있습니다.

   네이밍은 feature/branch-name 과 같은 형태로 생성한다.

4. Release 브랜치: 새로운 버전을 릴리즈할 때 사용되는 브랜치입니다. 개발이 완료되면 Development 브랜치의 코드를 Release 브랜치로 병합하고, 여기서 테스트 및 최종 검토를 수행한 후 Main 브랜치로 병합합니다.

   네이밍은 release/v1.1 과 같은 형태로 생성한다.

5. hotfix 브랜치: 기본 브랜치에 긴급한 버그 수정이 필요한 경우 사용합니다. 핫픽스 브랜치에서 버그를 수정하고, 이 수정 사항을 기본 브랜치 및 개발 브랜치로 병합합니다.

   네이밍은 hotfix/v1.0.1 과 같은 형태로 생성한다.

이러한 브랜치 전략은 Git을 사용하여 웹사이트 제작 프로젝트를 효과적으로 관리하기 위한 예시입니다. 팀의 크기, 프로젝트의 복잡성 및 개발 방법에 따라 브랜치 전략을 조정하고 사용자 정의할 수 있습니다. 중요한 것은 모든 개발자가 브랜치 전략을 이해하고 준수하여 협업과 버전 관리를 원활하게 유지하는 것입니다.

장단점

• 장점 : 안정적으로 버전별 배포가 가능합니다
• 단점 : ci/cd 에는 적합하지 않습니다. 웹 어플리케이션 개발에는 적합하지 않습니다.

브랜치 작명

1. main branch, develop branch

• main과 develop 브랜치는 본래 이름 그대로 사용하는 경우가 일반적입니다.

2. feature branch

• 어떤 이름도 가능하지만 main, develop, release-..., hotfix-... 같은 이름은 사용할 수 없습니다

• 추천 네이밍 : feature/기능요약
  ex) feature/login
  feature/{issue-number}-{feature-name} 이슈추적 시
  ex) feature/1-init-project, feature/2-build-gradle-script-write

3. release branch

• release-RB_... 또는 release-... 또는 release/... 사용

• 추천 네이밍 : release-... . ex) release-1.2

4. hotfix branch

• 추천 네이밍 : hotfix-... ex) hotfix-1.2.1

---

Github Flow (브랜치 하나만 잘 관리하자)

Main 브랜치

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

Topic 브랜치

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

이때, Topic 브랜치의 이름은 기능을 설명하는 명확한 이름으로 네이밍 해야한다. 예를 들면, user-content-cache-key, submodules-init-task, redis2-transition 등이 있다.

Topic 브랜치의 커밋은 기능이 완성되지 않았더라도 꾸준히 Push 한다. 노트북 분실, 작업 컴퓨터의 고장등의 위험으로 코드가 유실되는 것을 막아준다. 이것보다 더 중요한 이유는 꾸준히 Push 함으로써 구성원 모두가 끊임없이 커뮤니케이션 할 수 있게 해준다.

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

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

장단점

• 장점 : 소스코드가 한곳에만 있으므로 관리가 쉽습니다.
• 단점 : 테스트 많이, 자주 해야 합니다.
  따라서 테스트와 배포가 자동화된 시스템에 적합하고 안정화된 프로젝트들이 주로 사용합니다.

정리

• 개발팀이 소규모고 제품이 단일 릴리즈 버전밖에 존재하지 않는다면 Github Flow가 적절합니다. 대부분의 웹 애플리케이션은 여러 버전을 관리하지 않고, 가장 최신 버전 하나만을 사용자가 사용하게 되니 웹 애플리케이션에 적합한 브랜치 전략이라고 할 수있습니다.
• 또한 Github Flow는 하루에 변경사항을 작은 단위로 신속하고 자주 병합/배포 할 수 있는 구조로, CI/CD가 구현되고 이를 적극 활용하는 경우에 적합합니다.

참고

• https://hudi.blog/git-branch-strategy/
• https://sungjk.github.io/2023/02/20/branch-strategy.html
• https://m.blog.naver.com/adamdoha/222712473510
• https://www.howdy-mj.me/git/git-flow
• https://velog.io/@kim-jaemin420/Git-branch-naming