풀 리퀘스트 만들기
Pull requests are a feature that makes it easier for developers to collaborate using Bitbucket. They provide a user-friendly web interface for discussing proposed changes before integrating them into the official project.
가장 간단한 형태의 풀리퀘스트는 개발자가 팀원에게 기능을 완료했음을 알리는 메커니즘입니다. 기능 브랜치가 준비되면 개발자는 Bitbucket 계정을 통해 풀리퀘스트를 제출합니다. 이를 통해 참여한 모든 팀원이 코드를 검토하고 main 브랜치로 병합해야 한다는 것을 알 수 있습니다.
하지만 풀리퀘스트는 단순한 알림 그 이상으로, 제안된 기능에 대해 논의하기 위한 전용 포럼입니다. 변경 사항에 문제가 있으면 팀원이 풀리퀘스트에 피드백을 게시하고 후속 커밋을 푸시하여 기능을 조정할 수도 있습니다. 이 모든 활동은 풀리퀘스트 내에서 바로 추적됩니다.
다른 공동 작업 모델과 비교했을 때 커밋 공유를 위한 이 공식적인 솔루션은 워크플로를 훨씬 더 간소화합니다. SVN과 Git 모두 간단한 스크립트로 알림 이메일을 자동으로 보낼 수 있습니다. 하지만 변경 사항에 대해 논의할 때 개발자는 보통 이메일 스레드에 의존해야 합니다. 이것은 무계획적으로 이루어질 수 있으며 특히 후속 커밋이 관련된 경우에는 더욱 그렇습니다. 풀리퀘스트는 이 모든 기능을 Bitbucket 리포지토리 바로 옆에 있는 친숙한 웹 인터페이스에서 사용할 수 있도록 합니다.
풀리퀘스트의 구조
풀 리퀘스트를 파일링하는 경우 수행해야 하는 모든 작업은 다른 개발자(예: 프로젝트 유지 관리자)가 사용자의 리포지토리에서 개발자의 리포지토리로 브랜치를 끌어오도록 요청하는 것입니다. 이는 풀 리퀘스트를 파일링하도록 소스 리포지토리, 소스 브랜치, 대상 리포지토리 및 대상 브랜치의 4가지 정보를 제공해야 함을 의미합니다.
대부분의 값은 Bitbucket에서 적절한 기본값으로 설정됩니다. 하지만 공동 작업 워크플로에 따라 팀에서 다른 값을 지정해야 할 수도 있습니다. 위의 다이어그램은 기능 브랜치를 공식적인 main 브랜치에 병합하도록 요청하는 풀리퀘스트를 보여주지만 풀리퀘스트를 사용하는 다른 방법도 많습니다.
작동 방식
풀 리퀘스트는 기능 브랜치 워크플로우, Gitflow 워크플로우 또는 포킹 워크플로우과 함께 사용할 수 있습니다. 풀 리퀘스트에는 중앙 집중화된 워크플로우와 작동하지 않도록 두 개의 고유한 브랜치 또는 두 개의 고유한 리포지토리가 필요합니다. 풀 리퀘스트를 이러한 각각의 워크플로우와 함께 사용하는 것은 약간 다르지만 일반적인 프로세스는 다음과 같습니다.
1. 개발자가 로컬 리포지토리의 전용 브랜치에서 기능을 만듭니다.
2. The developer pushes the branch to a public Bitbucket repository.
3. The developer files a pull request via Bitbucket.
4. The rest of the team reviews the code, discusses it, and alters it.
5. The project maintainer merges the feature into the official repository and closes the pull request.
이 섹션의 나머지 부분에서는 여러 공동 작업 워크플로에 대해 풀리퀘스트를 활용하는 방법을 설명합니다.
관련 자료
고급 Git 로그
솔루션 보기
Bitbucket Cloud에서 Git에 대해 알아보기
풀리퀘스트가 있는 기능 브랜치 워크플로
기능 브랜치 워크플로는 공동 작업 관리에 공유 Bitbucket 리포지토리를 사용하고 개발자는 분리된 브랜치에서 기능을 만듭니다. 그러나 즉시 main으로 병합하는 대신에 개발자는 풀리퀘스트를 열어 메인 코드베이스로 통합되기 전에 기능에 대한 논의를 시작해야 합니다.
풀리퀘스트의 대상 리포지토리와 소스 리포지토리가 항상 동일하도록 기능 브랜치 워크플로에는 하나의 공용 리포지토리만 있습니다. 일반적으로 개발자는 기능 브랜치를 소스 브랜치로 지정하고, main 브랜치를 대상 브랜치로 지정합니다.
풀리퀘스트를 받고 나면 프로젝트 관리자는 무엇을 해야 할지 결정해야 합니다. 기능을 사용할 준비가 되면 main에 병합하고 풀리퀘스트를 종료할 수 있습니다. 하지만 제안된 변경 사항에 문제가 있는 경우 풀리퀘스트에 피드백을 게시할 수 있습니다. 후속 커밋은 관련 댓글 바로 옆에 표시됩니다.
완료하지 않은 기능에 대한 풀리퀘스트를 제출하는 것도 가능합니다. 예를 들어, 개발자가 특정 요구 사항을 구현하는 데 어려움을 겪고 있다면 진행 중인 작업이 포함된 풀리퀘스트를 제출할 수 있습니다. 그러면 다른 개발자가 풀리퀘스트 내에서 제안을 하거나 추가 커밋을 통해 직접 문제를 해결할 수도 있습니다.
풀리퀘스트가 있는 Gitflow 워크플로
Gitflow 워크플로는 기능 브랜치 워크플로와 비슷하지만 프로젝트 릴리스를 중심으로 설계된 엄격한 브랜칭 모델을 정의합니다. Gitflow 워크플로에 풀리퀘스트를 추가하면 개발자가 작업하는 동안 릴리스 브랜치나 유지 관리 브랜치에 대해 편리하게 이야기할 수 있는 공간이 됩니다.
Gitflow 워크플로의 풀리퀘스트 메커니즘은 이전 섹션과 동일합니다. 개발자가 기능, 릴리스 또는 핫픽스 브랜치를 검토해야 할 때 풀리퀘스트를 제출하기만 하면 나머지 팀원들은 Bitbucket을 통해 알림을 받게 됩니다.
기능은 일반적으로 develop 브랜치로 병합되지만 릴리스 및 핫픽스 브랜치는 모두 develop 및 main으로 병합됩니다. 풀리퀘스트는 이러한 모든 병합을 공식적으로 관리하는 데 사용할 수 있습니다.
풀리퀘스트가 있는 포킹 워크플로
포킹 워크플로우에서 개발자는 전체 기능을 공유된 리포지토리가 아닌 자체 공용 리포지토리에 푸시합니다. 그 다음에 풀 리퀘스트를 파일링하여 프로젝트 유지 관리자가 검토할 준비가 되었음을 알도록 합니다.
프로젝트 관리자는 다른 개발자가 Bitbucket 리포지토리에 커밋을 추가한 시점을 알 수 있는 방법이 없기 때문에 풀리퀘스트의 알림 기능은 이 워크플로에서 특히 유용합니다.
각 개발자에게는 자체 공용 리포지토리가 있으므로 풀리퀘스트의 소스 리포지토리는 대상 리포지토리와 다릅니다. 소스 리포지토리는 개발자의 공용 리포지토리이며 소스 브랜치는 제안된 변경 사항이 포함된 리포지토리입니다. 개발자가 기능을 메인 코드베이스로 병합하려는 경우 대상 리포지토리는 공식 프로젝트이며 대상 브랜치는 main입니다.
또한 풀 리퀘스트는 공식 프로젝트 외부에 있는 다른 개발자와 협업하는 데 사용할 수 있습니다. 예를 들어 팀원과 함께 기능을 작업한 경우 공식 프로젝트 대신 대상에 대해 팀원의 Bitbucket 리포지토리를 사용하여 풀 ㅣ퀘스트를 파일링할 수 있습니다. 그러면 소스 및 대상 브랜치에 대해 동일한 기능 브랜치를 사용합니다.
두 개발자가 풀리퀘스트 내에서 기능에 대해 논의하고 개발할 수 있습니다. 기능 개발을 완료하면 그중 한 명이 공식적인 main 브랜치에 기능 병합을 요청하는 또 다른 풀리퀘스트를 제출합니다. 풀리퀘스트는 이러한 유연성 덕분에 포킹 워크플로에서 매우 효과적인 공동 작업 도구입니다.
예
아래 예시는 포킹 워크플로에서 풀리퀘스트를 사용하는 방법을 보여줍니다. 소규모 팀에서 일하는 개발자와 오픈 소스 프로젝트에 기여하는 타사 개발자에게도 동일하게 적용됩니다.
이 예시에서 Mary는 개발자이며 John은 프로젝트 관리자입니다. 둘 다 각자 공개 Bitbucket 리포지토리를 가지고 있으며 John의 리포지토리에는 공식 프로젝트가 있습니다.
공식 프로젝트를 포크하는 Mary
프로젝트에서 작업을 시작하려면 Mary는 먼저 John의 Bitbucket 리포지토리를 포크해야 합니다. Bitbucket에 로그인하고 John의 리포지토리로 이동한 다음 포크 버튼을 클릭하여 이를 수행할 수 있습니다.
Mary가 포크된 리포지토리의 이름과 설명을 입력하면 프로젝트의 서버 측 복사본을 가지게 됩니다.
Bitbucket 리포지토리를 복제하는 Mary
다음으로 Mary는 방금 포크한 Bitbucket 리포지토리를 복제해야 합니다. 그러면 로컬 컴퓨터에 프로젝트의 작업 복사본이 만들어집니다. Mary는 다음 명령을 실행하여 이 작업을 수행할 수 있습니다.
git clone https://user@bitbucket.org/user/repo.gitgit clone Mary의 포크된 리포지토리를 다시 가리키는 origin 리모트를 자동으로 생성합니다.
새 기능을 개발하는 Mary
Mary는 코드를 작성하기 전에 기능에 대한 새 브랜치를 만들어야 합니다. 이 브랜치는 풀리퀘스트의 소스 브랜치로 사용됩니다.
git checkout -b some-feature
# Edit some code
git commit -a -m "Add first draft of some feature"Mary는 기능을 생성하는 데 필요한 만큼 많은 커밋을 사용할 수 있습니다. 또한 기능 기록이 예상보다 더 복잡한 경우 대화형 기준 재지정을 사용하여 필요없는 커밋을 제거하거나 삭제할 수 있습니다. 대형 프로젝트의 경우 기능 기록을 정리하면 프로젝트 유지 관리자가 풀 리퀘스트의 상황을 더욱 쉽게 확인할 수 있습니다.
Bitbucket 리포지토리에 기능을 푸시하는 Mary
기능이 완료되면 Mary는 간소화된 git 푸시를 사용하여 기능 브랜치를 자체 Bitbucket 리포지토리(공식 리포지토리가 아님)로 푸시합니다.
git push origin some-branch이렇게 하면 프로젝트 관리자(또는 액세스 권한이 필요한 모든 공동 작업자)가 변경 사항을 확인할 수 있습니다.
풀리퀘스트를 만드는 Mary
Bitbucket에 기능 브랜치가 있으면 Mary는 포크된 리포지토리로 이동하고 오른쪽 상단 모서리에 있는 풀 리퀘스트 버튼을 클릭하여 Bitbucket 계정을 통해 풀 리퀘스트를 생성할 수 있습니다. 소스 리포지토리로 Mary의 리포지토리가 자동으로 설정되며 소스 브랜치, 대상 리포지토리 및 대상 브랜치 지정을 요청합니다.
Mary는 소스 브랜치가 자신의 기능 브랜치이고, 대상 리포지토리가 John의 공용 리포지토리이며, 대상 브랜치가 main이 되도록 기능을 메인 코드베이스에 병합하려고 합니다. 또한 풀리퀘스트에 대한 제목과 설명을 제공해야 합니다. John 외에도 코드를 승인해야 하는 다른 팀원이 있는 경우 검토자 필드에 입력할 수 있습니다.
Mary가 풀리퀘스트를 만들면 Bitbucket 피드를 통해 그리고 (선택적으로) 이메일을 통해 John에게 알림이 전송됩니다.
풀리퀘스트를 검토하는 John
John은 자체 Bitbuck 리포지토리에서 풀 리퀘스트 탭을 클릭하여 사람들이 파일링한 모든 풀 리퀘스트에 액세스할 수 있습니다. Mary의 풀 리퀘스트를 클릭하면 풀 리퀘스트의 설명, 기능의 커밋 기록 및 포함하고 있는 모든 변경 사항의 차이가 표시됩니다.
기능을 프로젝트에 병합할 준비가 되었다고 생각되는 경우 John은 병합 버튼을 눌러 풀리퀘스트를 승인하고 Mary의 기능을 자신의 main 브랜치에 병합하기만 하면 됩니다.
하지만 이 예시에서 John이 Mary의 코드에서 작은 버그를 발견했고 병합하기 전에 Mary가 버그를 수정해야 한다고 가정해 보겠습니다. 풀리퀘스트에 전체적으로 댓글을 추가하거나 기능 기록에서 특정 커밋을 선택하여 댓글을 추가할 수 있습니다.
후속 커밋을 추가하는 Mary
Mary가 피드백에 대해 질문이 있는 경우 풀리퀘스트를 해당 기능에 대해 논의하는 포럼처럼 사용하여 답할 수 있습니다.
오류를 수정하기 위해 Mary는 처음과 마찬가지로 기능 브랜치에 또다른 커밋을 추가하고 Bitbucket 리포지토리에 푸시합니다. 이 커밋은 원래 풀리퀘스트에 자동으로 추가되며 John은 원래 댓글 바로 옆에서 변경 사항을 다시 검토할 수 있습니다.
풀리퀘스트를 수락하는 John
마지막으로 John은 변경 사항을 수락하고 기능 브랜치를 main으로 병합한 후 풀리퀘스트를 종료합니다. 이제 기능은 프로젝트에 통합되었으며 이 기능에 대해 작업 중인 다른 개발자는 표준 git pull 명령을 사용하여 자신의 로컬 리포지토리로 풀할 수 있습니다.
여기에서 나아가야 할 방향
이제 기존 워크플로우로의 풀 리퀘스트 통합을 시작하는 데 필요한 모든 도구가 준비되었습니다. 풀 리퀘스트는 Git 기반 협업 워크플로우에 대한 대체 방법이 아니지만 모든 팀 구성원이 더 쉽게 협업할 수 있도록 하는 편리한 추가 기능입니다.
이 문서 공유
다음 토픽
여러분께 도움을 드릴 자료를 추천합니다.
이러한 리소스에 책갈피를 지정하여 DevOps 팀의 유형에 대해 알아보거나 Atlassian에서 DevOps에 대한 지속적인 업데이트를 확인하세요.
Bitbucket 블로그
DevOps 학습 경로
