혼란 없는 팀워크: Git의 분기 전략 이해

소개

Git은 소프트웨어 제작 시 버전 제어를 위한 사실상의 업계 표준이 되었습니다. git이 무엇인지, 어떻게 시작하는지 알아보려면 먼저 이에 대한 내 기사를 읽어보세요. 읽어보셨나요? 좋습니다. 계속 진행하겠습니다! 좋든 싫든 Linus Towalds가 만든 도구는 폐기되지 않을 것입니다. 따라서 분산된 팀이 git에서 작업하는 방식과 이를 위해 어떤 분기 전략을 선택해야 하는지에 대해 이야기하는 것이 합리적입니다. 그리고 이것은 전혀 유휴 질문이 아닙니다. 종종 서로 협력하지 않은 새로운 개발자 팀이 모이는 상황에서 분기 전략은 가장 먼저 결정해야 할 사항 중 하나입니다. 그리고 한 전략이 다른 전략보다 낫다는 것을 증명하기 위해 입에 거품을 물고 있는 사람들도 있을 것입니다. 그러므로 나는 그들이 일반적으로 무엇인지에 대한 정보를 당신에게 전달하고 싶습니다.

분기 전략이 필요한가요?

하지만 그것들은 필요하고, 여전히 필요합니다. 팀에서 어떤 것에 동의하지 않으면 모두가 원하는 대로 할 것이기 때문입니다.

• 그가 원하는 지점에서 일하십시오.
• 그가 원하는 다른 지점으로 병합합니다.
• 일부 지점을 삭제하십시오.
• 새로운 것을 창조하십시오;
• 등등 - 각 팀 구성원은 통제되지 않은 흐름에 있습니다.

따라서 아래에는 세 가지 전략이 있습니다. 가다!

GitHub 흐름 전략

분기 전략은 아무리 이상하더라도 GitHub에서 선호됩니다. 이에 따라야 할 일련의 규칙이 첨부되어 있습니다.

1. 마스터 브랜치의 코드는 손상되지 않고 언제든지 배포할 준비가 되어 있어야 합니다. 즉, 프로젝트를 빌드하고 서버에 배포하는 것을 방해하는 코드를 거기에 넣을 수 없습니다.
2. 새로운 기능에 대한 작업을 계획할 때 마스터 브랜치를 기반으로 새 브랜치(기능 브랜치)를 생성하고 의미 있는 이름을 지정해야 합니다. 코드를 로컬로 커밋하고 변경 사항을 원격 저장소의 동일한 분기에 정기적으로 푸시하세요.
3. 작업이 준비 되었고 마스터 브랜치에 병합될 수 있다는 분명한 느낌이 들 때(또는 확실하지 않지만 피드백을 받고 싶은 경우) 풀 요청(풀 요청이 무엇인지 읽을 수 있음)을 엽니다. 완료된 작업).
4. 끌어오기 요청의 새로운 기능이 승인되면 마스터 분기에 병합할 수 있습니다.
5. 변경 사항이 마스터 브랜치에 병합되면 즉시 서버에 배포되어야 합니다.

GitHub Flow에 따르면 수정 사항이든 새 기능이든 새로운 작업을 시작하기 전에 마스터를 기반으로 새 분기를 만들고 적절한 이름을 지정해야 하는 것으로 나타났습니다. 다음으로 구현 작업이 시작됩니다. 동일한 이름을 가진 원격 서버에 지속적으로 커밋을 푸시해야 합니다. 모든 것이 준비되었음을 이해하면 마스터 브랜치에서 풀 요청을 생성해야 합니다. 그렇다면 적어도 한 명 또는 두 명이 이 코드를 보고 승인을 클릭해야 합니다. 일반적으로 프로젝트 팀장과 다른 사람이 이를 살펴보고 나서 끌어오기 요청을 완료하면 됩니다. GitHub Flow는 프로젝트에서 CD(지속적 전달)를 추진하는 것으로도 알려져 있습니다 . 마스터 브랜치가 변경되면 즉시 서버에 배포되어야 하기 때문입니다.

GitFlow 전략

이전 전략(GitHub Flow)은 본질적으로 그다지 복잡하지 않았습니다. 분기에는 마스터 분기와 기능 분기의 두 가지 유형이 있습니다. 그러나 GitFlow는 더 심각합니다. 적어도 위 그림을 보면 이 사실을 이해할 수 있습니다.) 그러면 이 전략은 어떻게 작동합니까? 일반적으로 GitFlow는 두 개의 영구 분기와 여러 유형의 임시 분기로 구성됩니다(GitHub Flow의 맥락에서 마스터 분기는 영구 분기이고 나머지 분기는 임시 분기입니다). 영구 지점:

• 마스터: 누구도 이 가지를 만지거나 거기에 아무것도 밀어서는 안 됩니다. 이 전략에서 마스터는 프로덕션(즉, 실제 서버)에 사용되는 최신 안정 버전을 표시합니다.
• 개발은 개발을 위한 분기입니다. 잠재적으로 불안정할 수 있습니다.

개발은 세 가지 보조 임시 분기를 사용하여 수행됩니다 .

1. 기능 분기 - 새로운 기능을 개발합니다.
2. 릴리스 분기 - 프로젝트의 새 버전 릴리스를 준비합니다.
3. 핫픽스 브랜치는 실제 서버에서 실제 사용자가 이미 발견한 결함에 대한 빠른 솔루션입니다.

기능 분기

기능 분기는 개발자가 새로운 기능을 위해 생성합니다. 항상 개발 브랜치를 기반으로 생성되어야 합니다. 새로운 기능에 대한 작업을 완료한 후에는 개발 브랜치에서 끌어오기 요청을 생성해야 합니다. 대규모 팀에서는 한 번에 둘 이상의 기능 분기가 있을 수 있다는 것이 분명합니다. 다시 한 번 GitFlow 전략 설명 시작 부분의 그림에 주목하세요.

릴리스 브랜치

개발 브랜치에서 필요한 수의 새로운 기능이 준비되면 제품의 새 버전 출시를 준비할 수 있습니다. 릴리스 브랜치가 이를 도와줄 것입니다. 개발 브랜치를 기반으로 생성됩니다. 릴리스 브랜치로 작업하는 동안 모든 결함을 찾아서 수정해야 합니다. 릴리스 브랜치를 안정화하는 데 필요한 새로운 변경 사항도 개발에 다시 병합해야 합니다. 이는 지점을 안정화하고 발전시키기 위해 수행됩니다. 테스터가 브랜치가 새 릴리스에 충분히 안정적이라고 말하면 마스터 브랜치에 병합됩니다. 다음으로, 이 커밋에 버전 번호가 할당된 태그가 생성됩니다(태그: 자세한 내용은 여기에서 확인할 수 있습니다 ). 예를 들어 전략 시작 부분의 그림을 볼 수 있습니다. 따라서 태그 1.0은 프로젝트 버전 1.0을 나타내는 레이블일 뿐입니다. 마지막으로 브랜치 핫픽스입니다.

핫픽스 브랜치

핫픽스 브랜치는 마스터의 새 버전 출시를 위한 것이기도 합니다. 유일한 차이점은 이번 출시가 계획되지 않았다는 것입니다. 결함이 릴리스에 이르고 프로덕션에서 이미 발견되는 상황이 있습니다. 예를 들어 iOS의 경우 새 버전이 출시되자마자 출시 후 발견된 결함에 대한 수정 사항이 포함된 수많은 업데이트를 즉시 받게 됩니다. 이런 점에서 이번 결함을 조속히 수정하고 새 버전을 출시하는 것이 필요하다. 우리 그림에서는 버전 1.0.1에 해당합니다. 아이디어는 실제 서버의 결함을 수정해야 하는 순간에 새로운 기능에 대한 작업이 중단되지 않을 수 있다는 것입니다(“프로덕션 중”이라고 말함: 다시 영어 단어 프로덕션의 복사본). 핫픽스 분기는 프로덕션에서 작동하는 상태를 나타내기 때문에 마스터 분기에서 생성되어야 합니다. 결함에 대한 솔루션이 준비되는 즉시 마스터에 병합되고 새 레이블이 생성됩니다. 릴리스 분기를 준비하는 것과 마찬가지로 핫픽스 분기는 해당 솔루션을 개발 분기에 병합해야 합니다.

포크 워크플로우 전략

Forking Workflow 전략의 일환으로 개발은 두 개의 저장소가 있는 방식으로 수행됩니다.

1. 모든 변경 사항이 병합될 원본 저장소입니다.
2. 포크 저장소(원본을 변경하려는 다른 개발자가 소유하고 있는 원본 저장소의 복사본입니다).

지금까지는 조금 이상하게 들렸죠? 이미 오픈 소스 개발을 접해본 사람들에게는 이 접근 방식이 이미 익숙합니다. 이 전략은 다음과 같은 이점을 제공합니다. 원본 저장소에서 공동 개발에 대한 권한을 부여하지 않고도 포크 저장소에서 개발을 수행할 수 있습니다. 물론 원본 저장소의 소유자는 제안된 변경 사항을 거부할 권리가 있습니다. 아니면 동의하고 그들을 죽이십시오. 이는 원본 저장소의 소유자와 일부 제품 생성에 참여하려는 개발자 모두에게 편리합니다. 예를 들어 Linux 커널 에 대한 변경을 제안할 수 있습니다 . Linus가 그 내용이 타당하다고 판단하면 변경 사항이 추가됩니다(!!!).

포크 워크플로우 예시

Forking Flow는 사용하려는 라이브러리가 있을 때 GitHub에서 사용됩니다. 제대로 사용하지 못하는 단점이 있습니다. 문제를 충분히 조사했고 해결책을 알고 있다고 가정해 보겠습니다. Forking Workflow 전략을 사용하면 원본 라이브러리 저장소에서 작업할 수 있는 권한을 부여하지 않고도 이 문제를 해결할 수 있습니다. 시작하려면 저장소(예: Spring Framework 코어) 를 선택해야 합니다 . 오른쪽 상단 모서리에 있는 포크(Fork) 버튼을 찾아 클릭하세요. 이 작업은 시간이 좀 걸리며 그 후 이 원본 저장소의 복사본이 사용자의 컴퓨터에 나타납니다. 포크임을 나타내는 개인 계정: 그런 다음 평소처럼 이 리포지토리로 작업하고 마스터 브랜치에 변경 사항을 추가한 다음 모든 것이 준비되면 원래 리포지토리에 대한 풀 요청을 생성할 수 있습니다. 이렇게 하려면 New Pull request 버튼을 클릭하세요 .

어떤 전략을 선택할 것인가

Git은 다양한 프로세스와 전략을 사용하여 작업할 수 있는 유연하고 강력한 도구입니다. 그러나 선택의 폭이 클수록 지금 어떤 전략을 선택할지 결정하는 것이 더 어렵습니다. 분명히 모든 경우에 적용되는 정답은 없습니다. 그것은 모두 상황에 달려 있습니다. 그러나 이에 도움이 될 수 있는 몇 가지 권장 사항이 있습니다.

1. 가장 간단한 전략을 먼저 선택하는 것이 좋습니다. 필요한 경우에만 더 복잡한 전략으로 이동하십시오.
2. 가능한 한 적은 유형의 개발자 브랜치를 포함하는 전략을 고려하세요.
3. 다양한 전략의 장단점을 살펴보고 프로젝트에 따라 올바른 전략을 선택하세요.

이것이 제가 git의 분기 전략에 대해 말씀드리고 싶은 전부입니다. 관심을 가져주셔서 감사합니다 :) 내 GitHub 계정을 구독하세요 . 저는 작업에 사용하는 다양한 기술과 도구에 대한 작업을 자주 게시합니다.

유용한 링크

• GitHub 흐름: Git 및 GitHub를 사용하는 가장 좋은 방법
• GitHub의 풀 요청 또는 다른 사람의 프로젝트를 어떻게 변경할 수 있나요?
• GitHub: 풀 요청 정보
• 지속적인 통합, 제공 및 배포의 차별화
• Git 기본: 태그 작업
• Habr: Git의 성공적인 분기 모델