풀 요청으로 협업 개선

반응형

이 기사는 "Advanced Git" 시리즈의 일부입니다. 트위터에서 저희를 팔로우하거나 뉴스레터에 등록하여 다음 기사에 대해 들어보시기 바랍니다!

이번 "Advanced Git" 시리즈 3편에서는 소규모 및 대규모 개발자 팀에 모두 도움이 되는 풀 리퀘스트에 대해 알아보겠습니다. 꺼내기 요청은 검토 및 피드백 프로세스를 개선할 뿐만 아니라 코드 변경 사항을 추적하고 논의하는 데도 도움이 됩니다. 마지막으로, 끌어오기 요청은 쓰기 권한이 없는 다른 리포지토리에 기여할 수 있는 이상적인 방법입니다.

풀 요청이란 무엇입니까?

우선, 꺼내기 요청이 핵심 Git 기능이 아니라는 것을 이해하는 것이 중요합니다. 대신 사용 중인 Git 호스팅 플랫폼에 의해 제공됩니다. GitHub, GitLab, Bitbucket, AzureDevops 및 기타 플랫폼에는 모두 이러한 기능이 내장되어 있습니다.

꺼내기 요청을 만들어야 하는 이유는 무엇입니까?

 

완벽한 풀 요청을 만드는 방법에 대해 자세히 설명하기 전에 이 기능을 사용하는 이유에 대해 살펴보겠습니다.

소프트웨어의 새 기능을 방금 완료했다고 가정해 보십시오. 형상 분기에서 작업했으므로 다음 단계는 형상 분기를 메인라인 분기(마스터 또는 메인)에 병합하는 것입니다. 예를 들어, 만약 당신이 프로젝트의 유일한 개발자이거나 당신이 충분히 경험이 있고 당신의 팀원들이 그것에 대해 기뻐할 것이라는 것을 안다면, 이것은 어떤 경우에는 완전히 괜찮다.

그나저나: 지점과 일반적인 분기 워크플로우에 대해 자세히 알고 싶다면 "고급 Git" 시리즈의 두 번째 기사 "Git의 분기 전략"을 살펴보십시오.

하지만, 만약 여러분의 변화가 조금 더 복잡해서 여러분이 다른 사람이 여러분의 작품을 봐주기를 원한다면 어떻게 될까요? 이것이 풀 요청이 이루어진 이유입니다. 꺼내기 요청을 사용하면 다른 사용자를 초대하여 자신의 작업을 검토하고 피드백을 제공할 수 있습니다.

 

꺼내기 요청이 열리면 다른 개발자와 코드를 논의할 수 있습니다. 대부분의 Git 호스팅 플랫폼은 다른 사용자가 설명을 추가하고 프로세스 중에 변경 사항을 제안할 수 있도록 허용합니다. 검토자가 작업을 승인하면 다른 분기로 병합될 수 있습니다.

그러나 검토 워크플로우가 있는 것이 꺼내기 요청의 유일한 이유는 아닙니다. 쓰기 권한이 없는 다른 리포지토리에 기여하려는 경우 유용합니다. 모든 오픈 소스 프로젝트를 생각해 보십시오. 새로운 기능에 대한 아이디어가 있거나 패치를 제출하고 싶은 경우, 풀 리퀘스트(pull request)는 프로젝트에 참여하지 않고도 아이디어를 제시할 수 있는 좋은 방법입니다.

이를 통해 꺼내기 요청과 밀접하게 연결된 항목인 포크(fork)를 살펴보겠습니다.

 

포크 작업

포크는 기존 Git 리포지토리의 개인 복사본입니다. Open Source 예제로 돌아가서, 첫 번째 단계는 원래 리포지토리의 포크를 만드는 것입니다. 그런 다음 개인 복사본에서 코드를 변경할 수 있습니다.

작업을 완료한 후 꺼내기 요청을 열어 원래 리포지토리의 소유자에게 변경 사항을 포함하도록 요청합니다. 소유자 또는 다른 주요 기여자 중 한 명이 코드를 검토한 후 포함(또는 포함하지 않음)을 결정할 수 있습니다.

 

중요: 꺼내기 요청은 항상 분기에 기반하며 개별 커밋에 기반하지 않습니다! 꺼내기 요청을 만들 때 특정 분기를 기반으로 하여 포함되도록 요청합니다.

검토자의 삶을 편리하게 만들기: 끌어당기는 요청을 만드는 방법

앞서 언급한 바와 같이 풀 리퀘스트는 핵심 Git 기능이 아닙니다. 그 대신 모든 Git플랫폼 자체 디자인과 어떻게 연줄 요청해야 한다에 대한 자신의 생각을 갖고 있다. GitLab, GitHub, Bitbucket 등에서는 다르게 보입니다. 모든 플랫폼에는 변경 사항을 추적, 토론 및 검토하는 워크플로우가 약간씩 다릅니다.

예를 들어, Tower Git 클라이언트와 같은 데스크톱 GUI는 이를 더 쉽게 만들 수 있습니다. 어떤 코드 호스팅 서비스를 사용하든 일관된 사용자 인터페이스를 제공합니다.

 

그러나 일반 워크플로우는 항상 동일하며 다음 단계를 포함합니다.

• 해당 리포지토리에 대한 쓰기 권한이 없는 경우 첫 번째 단계는 포크(즉, 개인 버전의 리포지토리)를 만드는 것입니다.
• 포크 저장소에 새 로컬 분기를 만듭니다. (다시 알림: 꺼내기 요청은 커밋이 아닌 분기를 기반으로 합니다!)
• 로컬 분기를 변경하고 커밋합니다.
• 변경 사항을 원격 리포지토리에 푸시합니다.
• 변경 사항을 포함하는 꺼내기 요청을 만들고 다른 사용자와 토론을 시작합니다.

풀 리퀘스트 자체와 다른 개발자의 삶을 더 쉽게 만들어 주는 풀 리퀘스트를 만드는 방법에 대해 알아보겠습니다. 우선, 그것은 빨리 검토될 수 있도록 짧아야 한다. 30줄이 아니라 3000줄을 보면 코드를 이해하기 어렵다.

또한, 분명하고 좋은 제목과 의미 있는 설명을 반드시 추가하세요. 변경한 내용, 꺼내기 요청을 연 이유 및 변경 사항이 프로젝트에 미치는 영향을 설명하십시오. 대부분의 플랫폼에서는 변경 사항을 설명하는 데 도움이 되는 스크린샷을 추가할 수 있습니다.

 

승인, 병합 또는 거부?

변경사항이 승인되면 사용자(또는 쓰기 권한이 있는 사용자)는 분기 분기 분기(forked branch)를 기본 분기에 병합할 수 있습니다. 하지만 검토자가 꺼내기 요청을 현재 상태로 병합하지 않으려면 어떻게 해야 합니까? 언제든지 새 커밋을 추가할 수 있으며 분기를 푸시한 후에는 기존 꺼내기 요청이 업데이트됩니다.

또는 소유자 또는 쓰기 권한이 있는 다른 사용자가 변경 사항을 병합하지 않으려는 경우 꺼내기 요청을 거부할 수 있습니다.

개발자용 안전망

보시다시피 풀 리퀘스트는 동료 개발자들과 소통하고 협업할 수 있는 좋은 방법입니다. 다른 사람에게 작업을 검토하도록 요청하면 고품질 코드만 코드베이스에 입력되도록 할 수 있습니다.

 

고급 Git 도구에 대해 자세히 알고 싶으시다면, 제 (공짜)를 마음껏 확인해 보십시오! "Advanced Git Kit": 분기 전략, 대화형 기본 설정, Reflog, 하위 모듈 등과 같은 주제에 대한 짧은 비디오 모음입니다.