주요 변경 사항에 대한 GitHub 기여 워크플로

Last update: Mon Jul 15 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

개요

이 워크플로는 주요 변경 작업을 수행해야 하거나 리포지토리에 자주 기여할 기여자에게 적합합니다. 일반적으로 빈번한 기여자에게는 여러 빌드/유효성 검사/스테이징 사이클을 거치거나, 가져오기 요청 승인 및 병합에 들어가기 전까지 여러 날에 걸쳐 진행 중인(장기 실행) 변경 사항이 있습니다.

용어

시작하기 전에 이 워크플로에서 사용되는 Git/GitHub 용어를 몇 가지 검토해 보겠습니다.

이름

설명

포크

일반적으로 명사로 사용되며, 이때 주 GitHub 리포지토리의 사본을 나타냅니다. 실제로 포크는 또 다른 리포지토리일 뿐입니다. 하지만 GitHub가 기본/상위 리포지토리에 양방향 연결을 유지한다는 점에서 포크는 특별한 의미를 갖습니다. “먼저 리포지토리를 포크해야 합니다”에서와 같이 때로는 동사로도 사용됩니다.

원격

“원본” 또는 “업스트림” 원격과 같이 원격 리포지토리에 대해 이름이 지정된 연결입니다. Git은 다른 컴퓨터에서 호스팅되는 리포지토리를 참조하는 데 사용되므로 이것을 원격이라고 합니다. 이 워크플로에서 원격은 항상 GitHub 리포지토리입니다.

원본

로컬 리포지토리와 로컬 리포지토리가 복제된 리포지토리 간 연결에 지정된 이름입니다. 이 워크플로에서 원본은 포크에 대한 연결을 나타냅니다. “원본에 변경 사항을 푸시해야 합니다”에서와 같이, 원본 리포지토리 자체에 대한 모니커로 사용되는 경우가 있습니다.

업스트림

원본 원격과 마찬가지로 업스트림 역시 또 다른 리포지토리에 대해 이름이 지정된 연결입니다. 이 워크플로에서 업스트림은 로컬 리포지토리와 포크를 만든 주 리포지토리 간의 연결을 나타냅니다. “업스트림에서 변경 사항을 가져와야 합니다”에서와 같이, 업스트림 리포지토리 자체에 대한 모니커로 사용되는 경우가 있습니다.

리포지토리 또는 분기와 같은 Git 및 GitHub 개념에 익숙하지 않다면 먼저 Git 및 GitHub 기본 사항을 검토하십시오.

워크플로

IMPORTANT

아직 완료하지 않았다면 설정 섹션의 단계를 완료해야 합니다.

이 워크플로에서는 변경 사항이 반복적인 사이클로 흐릅니다. 변경 사항은 디바이스의 로컬 리포지토리에서 시작하여 위의 GitHub 포크로 다시 이동하고 주 GitHub 리포지토리로 이동한 다음 다른 기여자의 변경 사항을 통합할 때 다시 아래의 로컬로 이동합니다.

GitHub 흐름 사용

Git 및 GitHub 기본 사항에서 Git 저장소에는 주 분기와 주 분기로 통합되지 않은 상태에서 작업이 진행 중인 추가 분기가 포함된다는 점을 상기하십시오. 논리적으로 연결된 변경 내용 집합을 새로 지정할 때마다 워크플로를 통해 변경 내용을 관리하는 작업 분기 를 만드는 것이 가장 좋습니다. 여기서 작업 분기라고 하는 이유는 변경 내용을 다시 주 분기로 통합하기 전까지 변경 내용을 반복/구체화하는 작업 영역이기 때문입니다.

특정 분기에 연결된 변경 내용을 격리하면 해당 변경 내용을 독립적으로 제어하고, 소개하고, 게시 주기에 있는 특정 릴리스 시점에 타겟팅할 수 있습니다. 실제로, 작업 유형에 따라 리포지토리에 몇 개의 작업 분기를 쉽게 구축할 수 있습니다. 각각 다른 프로젝트를 나타내는 여러 분기에서 동시에 작업하는 것은 일반적입니다.

NOTE

주 분기에서 변경 작업을 수행하는 것은 적절하지 않습니다. 기능을 특정 시점에 릴리스하기 위해 주 분기를 사용하여 변경 사항을 적용하는 경우를 생각해 보십시오. 변경을 완료하고 릴리스를 기다리고 있는데 그 사이에 어떤 문제를 수정해 달라는 긴급 요청이 있어서 주 분기에 있는 파일을 변경한 다음 해당 변경 사항을 게시합니다. 이 예에서는 해당 수정 사항 과 함께 특정 날짜에 릴리스하기 위해 보류 중이었던 변경 사항이 의도치 않게 모두 게시되었습니다.

다음 단계는 제안된 변경 사항을 캡처하기 위해 로컬 리포지토리에서 새 작업 분기를 만드는 것입니다. 각 Git 클라이언트는 서로 다르므로 선호하는 클라이언트에 대한 도움말을 참조하십시오. GitHub 흐름의 GitHub 안내서에서 프로세스 개요를 볼 수 있습니다.

가져오기 요청 처리

제안된 변경 사항은 대상 리포지토리의 PR(가져오기 요청) 대기열에 추가된 새 PR에서 번들로 묶어서 제출합니다. 가져오기 요청은 작업 분기의 변경 사항을 다른 분기로 가져와서 병합하도록 요구함으로써 GitHub의 협업 모델을 사용할 수 있도록 합니다. 대부분의 경우 이때의 다른 분기가 주 저장소의 기본/주 분기입니다.

유효성 검사

가져오기 요청을 대상 분기에 병합하려면 먼저 하나 이상의 PR 유효성 검사 프로세스를 통과해야 할 수도 있습니다. 유효성 검사 프로세스는 제안된 변경 사항의 범위와 대상 리포지토리의 규칙에 따라 달라질 수 있습니다. 가져오기 요청이 제출되면 내용 검토를 예상할 수 있으며, 혹시라도 적절하다면 내용의 주 리포지토리 병합을 예상할 수도 있습니다.

검토 및 승인

모든 PR 프로세스가 완료되면 결과(PR 댓글, 미리보기 URL 등)를 검토하여, 병합을 위해 승인하기 전에 해당 파일에 대한 추가 변경 내용이 필요한지 결정해야 합니다. PR 검토자가 가져오기 요청을 검토한 경우에는 병합하기 전에 해결해야 할 미해결 문제/질문이 있으면 댓글을 통해 피드백을 제공할 수도 있습니다.

가져오기 요청에 문제가 없고 승인되면 변경 사항이 상위 분기로 다시 병합되고 가져오기 요청이 닫힙니다.

게시

변경 사항이 그다음 예약된 게시 실행에 포함되려면 먼저 PR 검토자가 가져오기 요청을 병합해야 합니다. 가져오기 요청은 일반적으로 제출 순서로 검토/병합됩니다. 가져오기 요청이 특정 게시 실행을 위해 병합되어야 하는 경우 게시 전에 병합이 일어나도록 미리 PR 검토자와 작업해야 합니다.

recommendation-more-help

f0a0e44c-5d56-45af-ac98-47677caca18f