팀에 적합한 Git 워크플로 및 분기 모델을 선택하는 방법

Git은 거의 모든 소프트웨어 개발의 중심에 있는 버전 관리 시스템입니다. Git은 작성한 코드의 변경 사항을 저장하고 추적하는 데 사용됩니다. 팀에서 일할 때 비즈니스에 적합한 원활한 워크플로를 갖는 것은 빠르게 성장하는 데 매우 중요합니다.

더 나은 저장소 구성, 더 빠른 개발

Jenkins와 같이 사용하기 쉬운 자동화 파이프라인의 출현으로 많은 회사에서 CI/CD(지속적 통합 및 전달)를 구현하기 시작했으며 개발자의 변경 사항은 종종 리포지토리에 병합되어 일반적으로 제품을 제공하는 대신 매주 주간 기준. 월간 일정.

이 속도는 특히 Git과 관련하여 조직에 많은 부담을 줍니다. 동일한  master 브랜치에 변경 사항을 커밋하려고 하는 사람이 50명이라면 빈번한 병합 충돌 문제에 직면하게 될 것입니다.

운 좋게도 Git은 분기를 만들고 코드를 병합할 시기를 선택할 수 있는 기능을 제공하므로 모든 팀이 개발을 구성하는 데 사용해야 합니다. Git 워크플로를 제어하면 최소한 귀하와 팀원이 새로운 Git 문제를 검색하는 데 시간을 낭비하지 않아도 됩니다.

지점의 기능 및 개발

Git 브랜치가 작업하고 있는 두 가지 큰 문제가 있습니다. 내부 명령을 동기화 상태로 유지하고 공개 릴리스를 유지하는 것입니다.

Git에서 브랜치를 시작하면 .git이 아닌 해당 브랜치에 새로운 커밋이 생성됩니다 master. 이는 주어진 기능이나 버그 수정에 대한 개별 진행 상황을 추적하는 데 유용할 수 있습니다. 예를 들어, 각 분기는 Jira, Trello 또는 Github Issues & Projects와 같은 Kanban 서비스의 문제에 설명된 기능을 구현할 수 있습니다.

분기 병합은 일반적으로 명령 이 분기 master 에서 끌어오기를 요청하고 feature 모든 사람을 위해 변경 사항을 통합하는 Github와 같은 호스팅 Git 솔루션의 기능인 끌어오기 요청을 사용하여 수행됩니다. 이는 QA 및 단위 테스트를 수행하는 팀이 체인을 위로 이동하기 전에 분기가 제대로 작동하는지 확인하는 데 매우 유용할 수 있습니다.

또 다른 문제는 릴리스를 관리하는 것입니다. 잘못된 커밋으로 인해 손상될 수 있으므로 최신 내부 개발 빌드 사본을 클라이언트에게 보내고 싶지 않습니다.

이 문제를 해결하기 위해 많은 팀이 릴리스에 대해 별도의 분기를 사용하고 새 버전을 릴리스할 때만 해당 분기를 병합합니다. 이것은 릴리스 사이의 개발 분기에서 백그라운드에서 여러 커밋을 허용합니다.

이 모델의 또 다른 이점은 프로덕션 분기에서 별도의 커밋을 수행하여 다음 릴리스가 준비되기 전에 문제에 대한 수정 사항을 제공할 수 있다는 것입니다.

주요 개발

분기 전략은 제공된 도구를 사용하는 방법을 정확히 결정합니다. 다양한 유형의 팀을 위해 설계된 다양한 분기 전략이 있습니다.

고속도로 기반 개발은 팀 프로그래밍에 가깝습니다 master . 즉, 실행 가능한 제품을 신속하게 출시하기 위한 분기의 빠른 반복입니다. 팀은 일반적으로 며칠 이상 지속되지 않는 단기 기능 분기를 만들고 종종 에 직접 커밋합니다 master.

master 다른 모든 것을 지탱하는 두꺼운 나무 줄기처럼 전체 저장소에서 분기를 가장 활동적이고 유용한 분기로 만들기 때문에 “줄기”라고 합니다 . 모든 개발은 이 분기에 초점을 맞추며 쉽고 빠르게 배울 수 있어 우수한 개발자 경험을 제공합니다.

릴리스 준비가 되면 각 릴리스에 대해 새 버전의 분기가 생성됩니다. 이렇게 하면 릴리스가 분리 master되고 LTS 릴리스에 대한 수정 사항을 추가하거나 선택하는 데 도움이 됩니다.

이것은 특히 소규모 팀의 경우 많은 이점이 있습니다. 알고 있고 전체 리포지토리의 쓰기 권한을 신뢰하는 몇 명의 선임 개발자와 함께 작업하는 경우 가능한 한 빨리 변경 사항을 통합하면 개발 속도를 높일 수 있습니다. 결국, 이것은 지속적인 pull 요청 및 병합과 관련된 거의 모든 관료주의를 제거하지만, 팀과의 간단한 의사 소통은 여전히 ​​서로를 유지하는 데 필요하고 상대방이 무엇을 하고 있는지 항상 알아야 합니다.

그러나 이것은 규율과 좋은 개발자에 의존하기 때문에 좋은 조직이 아닙니다. 이것은 제품을 빠르게 출시하거나 기존 프로젝트를 빠르게 반복하는 데 정말 좋지만 프로젝트에 더 많은 주니어 개발자를 추가하거나 더 많은 오픈 소스 공동 작업자를 확보하자마자 결함이 보이기 시작합니다.

기존 Git 흐름

“Git Flow”는 여러 팀에서 작동하는 워크플로입니다. 이는 단순한 백본 개발 워크플로보다 복잡하지만 오픈 소스 프로젝트 및 팀 구성원이 많은 대규모 프로젝트에 많은 이점을 제공합니다.

Git Flow 분기 전략에서 기능 분기는 더 오래 지속되며 일일 통합의 주요 초점입니다. 팀은 프로덕션 준비가 될 때까지 기능에 대해 작업한 다음 승인을 받기 위해 풀 리퀘스트 프로세스를 거칩니다. master 더 최근의 커밋 으로 리베이스해야 할 만큼 오래 지속되는 기능을 포함하여 동시에 여러 기능이 있을 수 있습니다 .

Git Flow를 사용하면 액세스가 더 제한됩니다. 대부분의 개발자는 와 직접 병합할 수 있는 권한이 없고 develop확실히 , 과도 병합할 수 없으며 master기본 변경 방법으로 분기를 만들어야 하기 때문입니다.

Git Flow는 pull 요청 프로세스 중에 적절한 코드 검토를 위한 시간을 자연스럽게 남겨둡니다. 이를 통해 지속적으로 변경되는 백본 분기가 아닌 PR, 리베이스 및 병합으로 충돌을 처리할 수 있습니다. 이러한 포크는 타사에서 올 수 있기 때문에 오픈 소스에 적합하지만 대규모 팀 환경이나 많은 구성 요소가 포함된 모놀리식 제품을 개발하는 팀에도 적합합니다.

이 워크플로의 주요 기능 중 하나는 릴리스 템플릿입니다. 새 릴리스가 되면 준비를 위해 별도의 분기가 생성됩니다. 최종 버그 수정 및 패치가 여기에서 이루어진 다음 실제 master 분기로 푸시되고 릴리스를 빌드할 태그가 제공됩니다.

주요 차이점은 이 master 분기가 와 함께 유지된다는 것입니다 develop. develop릴리스 분기의 커밋 과 수정 사항 이 다시 병합됩니다 . develop 이렇게 하면 안정적일 때 릴리스가 만들어지는 가장 최근 분기가 항상 만들어 집니다.

master 이렇게 분리하면 최신 릴리스에 병합 되기 전에 릴리스해야 하는 사소한 버그 수정을 더 쉽게 관리할 수 있습니다 . 릴리스 브랜치는 기능 브랜치와 거의 동일한 방식으로 작동하며 안정적으로 표시된다는 추가 보너스가 있습니다.

물론 지속적인 pull, rebase 및 merge 요청은 힘든 작업이며 빠르게 하려는 경우 지루할 수 있습니다. 그러나 정적 타이핑이나 단위 테스트와 마찬가지로 결국에는 일을 조직화하고 원활하게 실행하는 것이 좋습니다.

당신에게 적합한 것을 선택하십시오

결국 좋은 팀 에티켓에 관한 것이며 멋진 다이어그램이라기보다 선에 가까운 Git 히스토리를 팀에서 잘 수행할 수 있습니다. 프로젝트가 작거나 솔로 취미 생활을 하는 경우 엄격한 Git 표준을 고수하면 득보다 실이 더 많을 수 있습니다.

하지만 Git에 문제가 있는 경우 백본 또는 Git Flow 개발을 시도할 수 있습니다. 최소한 리포지토리의 구성을 이해하면 통합 프로세스를 개선하는 데 도움이 됩니다.