전문가를 위한 Git 워크플로: 좋은 Git 가이드

Git은 버전 관리뿐만 아니라 협업 및 릴리스 관리를 통해 프로젝트를 지원할 수 있습니다. Git 워크플로 패턴이 프로젝트를 돕거나 방해할 수 있는 방법을 이해하면 프로젝트의 Git 프로세스를 효과적으로 평가하고 조정하는 지식을 얻을 수 있습니다.

이 가이드 전체에서 나는 일반적인 Git 워크플로에서 발견되는 소프트웨어 개발 프로세스 패턴을 분리할 것입니다. 이에 대한 지식은 개발 팀에 합류, 생성 또는 성장시킬 때 방향을 찾는 데 도움이 됩니다. 특정 유형의 프로젝트 또는 팀에 대한 장단점은 우리가 탐색하는 워크플로 예제에서 강조 표시되므로 시나리오에 잘 맞는 것을 선택하고 선택할 수 있습니다.

이것은 Git 사용에 대한 소개가 아닙니다. 이에 대한 멋진 가이드와 문서가 이미 있습니다. 애플리케이션 개발 팀 내에서 이미 경험이 있고 워크플로 장애, 통합 중단 또는 git-tastrophes에 직면한 경우 이 Git 워크플로 가이드의 이점을 얻을 수 있습니다. 이러한 패턴은 향후 이러한 상황을 피하는 방법에 대한 정보를 제공할 수 있습니다.

협동

Git 프로세스 측면에서 협업은 종종 워크플로를 분기하는 것입니다. 커밋 트리를 어떻게 엮을 것인지 미리 생각하면 통합 버그를 최소화하고 릴리스 관리 전략을 지원하는 데 도움이 됩니다.

통합 지점

기여 컬렉션을 단일 엔터티로 프로덕션에 배포하기 위해 노력하는 소프트웨어 개발 팀과 함께 통합 분기 를 사용합니다. 이는 기능을 개별적으로 배포하는 데 중점을 두는 팀과 반대입니다. 종종 팀은 후자를 수행하기를 원할 수 있지만 실제적인 한계는 노력을 그룹화하는 프로세스를 부과하고 팀은 전자를 수행하게 되므로 실제 Git 사용을 검토하여 이러한 유형의 협업을 사용하면 이점이 있는지 확인하십시오. 무늬.

이 워크플로 패턴은 여러 분기를 통합할 위험이 결합된 기여 전체를 테스트해야 할 만큼 충분히 높을 때 유용한 스테이징 포인트입니다.

통합 분기는 일반적으로 주요 기능과 함께 배포할 여러 작은 기여로 구성됩니다. 개발 팀의 프로세스(예: Q&A 및 승인 테스트)를 통해 통합 분기를 실행합니다. 마이너 커밋을 푸시하여 프로덕션 준비 상태에 가깝게 만든 다음 환경 분기 또는 릴리스 분기(아래에서 설명)를 사용하여 배포를 준비합니다.

다른 주요 기능을 통합 분기에 병합하기 전에 통합 분기에 대한 기여를 다음 릴리스 단계에 병합해야 합니다. 그렇지 않으면 다른 완료 단계에서 기능을 혼합하게 됩니다. 이것은 준비된 것을 해제하는 능력을 억제합니다.

주제 분기

팀은 커밋 트리를 쉽게 읽을 수 있거나 개별 기능을 되돌릴 수 있는 상태로 유지하는 것이 중요한 경우 주제 분기 를 사용하기를 원할 것입니다. 토픽 분기는 구조를 정리하고 기능 커밋으로 축소하기 위해 커밋을 덮어쓸 수 있음을 나타냅니다(강제 푸시 사용).

토픽 브랜치는 종종 개별 기여자가 소유하지만 팀이 기능을 개발하기 위해 지정된 공간일 수도 있습니다. 다른 기여자들은 이러한 유형의 분기가 언제든지 커밋 트리를 다시 작성할 수 있고 로컬 분기를 동기화된 상태로 유지하려고 해서는 안 된다는 것을 알고 있습니다.

Git 워크플로에서 토픽 브랜치를 활용하지 않으면 원격 브랜치에 푸시하는 커밋으로 제한됩니다. 새 커밋 트리를 원격 분기로 강제로 푸시하면 동기화하는 분기의 무결성 유지에 의존하는 다른 기여자가 화를 낼 수 있습니다.

이 워크플로 패턴을 인지하지 못한 채 이미 사용하고 있을 가능성이 있지만 팀 간에 정의 집합을 공유하여 그 이면의 관행을 강화할 가치가 있습니다. 예를 들어, 브랜치 이름 앞에 브랜치 작성자의 이니셜을 붙이는 규칙은 토픽 브랜치임을 알리는 데 도움이 될 수 있습니다. 어느 쪽이든 내부 규칙을 결정하는 것은 팀의 몫입니다.

공용 리포지토리에서 토픽 브랜치를 사용 하지 마십시오 . 로컬 브랜치를 커밋 트리를 다시 작성한 토픽 브랜치와 동기화한 모든 사람에게 수많은 충돌이 발생합니다.

포크

오픈 소스 프로젝트는 이 Github 기반 기능을 사용하여 번창합니다. 포크 는 원본 리포지토리 분기에 직접 푸시하는 것보다 강화된 게이트웨이를 사용하여 리포지토리 유지 관리자에게 권한을 부여하지만 더 중요한 것은 협업을 용이하게 한다는 것입니다. 와후!

개인 저장소의 포크를 생성하는 것이 필요에 맞는 시나리오에 있을 수도 있습니다. 포크 리포지토리의 기고자에 대해 원본 리포지토리를 읽기 전용으로 설정하고 pull 요청으로 롤링하면 오픈 소스 커뮤니티에서 경험하는 것과 동일한 이점을 얻을 수 있습니다. 다른 조직의 팀은 커뮤니케이션 및 프로젝트 정책 준수를 위한 플랫폼이 될 수 있는 포크를 사용하여 효과적으로 작업할 수 있습니다.

포크 워크플로 패턴은 팀에 두 리포지토리 간의 단일 통합 지점(풀 요청)을 사용하여 익숙한 방식으로 작업할 수 있는 자체 공간을 제공합니다. 풀 리퀘스트 설명 내에서 오버커뮤니케이션은 필수입니다. 팀은 풀 리퀘스트가 발행되기 전에 별도의 커뮤니케이션 스트림을 갖고 있었고 이미 내린 결정을 강조 표시하면 검토 프로세스의 속도가 빨라집니다.

물론 포크 워크플로의 한 가지 이점은 권한이 아래로 계단식으로 내려갈 때 원본 리포지토리의 기고자에게 의견을 보낼 수 있다는 것입니다. 원본 리포지토리의 관점에서 포크가 더 이상 필요하지 않을 때 포크를 삭제할 수 있습니다.

이 패턴을 활용하기 위해 포크 및 풀 요청을 용이하게 하는 도구를 사용하고 있는지 확인하십시오. 이러한 도구는 Github에 국한되지 않습니다. 다른 인기 있는 선택은 Bitbucket 및 GitlLab입니다. 그러나 이러한 기능(또는 이와 유사한)이 있는 다른 Git 워크플로 호스팅 서비스가 꽤 있습니다. 귀하에게 가장 적합한 서비스를 선택하십시오.

팀의 각 구성원에 대해 개인 저장소의 포크를 사용 하지 마십시오 . 수많은 분기된 리포지토리는 여러 구성원이 동일한 기능 분기에서 공동 작업을 수행하는 것을 어렵게 만들 수 있으며 이러한 모든 리포지토리를 동기화된 상태로 유지하면 이동하는 부분의 수가 많기 때문에 오류가 발생하기 쉽습니다. 오픈 소스 프로젝트에는 이 오버헤드를 줄이는 원본 리포지토리에 대한 푸시 액세스 권한이 있는 핵심 팀 구성원이 있습니다.

클론

일반적인 아웃소싱 전략은 여러 소프트웨어 개발자가 채울 수 있는 프로젝트에 기여 "자리"를 두는 것입니다. 계약된 시간을 제공하기 위해 리소스 파이프라인을 관리하는 것은 아웃소싱 회사의 몫이며, 직면한 문제는 각 클라이언트의 프로젝트에 대해 개발자 풀을 온보딩, 교육 및 유지 관리하는 방법입니다.

프로젝트 리포지토리의 복제본 을 사용하면 아웃소싱된 팀이 기여를 관리하고 정책을 시행하며 지식 공유를 활용할 수 있는 격리된 교육 및 커뮤니케이션 기반이 마련됩니다. 이 모든 것이 클라이언트 개발 팀의 감시 하에 있습니다. 기여가 표준에 도달한 것으로 간주되고 기본 리포지토리에 대한 준비가 되면 원본 리포지토리 원격 분기 중 하나로 푸시하고 평소와 같이 통합할 수 있습니다.

일부 프로젝트는 코딩 규칙을 따르고 저장소에 기여하기 위해 Git 워크플로 표준을 정의하는 것에 대한 높은 기대치를 가지고 있습니다. 요령을 터득할 때까지는 이 환경에서 작업하는 것이 어려울 수 있으므로 팀으로 협력하여 양 당사자의 시간을 최적화하십시오.

허락 없이 클라이언트 저장소의 호스트된 복사본을 만들지 마십시오 . 계약을 위반할 수 있습니다. 이 방법이 클라이언트와 함께 프로젝트에 도움이 될 것인지 미리 확인하십시오.

릴리스 관리

협업에서 출시까지의 단계는 각 팀의 개발 프로세스 내 서로 다른 지점에서 시작됩니다. 일반적으로 하나 이상의 릴리스 관리 Git 패턴을 사용하고 싶지 않을 것입니다. 팀이 효과적으로 전달할 수 있는 가장 간단한 워크플로를 원합니다.

환경지사

소프트웨어 개발 프로세스는 프로덕션에 배포하기 전에 품질 보증을 돕기 위해 여러 환경에서 지원될 수 있습니다. 환경 분기 는 이 프로세스의 단계를 모방합니다. 각 단계는 분기에 해당하고 기여는 파이프라인에서 이를 통해 흐릅니다.

이러한 프로세스를 실행하는 팀에는 파이프라인의 각 단계(예: "QA", "준비" 및 "생산")에 대해 애플리케이션 환경이 설정된 경우가 많습니다. 이러한 경우 인프라는 다음 사람의 제품으로 이동하기 전에 프로덕션 준비(예: 예비 테스트, QA, 승인 테스트)가 의미하는 부분에 대한 기능 또는 기여 서명을 담당하는 직원을 지원하기 위해 마련되어 있습니다. 단계. 이를 통해 승인 터널을 통한 여정을 기록하는 Git 워크플로를 통해 요구 사항에 따라 배포, 테스트 및 평가할 수 있는 고유한 장소가 제공됩니다.

프로세스의 각 단계에 분기를 두는 것은 하나의 단위로 릴리스를 위해 작업할 수 있는 소규모 팀에 적합합니다. 불행히도 이와 같은 파이프라인은 너무 쉽게 병목 현상을 일으키거나 뭉쳐서 틈을 남길 수 있습니다. Git 프로세스를 인프라에 연결하여 기능 요구 사항이 증가하고 두 프로세스를 모두 확장해야 할 때 문제를 일으킬 수 있습니다.

먼저 다른 패턴의 장기적인 이점을 고려하지 않고 이 패턴을 사용 하지 마십시오 .

릴리스 분기

연속적인 스프린트에서 하나의 단위로 프로덕션 애플리케이션에 기여 컬렉션을 푸시하는 팀은 릴리스 분기 가 적합함을 찾을 수 있습니다.

거의 "프로덕션 준비" 커밋 모음에는 릴리스 분기에 대한 사소한 버그 수정이 제공됩니다. 커밋 트리를 릴리스 분기로 이동하기 전에 통합 분기를 사용하여 기능을 결합하고 테스트하십시오. 릴리스 분기의 책임을 프로덕션 애플리케이션에 배포하기 전에 최종 확인하는 것으로 제한합니다.

릴리스 브랜치는 수명이 짧다는 점에서 환경 브랜치와 다릅니다. 릴리스 분기는 필요할 때만 생성되고 커밋 트리가 프로덕션에 배포된 후에 삭제됩니다.

릴리스 분기가 소프트웨어 개발 로드맵에 연결되지 않도록 하십시오. 미리 결정된 계획을 따르도록 제한하면 계획된 모든 기능이 프로덕션 준비가 될 때까지 릴리스 배포가 지연됩니다. 릴리스 분기를 만들기 전에 로드맵에 버전 번호를 할당하지 않으면 프로덕션 준비가 된 기능을 릴리스 분기에 넣고 배포할 수 있으므로 이러한 유형의 지연을 완화할 수 있습니다.

릴리스 브랜치 이름에 버전 번호 명명 규칙을 사용하여 프로덕션에 배포된 리포지토리 버전을 분명히 합니다.

릴리스 분기가 아닌 마스터 분기를 배포합니다. 마스터 브랜치와 병합하기 전에 릴리스 브랜치에서 사소한 수정을 하도록 장려하려면 마스터 브랜치에서 Git 후크를 사용하여 병합이 발생한 후 트리거하여 업데이트된 커밋 트리를 프로덕션에 자동으로 배포합니다.

주어진 시간에 하나의 릴리스 분기만 존재하도록 허용하면 여러 릴리스 분기를 서로 동기화된 상태로 유지하는 오버헤드를 피할 수 있습니다.

동일한 저장소에서 작업하는 여러 팀과 함께 릴리스 분기를 사용 하지 마십시오 . 릴리스 분기는 수명이 짧지만 최종 확인이 너무 오래 걸리면 다른 팀이 릴리스하지 못하게 됩니다. 다른 팀의 릴리스 분기를 지원하는 팀은 버그를 도입하고 두 팀 모두에 지연을 일으킬 수 있습니다. 더 많은 수와 기여자 그룹에 더 잘 작동하는 아래의 타임스탬프가 표시된 릴리스 패턴을 살펴보세요.

타임스탬프가 찍힌 릴리스

인프라 제한이 있는 애플리케이션은 일반적으로 트래픽이 적은 기간 동안 배포를 예약합니다. 프로젝트에 배포할 준비가 된 기능의 일반 대기열이 있는 경우 타임스탬프가 있는 릴리스 를 사용하는 것이 좋습니다.

타임스탬프가 적용된 릴리스는 배포 프로세스에 따라 프로덕션에 배포된 마스터 분기의 마지막 커밋에 타임스탬프 태그를 자동으로 추가합니다. 토픽 브랜치는 배치를 기다리기 위해 마스터 브랜치에 병합되기 전에 개발 프로세스를 통해 기능을 넣는 데 사용됩니다.

타임스탬프 태그에는 실제 타임스탬프와 배포를 나타내는 레이블이 포함되어야 합니다(예: deployed-201402121345 .

마스터 브랜치의 커밋 트리 내에 타임스탬프 태그 형식으로 배포 메타데이터를 포함하면 프로덕션 애플리케이션에 릴리스된 회귀를 디버깅하는 데 도움이 됩니다. 문제의 원인을 찾는 책임을 맡은 사람은 프로덕션 애플리케이션에 배포되는 모든 라인에 대해 잘 알지 못할 것입니다. 마지막 두 태그에 대해 git diff 명령을 실행하면 마지막으로 배포된 커밋과 문제 해결에 도움이 될 수 있는 커밋 작성자에 대한 스냅샷을 빠르게 제공할 수 있습니다.

타임스탬프가 찍힌 분기는 표면에 표시되는 것보다 많습니다. 대기 중인 기능의 배포를 기록하기 위한 간단한 메커니즘을 실행하려면 놀라운 양의 우수한 프로세스가 필요합니다. 이 프로세스는 규모를 조정할 수 있고 소규모 기여자 팀과도 잘 작동하는 프로세스입니다.

이 Git 워크플로 패턴이 진정으로 효과적이려면 마스터 브랜치가 항상 배포 가능해야 합니다. 이는 팀에 대해 다른 의미를 가질 수 있지만 기본적으로 모든 커밋은 마스터 브랜치에 도달하기 전에 프로젝트 개발 프로세스를 거쳐야 합니다.

마스터 브랜치에 상륙하는 새 커밋은 하루에 여러 번 발생합니다. 이것은 개발 과정을 거쳐 이 시간 동안 마스터 브랜치와 동기화되지 않은 토픽 브랜치에 대한 문제입니다. 불행히도 이러한 시나리오는 병합 충돌이 잘못 처리될 때 마스터 분기에 회귀를 도입할 수 있습니다.

토픽 브랜치와 마스터 브랜치 사이에 병합 충돌이 발생하면 원격 마스터 브랜치를 업데이트하기 전에 새로운 버그를 도입할 위험에 대해 팀과 논의해야 합니다. 회귀가 발생할 수 있다는 의심의 여지가 있는 경우 병합 충돌이 해결된 상태에서 품질 보증 프로세스를 통해 주제 분기를 되돌릴 수 있습니다.

통합 버그를 줄이기 위해 저장소의 관련 부분에서 작업하는 개발자는 주제 분기를 마스터 분기와 병합하고 동기화하는 가장 좋은 시기에 공동 작업할 수 있습니다. 통합 브랜치는 관련 주제 브랜치의 충돌을 해결하는 데도 잘 작동합니다. 이러한 브랜치는 배포 보류 중인 마스터 브랜치의 대기열에 병합되기 전에 테스트 프로세스를 거쳐야 합니다.

기여자가 많은 소프트웨어 개발 프로젝트는 실용적이고 효율적인 접근 방식으로 협업 및 릴리스 관리 프로세스를 처리해야 합니다. 타임스탬프가 있는 릴리스를 사용하여 얻은 커밋 트리의 추가 메타데이터는 프로덕션 문제에 대응할 준비를 하고 있는 팀의 예측에 대한 포인터입니다.

버전 분기

프로덕션 환경에서 실행할 뿐만 아니라 다른 사람들이 자체 호스팅 애플리케이션에 사용하는 리포지토리가 있는 경우 버전 분기를 사용하면 팀에 플랫폼을 제공하여 애플리케이션 개발의 최첨단을 유지하지 않거나 유지할 수 없는 사용자를 지원할 수 있습니다. .

버전 분기를 사용하는 저장소에는 애플리케이션의 부 버전당 하나의 분기가 있습니다. 메이저, 마이너 및 패치 버전은 시맨틱 버전 문서에 설명되어 있습니다. 버전 분기는 일반적으로 " 2-3-stable "이라는 단어를 포함하고 응용 프로그램 버전에서 패치 번호를 삭제하는 명명 규칙을 따릅니다.

Git 태그는 애플리케이션의 패치 버전 번호까지 적용될 수 있지만 버전 분기는 그렇게 세분화되지 않습니다. 버전 분기는 항상 지원되는 부 버전에 대한 가장 안정적인 커밋을 가리킵니다.

보안 패치나 기능을 백포트해야 할 필요가 생기면 지원하는 이전 애플리케이션 버전에서 작동하는 데 필요한 커밋을 모아 각각 버전 분기에 푸시합니다.

둘 이상의 리포지토리 버전을 지원하지 않는 한 버전 분기를 사용 하지 마십시오 .

요약

팀의 규모가 변경되거나 프로젝트가 지속적인 평가를 통해 프로세스를 개발할 때 Git 프로세스도 평가하는 것을 빠뜨리지 마십시오. 이 자습서의 패턴을 시작점으로 사용하여 Git 워크플로의 올바른 방향으로 안내하는 데 도움이 됩니다.

이 가이드의 패턴은 분산 버전 제어 시스템을 사용자에게 맞게 조정하는 데 있어 어느 정도 예지력을 갖추는 데 도움이 될 수 있습니다. Git 워크플로에 대해 읽고 싶다면 Gitflow, Github Flow, 그리고 가장 중요한 것은 놀라운 git-scm 문서를 확인하십시오!