28. Visual Studio Code 및 GitHub로 풀 요청(Pull Request) 작업하기

<참조> https://azuredevopslabs.com/labs/azuredevops/githubpullrequests/

 

 

 

 

이번 글에서는 VIsual Studio Code와 GitHub를 사용하여 Pull Requests를 수행하는 방법에 대해 살펴 보고자 한다.

 

 

 

 

 

개요

팀은 코드를 마스터 브랜치에 병합하기 전에 Pull request(풀 요청)를 통해 기능 브랜치 변경에 대한 피드백을 제공 할 수 있다. 검토자는 제안 된 변경 사항을 단계별로 진행하고 의견을 남기며 코드를 승인 또는 거부하도록 의사를 표할 수 있다. GitHub와 Visual Studio Code 확장 기능은 풀 요청을 생성, 검토 및 승인 할 수 있는 풍부한 경험을 제공한다.

 

 

 

 

 

 

 

 

선행 조건

 

• 이 랩은 선행 조건으로 Git with GitHub lab을 완료해야 한다.

 

 

 

 

 

 

 

 

 

실습 1: 풀 요청 작업하기

 

Git 랩을 마칠 때, 새로운 브랜치를 만들고 코드 일부를 변경했다. 이제 변경 사항을 새 브랜치에 커밋하고 서버로 푸시해야한다. 그 상태가 되면 브랜치를 마스터와 병합 할 수 있도록 풀 요청을 작성할 수 있다.

 

과제 1: 새로운 작업 일감 생성하기

1. GitHub 브라우저 탭으로 돌아가서 포크받은 저장소로 이동한다.

 

2. Settings 탭으로 이동한다. 이 실습에서는 프로젝트에서 문서화 된 문제를 해결하도록 설계된 풀 요청을 생성할 것이며, 이 요청은 시작 전에 정의 할 것이다.

 

3. Enable the Issues 기능을 활성화 한다. 

 

4. Issues 탭으로 이동한다.

 

5. New Issue를 클릭한다.

 

6. “Change Category.cs” 라는 새 이슈를 생성하고 Submit new issue을 클릭한다.

 

7.  새 이슈는 ID 1로 생성되어야 하지만, 다른 경우에는 ID를 메모 해 둔다. 

 

과제 2: 새로운 풀 요청 생성하기

1. Visual Studio Code로 돌아간다.

 

2. Extensions 탭을 선택하고 "github"을 검색하여. GitHub Pull Requests를 Install을 클릭한다. 

 

3. Ctrl|Shift+P를 눌러하여 Command Palette를 연다. 

 

4. sign in을 검색하고 풀 요청 확장을 위해 GitHub에 로그인하는 옵션을 클릭한다.

 

5. 프로세스에 따라 확장 프로그램이 GitHub와 통합 할 수있는 권한을 완료한다.

 

6.  Source Control 탭을 선택한다. Category.cs에 대한 커밋되지 않은 변경 사항이 있음을 인식해야 한다. “Category change. Fixes #1.” (필요 시 이전에 생성 한 이슈와 일치하도록 ID를 업데이트한다) 라고 머멘트를 입력하고 Ctrl + Enter를 눌러 로컬 release 브랜치를 커밋한다.

 

7. Synchronize Changes 버튼을 클릭하여 커밋을 서버 브랜치로 푸시한다.

 

8. GitHub Pull Requests 탭을 선택하고 Create Pull Request 버튼을 클릭한다.

 

9. 계정과 연결된 리모트을 선택한다. 원래 Microsoft 저장소가 아닌 자신의 저장소를 선택한다.

 

10. Enter를 눌러 기본 master 브랜치를 확인한다.

 

11. 풀 요청에 대한 타이틀 소스를 선택하도록 묻는다. commit으로 선택한다. 

 

12. 풀 요청이 생성되면 검토를 위해 체크 아웃된다.

 

 

과제 3: 풀 요청 관리하기

1. 현재 풀 요청이 이미 열려 있지만 GitHub 풀 요청 패널에서 사용 가능한 옵션을 사용하여 쉽게 다른 요청으로 이동할 수 있다. 풀 요청이 선택되면 풀 요청의 변경 사항을 탐색 할 수 있다. 이 프로세스를 사용하여 커밋에서 Category.cs 파일을 연다.

 

2. diff 뷰어는 master 및 release 브랜치의 코드 차이를 표시하는 데 사용된다.

 

3. 추가 된 줄 옆에 있는 Add comment 버튼을 클릭하고 설명을 입력 한 후 Start Review를 클릭한다.

 

4. Toggle Reaction 드롭 다운에서 승인을 표시하기 위해 썸업 옵션을 선택한다. (썸업 옵션이 리스트 안되어 생략한다.)

 

5. Add comment 버튼을 다시 클릭하고 다른 의견을 입력 한 후 Finish Review를 클릭하여 검토를 완료한다.

 

6. 풀 요청 탐색보기 외에도 창의 맨 아래에 있는 바로 가기를 사용하여 현재 풀 요청으로 돌아갈 수 있다. 

 

7. Merge Pull Request를 클릭한다.

 

8. 메시지가 표시되면 Create Merge Commit을 클릭하여 프로세스를 완료한다.

 

9. GitHub 브라우저 탭으로 돌아간다. 리포지토리의 Pull Requests 탭으로 이동한다. Closed 풀 요청 옵션을 선택하고 종료된 풀 요청을 클릭하여 연다.

 

10. 커밋 및 대화를 포함하여 이 병합 된 풀 요청에서 모든 풀 요청 세부 정보를 검토 할 수 있다. 커밋에서 식별된 작업 항목을 클릭하여 풀 요청이 병합 될 때 자동으로 닫혔음을 확인한다.

 

11. 예상대로 이슈가 이제 Closed로 표시된다.

 

 

과제 4: Git 리포지토리 및 풀 요청 정책 관리하기

프로젝트와 팀의 규모가 복잡 해짐에 따라 더 많은 프로세스를 자동화하여 품질을 보장 ​​할 수 있다.

1. 레포지토리의 Settings로 이동한다.

 

2. Branches를 선택한다.

 

3. 정책은 대상 브랜치와 일치하는 규칙에 따라 시행된다. Add rule을 클릭하여 새 규칙을 만든다.

 

4. Branch name pattern에 “master” 라고 설정한다.

 

5. Require pull request reviews before merging(병합 전 풀 요청 검토 필요) 옵션을 활성화한다. 이 옵션을 사용하면 병합 요청이 검토되었으며 보호되지 않은 브랜치로부터 들어오는 것을 보장할 수 있다. 오래된 풀 요청 승인에 대한 특별한 행동방식을 지정할 수 있으며 특정 코드 소유자로부터 리뷰가 필요하도록 할 수 있음을 주목한다. 

 

6. Require status checks to pass before merging(병합 전 통과를 위해 상태 체크 필요) 옵션을 활성화한다. 그러면 풀 요청을 생성하기 전에 지정된 상태 점검이 통과하도록 보장할 수 있다. 예를 들어, 병합을 수행하기 전에 소스 브랜치가 성공적으로 빌드되도록 요구할 수 있다.

 

7. 서명 된 커밋을 요구하고 관리자가 이러한 풀 요청 제한을 준수하도록 요구하는 추가 옵션이 있다. 규칙을 작성하려면 작성을 클릭한다.