풀 리퀘스트 생성 및 검토

풀 리퀘스트(PR)는 GitHub 같은 플랫폼에서 협업 개발의 핵심입니다. 풀 리퀘스트는 프로젝트에 변경 사항을 제안하고 통합하기 전에 검토받는 방법입니다.

PR을 새 코드를 일반적으로 main 또는 develop인 메인 브랜치에 병합해 달라는 공식 요청이라고 생각해 보십시오.

PR은 팀과 개인 개발자에게 다음과 같은 주요 이점을 제공합니다.

• 코드 검토: 다른 사람이 코드의 버그, 모범 사례 준수 여부 및 개선점을 검토할 수 있습니다.
• 논의: 변경 사항을 논의할 전용 공간을 제공합니다.
• 품질 관리: 승인되고 테스트된 코드만 주요 프로젝트에 포함되도록 합니다.
• 변경 사항 추적: 누가 무엇을, 왜 변경했는지 명확한 기록을 남깁니다.

일반적인 풀 리퀘스트 작업 흐름은 다음 단계로 이루어집니다.

1. 기능 또는 수정 작업을 위한 새 브랜치를 만듭니다.
2. 변경 사항을 적용하고 새 브랜치에 커밋합니다.
3. 브랜치를 GitHub에 푸시합니다.
4. GitHub에서 풀 리퀘스트를 엽니다.
5. 검토자가 피드백을 제공하고 승인합니다.
6. 변경 사항을 메인 브랜치에 병합합니다.

변경 작업을 시작하기 전에 새 브랜치를 만드는 것이 좋습니다. 이렇게 하면 작업이 완료될 때까지 메인 프로젝트와 분리된 상태로 작업할 수 있습니다.

git checkout -b를 사용하여 새 브랜치를 만들고 전환하십시오.

이제 기능이나 버그 수정에 필요한 코드를 변경하세요. 완료한 후에는 다른 Git 커밋과 마찬가지로 변경 사항을 스테이징하고 새 브랜치에 커밋하세요.

로컬에서 변경 사항을 커밋한 후, 새 브랜치를 GitHub의 원격 저장소로 푸시하세요. 그러면 브랜치와 해당 커밋이 온라인에 표시됩니다.

-u 플래그는 업스트림 브랜치를 설정하므로 이후의 git push 명령을 더 간단하게 사용할 수 있습니다.

브랜치를 푸시하면 GitHub에서 일반적으로 저장소 페이지나 '풀 리퀘스트' 탭을 통해 직접 풀 리퀘스트를 만들도록 안내합니다.

• 기능 브랜치를 헤드(소스)로 선택하세요.
• main(또는 대상) 브랜치를 베이스로 선택하세요.
• 변경 사항을 설명하는 명확한 제목과 설명을 추가하세요.

풀 리퀘스트를 열면 검토 단계가 시작됩니다. 팀원(검토자)이 코드를 살펴보고 질문하거나 개선 사항을 제안합니다.

• 대화 탭: 토론과 댓글을 확인합니다.
• 변경된 파일 탭: 코드의 정확한 차이점(diff)을 확인합니다.
• 커밋 탭: 풀 리퀘스트의 개별 커밋을 확인합니다.

검토자는 코드 줄에 직접 댓글을 남기거나 일반적인 피드백을 제공할 수 있습니다. 그런 다음 다음 작업을 수행할 수 있습니다.

• 승인: 코드를 병합해도 좋습니다.
• 변경 요청: 병합하기 전에 추가 작업이 필요합니다.
• 댓글: 병합을 막지 않는 일반적인 피드백을 남깁니다.

피드백에 따라 기능 브랜치에 커밋을 더 추가해야 할 수도 있습니다.

승인을 받으면 PR을 베이스 브랜치에 병합할 수 있습니다. GitHub에서는 몇 가지 병합 옵션을 제공합니다.

• 병합 커밋: 기능 브랜치의 모든 커밋을 유지합니다.
• 스쿼시 후 병합: 모든 커밋을 하나의 새 커밋으로 합칩니다.
• 리베이스 후 병합: 기능 브랜치의 커밋을 베이스 브랜치 위에 다시 적용합니다.

선택한 방법은 프로젝트의 커밋 기록에 영향을 줍니다.

방금 풀 리퀘스트를 만들고 관리하는 핵심 단계를 배웠습니다. 이제 이해한 내용을 확인해 보겠습니다!

풀 리퀘스트는 현대적인 팀 협업의 핵심입니다. 다음 방법을 배웠습니다.

• 작업을 위한 새 브랜치 만들기
• 브랜치를 GitHub로 푸시하기
• 풀 리퀘스트 시작하기
• 검토 및 승인 과정 이해하기
• 변경 사항을 주 프로젝트에 병합하기

PR을 능숙하게 사용하는 것은 Git 기반 프로젝트에 효과적으로 기여하는 데 중요합니다!