Adopt a Git branching strategy(Git 분기 전략 채택)

  • 아티클

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Git과 같은 분산 버전 제어 시스템은 버전 제어를 사용하여 코드를 공유하고 관리하는 방법을 유연하게 제공합니다. 팀은 이러한 유연성과 일관된 방식으로 코드를 공동 작업하고 공유해야 하는 필요성 사이의 균형을 찾아야 합니다.

팀 구성원은 다른 사용자와 공유하는 Git 분기를 통해 코드 변경 내용을 게시, 공유, 검토 및 반복합니다. 팀을 위한 분기 전략을 채택합니다. 더 효율적으로 공동 작업하고 버전 제어를 관리하는 데 더 많은 시간을 할애하고 코드를 개발하는 데 더 많은 시간을 할애할 수 있습니다.

다음 분기 전략은 Microsoft에서 Git을 사용하는 방법을 기반으로 합니다. 자세한 내용은 Microsoft에서 Git을 사용하는 방법을 참조 하세요.

분기 전략을 단순하게 유지

분기 전략을 단순하게 유지합니다. 다음 세 가지 개념으로 전략을 빌드합니다.

  • 새로운 모든 기능과 버그 수정에 기능 분기를 사용합니다.
  • 끌어오기 요청을 사용하여 기능 분기 기본 분기에 병합합니다.
  • 고품질의 최신 기본 분기를 유지합니다.

이러한 개념을 확장하고 모순을 방지하는 전략은 일관되고 따라하기 쉬운 팀의 버전 제어 워크플로를 생성합니다.

작업에 기능 분기 사용

기능을 개발하고 기본 분기를 기반으로 기능 분기 버그를 수정합니다. 이러한 분기를 토픽 분기라고도 합니다. 기능 분기는 진행 중인 작업을 기본 분기의 완료된 작업과 격리합니다. Git 분기는 만들고 기본 저렴합니다. 작은 수정 및 변경 내용에도 고유한 기능 분기 있어야 합니다.

기본 분기 워크플로 이미지

모든 변경 내용에 대한 기능 분기 만들면 기록을 간단하게 검토할 수 있습니다. 분기에서 만든 커밋을 확인하고 분기를 병합한 끌어오기 요청을 확인합니다.

규칙에 따라 기능 분기 이름 지정

기능 분기 대해 일관된 명명 규칙을 사용하여 분기에서 수행된 작업을 식별합니다. 분기를 만든 사용자와 같은 다른 정보를 분기 이름에 포함할 수도 있습니다.

기능 분기 이름을 지정하기 위한 몇 가지 제안 사항:

  • users/username/description
  • users/username/workitem
  • bugfix/description
  • feature/feature-name
  • feature/feature-area/feature-name
  • 핫픽스/설명

참고 항목

분기 명명 전략을 적용하는 정책을 설정하는 방법에 대한 자세한 내용은 분기 폴더 필요를 참조 하세요.

기능 플래그를 사용하여 장기 실행 분기 관리

코드에서 기능 플래그를 사용하는 방법에 대해 자세히 알아봅니다.

끌어오기 요청을 사용하여 코드 검토 및 병합

끌어오기 요청에서 발생하는 검토는 코드 품질을 개선하는 데 중요합니다. 검토 프로세스를 통과하는 끌어오기 요청을 통해서만 분기를 병합합니다. 끌어오기 요청 없이 분기를 기본 분기에 병합하지 마세요.

끌어오기 요청의 검토는 완료하는 데 시간이 걸립니다. 팀은 끌어오기 요청 작성자 및 검토자로부터 예상되는 사항에 동의해야 합니다. 검토자 책임을 분산하여 팀 전체에서 아이디어를 공유하고 코드베이스에 대한 지식을 분산합니다.

성공적인 끌어오기 요청에 대한 몇 가지 제안 사항:

  • 두 명의 검토자는 연구에 따라 최적의 숫자입니다.
  • 팀에 이미 코드 검토 프로세스가 있는 경우 끌어오기 요청을 이미 수행 중인 작업으로 가져옵니다.
  • 많은 수의 끌어오기 요청에 동일한 검토자를 할당하는 데 주의하세요. 검토자 책임이 팀 간에 공유되면 끌어오기 요청이 더 잘 작동합니다.
  • 설명에 충분한 세부 정보를 제공하여 검토자가 변경 내용을 신속하게 처리할 수 있도록 합니다.
  • 끌어오기 요청을 사용하여 스테이징된 환경에서 실행 중인 변경 내용의 빌드 또는 연결된 버전을 포함합니다. 다른 사용자는 변경 내용을 쉽게 테스트할 수 있습니다.

고품질의 최신 기본 분기 유지

기본 분기의 코드는 테스트를 통과하고, 클린 빌드하며, 항상 최신 상태여야 합니다. 기본 분기에는 이러한 품질이 필요하므로 팀에서 만든 기능 분기 알려진 좋은 코드 버전에서 시작합니다.

기본 분기에 대해 다음과 같은 분기 정책을 설정합니다.

  • 코드를 병합하려면 끌어오기 요청이 필요합니다. 이 방법은 기본 분기에 대한 직접 푸시를 방지하고 제안된 변경 내용에 대한 논의를 보장합니다.
  • 끌어오기 요청을 만들 때 검토자를 자동으로 추가합니다. 추가된 팀 구성원은 코드를 검토하고 끌어오기 요청의 변경 내용에 대해 설명합니다.
  • 끌어오기 요청을 완료하려면 성공적인 빌드가 필요합니다. 기본 분기에 병합된 코드는 클린 빌드해야 합니다.

팁

끌어오기 요청에 대한 빌드 파이프라인은 빠르게 완료해야 하므로 검토 프로세스를 방해하지 않습니다.

릴리스 관리

릴리스 분기를 사용하여 코드 릴리스의 변경 내용을 조정하고 안정화합니다. 이 분기는 수명이 길며 기능 분기 경우와 달리 끌어오기 요청에서 기본 분기에 다시 병합되지 않습니다. 필요한 만큼 릴리스 분기를 만듭니다. 각 활성 릴리스 분기는 지원해야 하는 코드의 다른 버전을 나타냅니다. 특정 릴리스 지원을 중지할 준비가 되면 릴리스 분기를 잠급 수 있습니다.

릴리스 분기 사용

릴리스 또는 스프린트 종료와 같은 다른 중요 시점에 가까워지면 기본 분기에서 릴리스 분기를 만듭니다. 이 분기에 릴리스와 연결된 명확한 이름(예 : 릴리스/20)을 지정합니다.

릴리스 분기에서 버그를 수정하고 끌어오기 요청에서 릴리스 분기에 다시 병합하는 분기를 만듭니다.

릴리스 분기 워크플로 이미지

포트가 기본 분기로 다시 변경됩니다.

릴리스 분기와 기본 분기 모두에서 수정이 적용되는지 확인합니다. 한 가지 방법은 릴리스 분기에서 수정한 다음 기본 분기로 변경하여 코드의 회귀를 방지하는 것입니다. 또 다른 방법(및 Azure DevOps 팀에서 사용하는 방법)은 항상 기본라인을 변경한 다음 릴리스 분기로 이식하는 것입니다. 릴리스 흐름 전략에 대한 자세한 내용을 확인할 수 있습니다.

이 항목에서는 릴리스 분기를 변경하고 기본 줄로 포팅하는 작업을 설명합니다. 병합하는 대신 체리 따기를 사용하여 기본 분기로 다시 포팅되는 커밋을 정확하게 제어할 수 있습니다. 릴리스 분기를 기본 분기로 병합하면 기본 분기에서 원하지 않는 릴리스별 변경 내용을 가져올 수 있습니다.

다음 단계를 사용하여 릴리스 분기의 변경 내용으로 기본 분기를 업데이트합니다.

  1. 기본 분기에서 새 기능 분기 만들어 변경 내용을 이식합니다.
  2. 릴리스 분기에서 새 기능 분기 변경 내용을 선택합니다.
  3. 두 번째 끌어오기 요청에서 기능 분기 기본 분기에 다시 병합합니다.

릴리스 분기 워크플로가 업데이트되었습니다.

이 릴리스 분기 워크플로는 기본 워크플로의 핵심 요소인 기능 분기e, 끌어오기 요청 및 항상 최신 버전의 코드가 있는 강력한 기본 분기를 그대로 유지합니다.

릴리스에 태그를 사용하지 않는 이유는 무엇인가요?

다른 분기 워크플로는 Git 태그를 사용하여 특정 커밋을 릴리스로 표시합니다. 태그는 기록에서 중요한 점을 표시하는 데 유용합니다. 태그는 릴리스에 분기를 사용하는 경우 필요하지 않은 추가 단계를 워크플로에 도입합니다.

태그는 커밋과 별도로 기본 및 푸시됩니다. 팀 구성원은 커밋 태그 지정을 쉽게 놓친 다음 나중에 기록을 다시 돌아가서 태그를 수정해야 할 수 있습니다. 또한 태그를 푸시하는 추가 단계를 잊고 릴리스를 지원할 때 다음 개발자가 이전 버전의 코드에서 작업하도록 할 수도 있습니다.

릴리스 분기 전략은 릴리스를 처리하도록 기본 기능 분기 워크플로를 확장합니다. 팀은 포트 변경에 대한 체리 픽 이외의 새로운 버전 제어 프로세스를 채택할 필요가 없습니다.

배포 관리

여러 릴리스를 처리하는 것과 동일한 방식으로 코드의 여러 배포를 처리할 수 있습니다. 배포/성능 테스트와 같은 명확한 명명 규칙을 만들고 환경 분기를 릴리스 분기처럼 처리합니다. 팀은 배포 분기를 기본 분기의 코드로 업데이트하는 프로세스에 동의해야 합니다. 배포 분기에서 다시 기본 분기로 버그 수정을 선택합니다. 릴리스 분기에서 변경 내용을 포팅하는 것과 동일한 단계를 사용합니다.

이 권장 사항의 예외는 연속 배포 형식을 사용하는 경우입니다. 지속적인 배포로 작업할 때 Azure Pipelines를 사용하여 기본 분기에서 배포 대상으로 빌드를 승격합니다.