브랜치 전략

기본 접근 방식에서 벗어나야 할 때 Git 브랜치 전략을 확장합니다.

Git 브랜치를 구성하고 머지하는 방식을 브랜치 전략이라고 합니다. 많은 팀에서 가장 단순한 접근 방식이 합리적이고 효과적입니다: 기능 브랜치에서 변경합니다. 기능 브랜치를 main 에 직접 머지합니다. 그러나 팀에 복잡한 요구 사항(테스트 및 규정 준수 요구 사항 등)이 있는 경우 다른 브랜치 전략을 고려할 수 있습니다. 다음 섹션에서는 일반적으로 사용되는 전략을 설명합니다. 모든 직원이 Git(또는 버전 관리) 전문가를 갖추고 있는 것은 아닙니다. 팀이 Git 기술의 한계에서 작업하는 경우 이 정보가 도움이 될 수 있습니다. GitLab을 여러 개의 다양한 도구를 대체하는 데 사용할 때 Git 브랜치 전략에 대한 결정이 중요합니다. 신중한 계획을 통해 다음 사이에 명확한 연결을 설정할 수 있습니다: 받은 초기 버그 보고서. 팀이 해당 버그를 수정하기 위해 만드는 커밋. 해당 수정 사항을 다른 버전이나 고객에게 백포팅하는 프로세스. 사용자에게 수정 사항을 제공하는 배포. 신중한 선택은 GitLab의 단일 데이터 저장소를 최대한 활용하는 데 도움이 됩니다. 더 복잡한 Git 브랜치 전략이 필요한가요? # 현재 Git 브랜치 전략을 능가한 경우: 지속적 배포를 사용합니다. 상당한 자동화 테스트가 있습니다. 다른 고객에게 영향을 미치지 않고 특정 고객의 중요한 버그를 수정해야 합니다. 제품의 여러 이전 버전을 유지 관리합니다. 제품에 단일 프로덕션 브랜치가 없습니다. 여러 운영 체제 또는 플랫폼을 지원하기 때문입니다. 제품에 각 버전마다 다른 배포 또는 인증 요구 사항이 있습니다. 제품에 필요한 것보다 복잡한 전략을 구현하지 마세요. 프로젝트를 여러 저장소로 분할하는 경우 # 복잡한 브랜치 구조를 가진 하나의 Git 저장소를 유지할지, 아니면 프로젝트를 여러 저장소에 분산할지 결정해야 합니다. 단일한 정답은 없습니다. 지원할 인력과 전문 지식에 따라 다릅니다. GitLab은 저장소가 단일 제품을 위한 것이라고 가정하는 자동화를 제공하지만, 해당 제품에는 여러 버전이 포함될 수 있습니다. 여러 저장소가 필요한지 또는 단일 복잡 저장소가 필요한지를 결정하려면 다음 질문을 하세요: 같은 제품인가요? 모든 요소가 동일한 빌드 프로세스를 사용하나요? 기본 코드가 비슷하거나 동일한가요? 복잡한 단일 저장소 또는 더 작은 저장소 세트 중 어느 것을 선택하든 유지 관리에 엔지니어링 시간을 써야 합니다. 어떤 유형의 엔지니어링 작업을 수행할 준비가 되어 있는지 파악하세요: 단일 저장소에서 여러 제품의 코드를 유지 관리하는 경우 나중에 GitLab의 모든 기능을 사용하기 위한 사용자 정의 작업을 계획합니다. 여러 저장소에 걸쳐 작업을 머지하는 것은 동일한 저장소의 브랜치에서 머지하는 것보다 더 복잡합니다. 사용자 정의 릴리스 프로세스를 구축하고 저장소 전체에 코드 흐름을 관리하기 위한 엔지니어링 시간을 계획합니다. Note 조직에서 대형 모노레포 또는 메가레포를 사용하는 경우 GitLab의 Professional Services 팀이 필요에 맞는 사용자 정의