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

소개

Git은 소프트웨어 개발에서 버전 제어 시스템의 사실상 업계 표준이 되었습니다. 먼저 Git이 무엇 이고 시작하는 방법 에 대한 내 기사를 읽어야 합니다 . 당신은 그것을 읽었습니까? 좋습니다. 시작하겠습니다! 좋든 싫든 Linus Tovalds가 만든 이 도구는 은퇴하지 않을 것입니다. 따라서 분산된 팀이 Git으로 작업하는 방법과 이를 위해 어떤 분기 전략을 선택해야 하는지에 대해 이야기하는 것이 이치에 맞습니다. 이것은 중요하지 않은 질문이 아닙니다. 이전에 함께 일한 적이 없는 새로운 개발 팀을 구성할 때 분기 전략은 종종 가장 먼저 결정해야 하는 것 중 하나입니다. 그리고 어떤 사람들은 한 전략이 다른 전략보다 낫다는 것을 증명하기 위해 입에 거품을 물고 있을 것입니다. 그래서 나는 그들에 대한 몇 가지 일반적인 정보를 여러분에게 전달하고 싶습니다.

분기 전략이 필요합니까?

그들은 참으로 필요합니다. 매우 필요합니다. 팀이 무언가에 동의하지 않으면 각 팀원이 원하는 대로 할 것이기 때문입니다.

• 어떤 부서에서 일하든
• 임의의 다른 분기로 병합
• 일부 분기 삭제
• 새로운 것 만들기
• 따라서 각 팀 구성원은 관리되지 않는 흐름에서 작동합니다.

그렇기 때문에 아래에서 고려해야 할 세 가지 전략이 있습니다. 갑시다!

GitHub 흐름

이상하게도 이 분기 전략은 GitHub에서 선호됩니다 :) 다음과 같은 규칙 세트가 제공됩니다 .

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

GitHub Flow에 따르면 수정 사항이든 새로운 기능이든 새로운 작업을 시작하기 전에 마스터를 기반으로 새 분기를 만들고 적절한 이름을 지정해야 합니다. 다음으로 구현 작업이 시작됩니다. 동일한 이름으로 원격 서버에 커밋을 지속적으로 제출해야 합니다. 모든 것이 준비되었다는 결론을 내리면 마스터 브랜치에 풀 요청을 생성해야 합니다. 그런 다음 "승인"을 클릭하기 전에 적어도 한 명 또는 더 나은 두 사람이 이 코드를 확인해야 합니다. 일반적으로 프로젝트의 팀장과 두 번째 사람이 반드시 살펴봐야 합니다. 그런 다음 풀 요청을 완료할 수 있습니다. GitHub Flow는 프로젝트에서 CD(Continuous Delivery)를 구동하는 것으로도 알려져 있습니다. 변경 사항이 마스터 브랜치로 이동하면 즉시 서버에 배포되어야 하기 때문입니다.

GitFlow

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

• 마스터: 아무도 이 나뭇가지를 만지거나 밀어서는 안 됩니다. 이 전략에서 마스터는 프로덕션(즉, 실제 서버)에서 사용되는 최신 안정 버전을 나타냅니다.
• 개발: 개발 브랜치. 불안정할 수 있습니다.

개발은 3개의 보조 임시 분기를 사용하여 이루어집니다 .

1. 기능 분기 — 새로운 기능을 개발하기 위한 것입니다.
2. 릴리스 브랜치 — 새 버전의 프로젝트 릴리스를 준비하기 위한 것입니다.
3. 핫픽스 분기 — 실제 서버에서 실제 사용자가 발견한 버그를 신속하게 수정하기 위한 것입니다.

기능 분기

기능 분기는 새로운 기능을 위해 개발자가 만듭니다. 항상 개발 브랜치를 기반으로 생성해야 합니다. 새 기능에 대한 작업을 완료한 후에는 개발 브랜치에 대한 풀 요청을 생성해야 합니다. 분명히 대규모 팀은 한 번에 둘 이상의 기능 분기를 가질 수 있습니다. GitFlow 전략 설명의 시작 부분에 있는 그림을 다시 살펴보십시오.

릴리즈 브랜치

필요한 새 기능 세트가 개발 브랜치에서 준비되면 제품의 새 버전 릴리스를 준비할 수 있습니다. 개발 브랜치를 기반으로 생성되는 릴리스 브랜치가 이에 도움이 될 것입니다. 릴리스 브랜치로 작업할 때 모든 버그를 찾아 수정해야 합니다. 릴리스 브랜치를 안정화하는 데 필요한 새 변경 사항도 개발 브랜치에 다시 병합해야 합니다. 이는 개발 지점을 안정화하기 위해서도 수행됩니다. 테스터가 분기가 새 릴리스에 대해 충분히 안정적이라고 말하면 마스터 분기로 병합됩니다. 나중에 이 커밋에 대해 버전 번호가 할당된 태그가 생성됩니다. 예를 보려면 전략 시작 부분의 그림을 보십시오. 태그 1.0이 표시됩니다.— 이것은 프로젝트의 버전 1.0을 나타내는 태그일 뿐입니다. 마지막으로 핫픽스 분기가 있습니다.

핫픽스 분기

핫픽스 분기는 마스터 분기에 새 버전을 릴리스하기 위한 것이기도 합니다. 유일한 차이점은 해당 릴리스가 계획되지 않았다는 것입니다. 출시된 버전에 버그가 들어와 프로덕션 환경에서 발견되는 경우가 있습니다. iOS를 예로 들어 보겠습니다. 새 버전이 출시되자마자 출시 후 발견된 버그에 대한 수정 사항이 포함된 업데이트를 즉시 받을 수 있습니다. 따라서 빠르게 버그를 수정하고 새 버전을 출시해야 합니다. 사진에서 이것은 버전 1.0.1에 해당합니다. 아이디어는 새로운 기능에 대한 작업이 실제 서버의 버그를 수정해야 할 때(또는 우리가 말하는 "프로덕션" 또는 "프로덕션") 중지할 필요가 없다는 것입니다. 핫픽스 분기는 현재 프로덕션에서 실행 중인 항목을 나타내므로 마스터 분기에서 만들어야 합니다. 버그 수정이 준비되는 대로 마스터로 병합되고 새 태그가 생성됩니다. 릴리스 브랜치를 준비하는 것과 마찬가지로 핫픽스 브랜치도 수정 사항을 개발 브랜치로 다시 병합해야 합니다.

포크 작업 흐름

분기 워크플로우에서 개발에는 두 개의 리포지토리가 포함됩니다.

1. 모든 변경 사항이 병합될 원래 리포지토리입니다.
2. 포크 저장소. 이것은 원본을 변경하려는 다른 개발자가 소유한 원본 리포지토리의 복사본입니다.

지금까지 조금 이상하게 들리나요? 이미 오픈 소스 개발을 경험한 사람이라면 누구나 이 접근 방식에 이미 익숙합니다. 이 전략은 다음과 같은 이점을 제공합니다. 개발은 원래 브랜치에서 공동 개발에 대한 권한을 부여하지 않고 포크 리포지토리에서 발생할 수 있습니다. 당연히 원래 리포지토리의 소유자는 제안된 변경 사항을 거부할 권리가 있습니다. 또는 수락하고 병합합니다. 이것은 원래 리포지토리의 소유자와 제품 생성을 돕고자 하는 개발자 모두에게 편리합니다. 예를 들어 Linux 커널 에 대한 변경 사항을 제안할 수 있습니다 . Linus가 의미가 있다고 판단하면 변경 사항이 추가됩니다(!!!).

분기 작업 흐름의 예

Forking 워크플로는 사용하려는 라이브러리가 있는 경우 GitHub에 적용됩니다. 완전히 사용하지 못하게 하는 버그가 있습니다. 당신이 문제에 대해 충분히 깊이 파고들어 해결책을 알고 있다고 가정해 봅시다. 포크 워크플로를 사용하면 라이브러리의 원래 리포지토리에서 작업할 수 있는 권한 없이 문제를 해결할 수 있습니다. 시작하려면 Spring Framework 와 같은 일부 리포지토리를 선택해야 합니다 . 오른쪽 상단 모서리에 있는 "포크" 버튼을 찾아 클릭합니다. 시간이 좀 걸립니다. 그러면 원본 리포지토리의 복사본이 개인 계정에 나타나 포크임을 나타냅니다.이제 평소처럼 이 리포지토리를 사용하여 마스터 브랜치에 변경 사항을 추가하고 모든 것이 준비되면 원래 리포지토리에 풀 요청을 생성할 수 있습니다. 이렇게 하려면 New pull request 버튼을 클릭합니다.

선택할 전략

Git은 다양한 프로세스와 전략을 사용하여 작업할 수 있는 유연하고 강력한 도구입니다. 하지만 선택지가 많을수록 어떤 전략을 선택할지 결정하기가 더 어려워집니다. 모든 사람에게 단일한 답이 없다는 것은 분명합니다. 모든 것은 상황에 달려 있습니다. 즉, 이에 도움이 되는 몇 가지 지침이 있습니다.

1. 가장 간단한 전략을 먼저 선택하는 것이 가장 좋습니다. 필요할 때만 더 복잡한 전략으로 이동하십시오.
2. 개발자를 위해 분기 유형이 가능한 한 적은 전략을 고려하십시오.
3. 다양한 전략의 장단점을 살펴본 다음 프로젝트에 필요한 전략을 선택하십시오.

이것이 제가 Git의 분기 전략에 대해 말하고 싶었던 전부입니다. 관심을 가져주셔서 감사합니다 :) GitHub 에서 저를 팔로우하세요 . 제가 작업에 사용하는 다양한 기술 및 도구와 관련된 창작물을 자주 게시합니다.