Git의 분기 전략-CSS 튜토리얼-php.cn

Git의 분기 전략

Lisa Kudrow

풀어 주다： 2025-03-19 10:02:10

원래의

741명이 탐색했습니다.

Git의 분기 전략

이 기사는 "Advanced Git"시리즈의 일부입니다. 트위터에서 우리를 팔로우하거나 향후 기사에 대한 업데이트를 위해 뉴스 레터를 구독하십시오!

대부분의 버전 제어 시스템 (VCS)은 분기를 지원합니다. 기본적으로 Branching은 변경에 대한 별도의 작업 공간을 만듭니다. 기본 코드베이스에 영향을 미치지 않고 실험이 가능합니다. Git의 분기 모델은 지점 생성, 전환 및 삭제의 속도와 효율성으로 유명한 매우 강력합니다. GIT는 분기가 많은 워크 플로를 적극적으로 홍보합니다.

개별 개발자는 자신의 분기 관행에 자유가 있지만 팀워크에는 공유 전략이 필요합니다. Git은 도구를 제공합니다. 팀은 최적의 사용을 정의합니다. 이 기사는 다양한 분기 전략, 지점 유형 및 GIT 흐름과 GitHub 흐름의 두 가지 인기있는 워크 플로를 탐구합니다.

고급 GIT 시리즈 :

1 부 : Git에서 완벽한 커밋 만들기
2 부 : Git의 분기 전략 ( 당신은 여기 있습니다! )
파트 3 : 풀 요청과 더 나은 협력
4 부 : 충돌을 병합합니다
5 부 : Rebase vs. Merge
6 부 : 대화식 레바 제
7 부 : 체리 따기 커밋
파트 8 : 리플 로그를 사용하여 잃어버린 커밋을 복원합니다

팀워크 : 분기 컨벤션을 설정하십시오

효과적인 팀 협업에는 문서화 된 분기 전략 및 워크 플로가 필요합니다. 이 문서는 충돌을 방지하고, 온 보딩을 간소화하며, 모든 사람이 프로세스를 이해하도록합니다.

규칙의 예 :

master (또는 main ) : 현재 공개 릴리스.
next : 다가오는 공개 릴리스 (관련없는 변경 사항을 병합하지 않고 master 에서 핫픽스를 허용합니다).
feature/ : 기능 분기 (이 접두사 아래에서 구성).
wip/ : 진행중인 작업 지점 (개인 백업용).

이러한 규칙은 예시 적이다. 팀은 자신의 요구에 맞게 조정할 수 있습니다.

변경 및 구조화 릴리스 통합

분기 전략은 변화 통합 및 릴리스 구조화를 고려해야합니다. 두 가지 대조적 인 접근법은 가능성의 스펙트럼을 강조합니다.

메인 라인 개발 : 단일 분기를 사용한 "항상 통합"접근 방식. 모든 기여는 메인 라인에 직접 최선을 다하고 있습니다. 이것은 추적을 단순화하지만 엄격한 테스트와 작고 자주 커밋해야합니다.
상태, 릴리스 및 기능 분기 : 기능, 릴리스 및 개발 상태를 관리하기 위해 여러 지점 유형을 사용합니다. 이 접근법은 더 복잡하지만 대규모 프로젝트 및 팀에게 더 나은 조직과 제어를 제공합니다. 대부분의 팀은이 극단 사이에 떨어집니다.

이것을 자세히 살펴 보겠습니다.

메인 라인 개발

핵심 원칙은 지속적인 통합입니다. 모든 개발자는 단일 지점에 직접 커밋합니다. 이것은 추적을 단순화하지만 통합 문제를 방지하기 위해 고품질 테스트가 필요합니다. 단순성으로 인해 강력한 테스트 인프라가없는 팀에는 적합하지 않습니다.

상태, 릴리스 및 지점

이 전략은 기능 개발, 릴리스 관리 및 다양한 개발 단계를 나타내는 독특한 목적으로 다양한 지점 유형을 사용합니다. 처음에는 복잡한 것처럼 보이지만 실습으로 관리 할 수 있으며 더 복잡한 릴리스주기가있는 프로젝트에 적합합니다.

다음으로, 우리는 장기 실행 및 단기 지점을 탐구합니다.

장기 실행 지점

모든 저장소에는 종종 master 또는 main 이라는 최소한 리포지토리가 있습니다. 다른 장기 실행 지점에는 릴리스 프로세스의 다양한 단계를 나타내는 develop , production 또는 staging 포함될 수 있습니다. 이 분기는 프로젝트 수명주기 전체에서 지속됩니다.

일반적인 규칙은 장기 실행 지점으로의 직접 커밋을 피하는 것입니다. 대신, 변경은 병합 또는 재생을 통해 통합되어 코드 품질 및 제어 릴리스를 보장합니다.

단기간

이 지점은 일시적인 목적으로 사용되며 특정 작업 (새로운 기능, 버그 수정, 리팩토링)을 위해 만들어지고 장기 실행 지점에 통합 한 후 삭제됩니다. 그들은 일반적으로 장기 실행 지점에서 분기되어 고립 된 개발을 허용 한 다음 완성 된 작업을 메인 라인으로 다시 병합합니다.

두 가지 인기있는 분기 전략 : git 흐름과 Github 흐름

널리 사용되는 두 가지 전략은 다른 접근법을 제공합니다.

git 흐름

이 전략은 생산 릴리스에 main 사용하고 지속적인 개발을 위해 develop . develop 분야의 지점과 릴리스 브랜치는 릴리스 준비를 위해 develop 에서 생성됩니다. 일단 테스트되면 릴리스 브랜치가 main 으로 병합되고 태그가 지정되고 삭제됩니다. 패키지 소프트웨어에는 효과적이지만 웹 프로젝트에는 지나치게 복잡 할 수 있습니다.

Github 흐름

자주 릴리스가있는 지속적인 전달에 적합한 Github Flow는 단일 main 지점을 사용합니다. 유형 (피처, 버그 수정, 리팩토링)에 관계없이 모든 작업은 main 으로 병합 될 때까지 자체 지점에 있습니다. 단순성은 빠른 반복에 이상적입니다.

올바른 전략 선택

최적의 분기 전략은 상황에 따라 매우 높습니다. 팀은 프로젝트 요구, 출시 전략 및 개발 프로세스를 공동으로 평가하여 가장 적합한 접근 방식을 선택해야합니다. 하나의 크기에 맞는 솔루션은 없습니다. 고급 GIT 도구에 대한 더 깊은 이해를 위해 "Advanced Git Kit"와 같은 추가 리소스를 탐색하는 것을 고려하십시오.