지속적인 업데이트를 위한 Git 분기 모델 살펴보기

3분

코드 작성의 목적은 소프트웨어에 향상된 기능을 제공하는 데 있습니다.

프로세스 오버헤드가 너무 많은 분기 모델은 고객에게 변경 내용을 가져오는 속도를 높이는 데 도움이 되지 않습니다. 분기 모델을 개발하면 품질이 저하되는 변경을 제공하지 않는 패딩을 충분히 얻을 수 있습니다. 그러나 동시에 너무 많은 프로세스를 도입하지 않아 속도가 저하되지 않습니다.

인터넷은 Git 분기 전략으로 가득 차 있습니다. 옳고 그름은 없지만 완벽한 분기 전략이 팀에 유효하게 작용합니다!

항상 기능 분기와 끌어오기 요청의 조합을 사용하여 즉시 제공할 수 있는 기본 분기를 갖추는 방법을 알아봅니다.

준비

그럼 제안 사항의 원칙을 살펴보겠습니다.

기본 분기:
- 기본 분기는 모든 항목을 프로덕션에 릴리스하는 유일한 방법입니다.
- 기본 분기는 항상 릴리스 준비 상태여야 합니다.
- 분기 정책으로 기본 분기를 보호합니다.
- 끌어오기 요청을 통해서만 기본 분기 흐름을 변경합니다.
- Git 태그로 기본 분기의 모든 릴리스를 태그합니다.
기능 분기:
- 새로운 모든 기능과 버그 수정에 기능 분기를 사용합니다.
- 기능 플래그를 사용하여 장기 실행되는 기능 분기를 관리합니다.
- 끌어오기 요청을 통해 기능 분기에서 기본 전용 흐름으로만 변경합니다.
- 용도를 반영하도록 기능의 이름을 지정합니다.
릴리스 분기:
- 안정적인 기능 분기에서 전용 릴리스 분기를 만들어 배포를 준비합니다.
- 릴리스 분기가 철저한 테스트 및 안정화 작업을 거치는지 확인합니다.
- 배포 전에 릴리스 분기에 버그 수정 및 필요한 변경 사항을 적용합니다.
- 릴리스 분기의 릴리스에 태그를 지정하여 중요한 마일스톤을 표시합니다.
분기 목록:
```
bugfix/description
features/feature-name
features/feature-area/feature-name
hotfix/description
users/username/description
users/username/workitem
```
끌어오기 요청:
- 끌어오기 요청으로 코드를 검토하고 병합합니다.
- 끌어오기 요청의 일부로 검사 및 유효성 검사 내용을 자동화합니다.
- 끌어오기 요청 완료 기간을 추적하고 목표를 설정하여 작업 소요 시간을 단축합니다.

이전 연습에서 만든 myWebApp을 사용합니다. 로컬의 Git 작업 설명을 참조하세요.

이 레시피에서는 마켓플레이스의 세 가지 인기 확장도 사용합니다.

Azure CLI: Azure 명령줄 인터페이스입니다.
Azure DevOps CLI: Git, CI 파이프라인 및 Agile 도구와 원활하게 통합되도록 설계된 Azure DevOps Server, Azure DevOps를 사용하기 위한 Azure CLI의 확장입니다. Azure DevOps CLI를 사용하면 명령줄을 종료하지 않고도 프로젝트에 기여할 수 있습니다. CLI는 Windows, Linux, Mac에서 실행됩니다.
Git 끌어오기 요청 병합 충돌: Microsoft DevLabs에서 만든 이 오픈 소스 확장을 사용하면 웹에서 끌어오기 요청 병합 충돌을 검토하고 해결할 수 있습니다. Git 끌어오기 요청을 완료하려면 먼저 대상 분기와의 충돌을 해결해야 합니다. 이 확장을 사용하면 병합하고 로컬 클론에서 충돌을 해결하는 대신 끌어오기 요청 병합의 일부로 웹에서 이러한 충돌을 해결할 수 있습니다.

Azure DevOps CLI는 JSON, JSONC, YAML, YAMLC, 테이블, TSV 및 none에서 쿼리 결과 반환을 지원합니다. 구성 명령을 사용하여 기본 설정을 구성할 수 있습니다.

작업 방법

중요

첫 번째 학습 경로: 로컬의 Git 작업 설명에서 프로젝트를 만들어야 합니다.

기본 분기를 로컬 리포지토리에 복제한 후 새 기능 분기, myFeature-1을 만듭니다.

myWebApp
```
git checkout -b feature/myFeature-1
```
출력:

새 분기 'feature/myFeature-1'로 전환되었습니다.
모든 분기를 보려면 Git 분기 명령을 실행하세요. 별표와 함께 표시되는 분기는 "현재 체크 아웃된" 분기입니다.

myWebApp
```
git branch
```
출력:

feature/myFeature-1

main
feature/myFeature-1 분기에서 Program.cs 파일을 변경합니다.

myWebApp
```
notepad Program.cs
```
변경 내용을 스테이징하여 로컬로 커밋한 후 분기를 원격에 게시합니다.

myWebApp
```
git status
```
출력:

분기 기능/myFeature-1에서 커밋을 위해 준비되지 않은 변경 사항: (커밋할 내용을 업데이트하려면 "git add <file>..."을 사용)(작업 디렉터리의 변경 사항을 취소하려면 "git checkout -- <file>..."을 사용)을 수정함: Program.cs.

myWebApp
```
git add .
git commit -m "Feature 1 added to Program.cs"
```
출력:

[feature/myFeature-1 70f67b2] feature 1이 program.cs에 추가됨, 1개 파일이 변경됨, 1개 삽입(+).

myWebApp
```
git push -u origin feature/myFeature-1
```
출력:

최대 8개의 스레드를 사용하여 델타 압축. 개체를 압축하는 중: 100% (3/3), 완료. 개체 작성: 100%(3/3), 348바이트 | 348.00 KiB/s, 완료. 총 3개(델타 2), 재사용됨 0(델타 0) 원격: 개체 분석 중... (3/3) (10ms) 원격: 팩 파일을 저장하는 중... 완료(44ms) 원격: 인덱스를 저장하는 중... 완료 (62ms) 원본에서 원격 분기 기능/myFeature-1을 추적하도록 설정된 https://dev.azure.com/organization/teamproject/\_git/MyWebApp *[새 분기] 'feature/myFeature-1 -> 기능/myFeature-1 분기 feature/myFeature-1로 전환되었습니다.

원격에는 변경 기록이 표시됩니다.
조직 및 프로젝트에 대한 Azure DevOps CLI를 구성합니다. 조직과 프로젝트 이름 바꾸기:
```
az devops configure --defaults organization=https://dev.azure.com/organization project="project name"
```
새 끌어오기 요청(Azure DevOps CLI 사용)을 만들어 feature-1 분기에서 변경 내용을 검토합니다.
```
az repos pr create --title "Review Feature-1 before merging to main" --work-items 38 39 `
--description "#Merge feature-1 to main" `
--source-branch feature/myFeature-1 --target-branch main `
--repository myWebApp --open
```
끌어오기 요청을 생성한 후 웹 브라우저에서 끌어오기 요청을 제기하여 열 때 --open 스위치를 사용합니다. 끌어오기 요청을 완료한 후에는 --deletesource-branch 스위치를 사용하여 분기를 삭제할 수 있습니다. 또한 모든 정책이 통과되고 원본 분기를 대상 분기에 병합할 수 있는 경우 --auto-complete를 사용하여 자동으로 완료하는 것이 좋습니다.

참고

az repos pr create 매개 변수에 관한 자세한 내용은 코드를 검토하고 병합하는 끌어오기 요청 만들기를 참조하세요.

팀은 코드 변경 내용을 공동으로 검토하고 끌어오기 요청을 승인합니다.

기본을 릴리스할 준비가 되었습니다. 팀은 릴리스 번호를 사용하여 기본 분기에 태그를 지정합니다.
기능 2에서 작업을 시작합니다. 기본 분기에서 원격으로 분기를 만들고 로컬에서 체크 아웃합니다.

myWebApp
```
git push origin main:refs/heads/feature/myFeature-2
```
출력:

총 0(델타 0), 재사용됨 0(델타 0) https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [새 분기] 원본/HEAD -> refs/heads/feature/myFeature-2.

myWebApp
```
git checkout feature/myFeature-2
```
출력:

원본에서 원격 분기 기능/myFeature-2를 추적하도록 설정된 새 분기 'feature/myFeature-2' 분기 기능/myFeature-2로 전환되었습니다.

feature-1에서 변경된 코드에서 동일한 주석 줄을 변경하여 Program.cs를 수정합니다.

public class Program
{
    // Editing the same line (file from feature-2 branch)
    public static void Main(string[] args)
    {
        BuildWebHost(args).Run();
    }

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>()
            .Build();

변경 내용을 로컬로 커밋하고 원격 리포지토리에 푸시한 후 끌어오기 요청을 실행하여 다음과 같이 feature/myFeature-2의 변경 내용을 기본 분기로 병합합니다.
```
az repos pr create --title "Review Feature-2 before merging to main" --work-items 40 42 `
--description "#Merge feature-2 to main" `
--source-branch feature/myFeature-2 --target-branch main `
--repository myWebApp --open
```
끌어오기 요청이 처리 중이면 feature-1 릴리스에 대해 프로덕션에서 중요한 버그가 보고됩니다. 이 문제를 조사하려면 현재 프로덕션에 배포된 코드 버전에 대해 디버그해야 합니다. 문제를 조사하려면 release_feature1 태그를 사용하여 새 fof 분기를 만듭니다.

myWebApp
```
git checkout -b fof/bug-1 release_feature1
```
출력:

새 분기 'fof/bug-1'로 전환되었습니다.

feature-1 릴리스에서 변경된 것과 동일한 코드 줄을 변경하여 Program.cs를 수정합니다.

public class Program
{
    // Editing the same line (file from feature-FOF branch)
    public static void Main(string[] args)
    {
        BuildWebHost(args).Run();
    }

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>()
            .Build();

변경 내용을 로컬로 스테이징 및 커밋한 후 원격 리포지토리에 변경 내용을 푸시합니다.

myWebApp
```
git add .
git commit -m "Adding FOF changes."
git push -u origin fof/bug-1
```
출력:

https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [새 분기] fof/bug-1 - 원본에서 원격 분기 fof/bug-1을 추적하도록 설정된 fof/bug-1 분기 fof/bug-1입니다.
변경 내용이 프로덕션에 롤아웃된 직후 release_bug-1 태그로 fof\bug-1 브랜치에 태그를 지정한 다음 끌어오기 요청을 발생시켜 fof/bug-1의 변경 내용을 다시 기본에 병합합니다.
```
az repos pr create --title "Review Bug-1 before merging to main" --work-items 100 `
--description "#Merge Bug-1 to main" `
--source-branch fof/Bug-1 --target-branch main `
--repository myWebApp --open
```
끌어오기 요청의 일부로 분기가 삭제됩니다. 그러나 태그를 사용하여 전체 기록을 계속 참조할 수 있습니다.

중요한 버그 수정이 끝났으니 feature-2 풀 리퀘스트를 검토해 봅시다.

분기 페이지를 통해 feature/myFeature-2 분기는 기본 앞에 한 가지 변경 내용이, 기본 뒤에 두 가지 변경 내용이 있음을 분명히 보여 줍니다.

끌어오기 요청을 승인하려고 하면 병합 충돌을 알리는 오류 메시지가 표시됩니다.
Git 끌어오기 요청 병합 충돌 해결 확장을 사용하면 브라우저에서 바로 병합 충돌을 해결할 수 있습니다. 충돌 탭으로 이동하고 Program.cs를 클릭하여 병합 충돌을 해결합니다.

사용자 인터페이스를 사용하면 원본 또는 대상을 가져오거나 사용자 지정 변경 내용을 추가하고 병합을 검토 및 제출할 수 있습니다. 변경 내용이 병합되면 끌어오기 요청이 완료됩니다.

이 시점에서 fof/bug-1 분기에 구현되고 마스터로 병합된 중요한 버그 수정을 기반으로 릴리스 분기를 만들 수 있습니다. git checkout 명령을 사용하여 마스터 분기에서 전용 릴리스 분기를 만듭니다.

git checkout -b release/v1.1 main

이 명령은 마스터 분기를 기반으로 release/v1.1이라는 새 분기를 만듭니다.

릴리스 프로세스 중에 중요한 마일스톤에 도달하면 Git 태그를 사용하여 릴리스 분기의 릴리스에 태그를 지정합니다. 태그는 소프트웨어의 특정 버전을 나타내는 표식 역할을 합니다.

git tag -a v1.1 -m "Release version 1.1"

이 명령은 v1.1이라는 태그를 만들어 릴리스 분기에서 릴리스 버전 1.1을 표시합니다.

작동 방식

Git 분기 모델에서 각 기능에 대한 분기를 만들어 병렬로 기능을 수행할 수 있는 유연성이 제공되는 방법을 배웠습니다.

끌어오기 요청 워크플로를 사용하면 분기 정책을 사용하여 코드 변경 내용을 검토할 수 있습니다.

Git 태그는 릴리스 코드의 버전 같은 마일스톤을 기록하는 좋은 방법입니다. 태그는 태그에서 분기를 만드는 방법을 제공합니다.

이전 릴리스 태그에서 분기를 만들어 프로덕션에 중요한 버그를 수정했습니다.

웹 포털에서 분기 뷰를 사용하면 기본보다 먼저 분기를 쉽게 식별할 수 있습니다. 또한 진행 중인 끌어오기 요청에서 병합 충돌을 해결하지 않고 기본에 병합하려고 하면 병합 충돌을 강제로 수행합니다.

간결한 분기 모델을 사용하면 단기 분기를 만들고 프로덕션에 품질 변경 내용을 더 빠르게 푸시할 수 있습니다.

지속적인 업데이트를 위한 Git 분기 모델 살펴보기

준비

작업 방법

작동 방식

피드백