개발자가 각자의 개인 브랜치인 기능 브랜치(feature branch)에서 개발과 테스트가 마치면 메인 브랜치에 머지를 해야 하는 순간이 옵니다. 이때 pull request를 생성하게 됩니다. 대부분의 현장에서는 풀 리퀘스트(pull request, 줄여서 pr)를 만들어 코드 리뷰를 한 후 코드에 문제가 없다면 메인 브랜치로 머지를 하는 프로세스를 갖게 됩니다. 이번 포스트에서 github에서 pr를 만들고 merge를 하는 과정을 살펴보겠습니다.
pull request 만들기
1. new pull request 버튼으로 풀 리퀘스트 생성화면 열기
아래 화면은 git hub 리포지토리 화면 입니다. 현재 두개의 브랜치가 존재합니다.
오렌지 상자 영역의 텍스트를 클릭해서 들어가면 아래 화면이 표시됩니다.
Default branch(기본 브랜치)는 main입니다. 그리고 test라는 브랜치가 존재합니다. 이 화면에서 브랜치를 검색을 할 수도 있습니다.
또한 필터를 통해, 브랜치를 빠르게 살펴볼 수 있는 인터페이스도 존재합니다.
pull request를 만드는 첫번째 방법으로 overview의 브랜치의 각 줄에서 new pull requests를 이용하는 것입니다.
pull request 매우 중요하며 브랜치의 변경사항을 다른 브랜치로 가져오는 데 사용됩니다. 그것이 메인 브랜치일 수도 있지만 다른 브랜치일 수도 있습니다.
두 번째 방법은 Pull requests 탭을 이용하는 것입니다. pull requests 탭이 접근하기 쉬우므로 많이 사용됩니다.
Pull requests 탭을 클릭하면 아래와 같이 표시됩니다.
현재 공개된 pull request는 0개 라고 나오고 있습니다. 이 화면을 이용하면 open 돼있거나 close 된 pull request의 이력을 검색해 볼 수 있습니다. 이제 초록색 버튼인 New pull request에 주목해 주세요. 이 버튼을 누르면 pull request 생성 화면이 열립니다.
2. compare changes : 브랜치 간 코드 비교하기
이 인터페이스에서 각 브랜치를 비교한 후 pull request를 생성할 수 있습니다. 지금은 test브랜치에서 작업을 했고 test브랜치의 내용을 main 브랜치로 병합하는 pull request를 작성하려고 합니다.
compare를 클릭해서 test브랜치를 선택해 줍니다.
비교할 브랜치를 선택하면 커밋의 이력과 변경사항이 표시됩니다.
개발자는 이 화면을 통해 최종 확인을 할 수 있습니다. pull request는 보통 개인브랜치에서 기능을 개발한 개발자가 작성하게 됩니다. 따라서 자신이 개발한 기능과 커밋이 잘 포함되어 있는지 수정사항에는 문제가 없는지 확인할 수 있습니다. 실제 프로젝트에서도 이곳에서 확인하는 최종 체크가 많은 실수를 줄여주곤 합니다.
이 비교 화면에서 체크를 위해 많이 사용하는 것이 분할보기 입니다. Split를 클릭하면 아래와 같이 분할되어서 표시됩니다.
브랜치 별로 비교가 좌우로 표시되어 확인하기가 매우 편리합니다.
3. Open a pull request : 풀 리퀘스트 타이틀과 메시지남겨 생성하기
문제가 없다면 create pull request를 눌러 다음 단계로 넘어갑니다.
기본적으로 title에는 마지막 커밋의 이름이 자동으로 들어가게됩니다. 프로젝트의 룰에 따라서 title을 적고 코멘트에 어떠한 기능을 추가했는지 적어줍니다. github는 소셜 코딩 플랫폼입니다. 코멘트에서 앳 마크로 유저를 맨션하여 pull request가 생성되는걸 동료에게 알리고 코멘트를 남길 수 있습니다. 그리고 오른쪽에 보면 Reviewers나 Assigness로 유저를 추가할 수 있습니다. 이곳에 추가된 유저는 자동으로 알림이 가게 됩니다. 리뷰를 담당하는 개발자가 있다면 꼭 넣어주는 것이 리뷰어에게 편리합니다.
타이틀과 코멘트를 작성 후 Create pull request버튼을 누르면 풀 리퀘스트가 생성됩니다.
생성된 풀리퀘스트의 메시지를 보면 conflict(코드 간 충돌)이 없다고 나옵니다. 그리고 merge pull request 버튼이 활성화되어있습니다. 만약 conflict가 있다면 머지를 할 수 없고 conflict를 없애야 합니다. conflict를 해결하는 것 역시 머지 리퀘스트를 만든 개발자의 역할이니 풀 리퀘스트를 만들고 conflict가 있는지 반드시 확인해야 합니다.
여기까지가 풀 리퀘스트 생성입니다. 일반적으로 풀 리퀘스트가 생성된후 main으로 병합은 리뷰어가 해당 풀 리퀘스트를 검토한 후 머지하게 됩니다.
pull request 확인하고 merge 하기
리뷰어가 되었다고 가정하고 진행해 보겠습니다. 풀 리퀘스트 상황을 파악하기 위해 pull requests 탭으로 이동해 보겠습니다.
공개된 풀 리퀘스트가 하나 있는 걸 확인할 수 있습니다. 마우스 오버를 하면 아래 화면과 같이 간단한 정보를 확인할 수 있습니다.
또는 클릭해서 전체 풀리퀘스트를 확인하거나 머지를 할 수 있습니다. 풀 리퀘스트를 만들고 표시되는 화면이 그대로 표시됩니다.
commits 탭에서 어떠한 커밋이 포함되어있는지 확인이 가능합니다.
files changed탭에서는 변경사항을 확인할 수 있습니다.
리뷰어 혹은 동료가 이 변경사항을 보고 수정사항을 발견했다면 코멘트를 남길 수 있습니다.
지적하고 싶은 라인에 커서를 가져가면 나오는 + 버튼을 누르면 리뷰 프로세스 창을 띄울 수 있습니다.
이것이 풀 리퀘스트에서 코드에 대한 리뷰를 시작할 수 있는 방법입니다. 지금은 cancel를 하였습니다.
문제가 없다고 가정하고 merge를 진행하겠습니다.
풀 리퀘스트의 conversation탭에서 활성화되어있는 merge pull request를 눌러줍니다.
머지 메시지를 입력하고 confirm merge를 클릭합니다.
풀 리퀘스트가 성공적으로 머지 되었고 완료되었다고 메시지가 표시됩니다. 그리고 작업 브랜치였던 test를 삭제하는 버튼이 표시됍니다. 이제 메인 브랜치에서 모든 수정사항을 가지고 있으므로 test브랜치는 삭제해도 괜찮습니다.
delete branch를 눌러 삭제를 하겠습니다.
삭제를 하고 특정시점까지는 복구를 할 수 있으니 실수를 했다면 restore branch를 눌러 브랜치를 복구할 수 있습니다.
이것으로 pull request를 사용해서 브랜치를 merge하는 과정이 끝났습니다. pull requests 탭으로 들어가면 열려있는 풀 리퀘스트가 없는 것을 확인할 수 있습니다.
main에는 머지가 잘 되어 test브랜치에서 작업한 파일이 업데이트 된걸 확인할 수 있습니다.
여기까지 수고하셨습니다.
'프로그래밍 > Git' 카테고리의 다른 글
| Github 이슈(Issue) 만들어 관리하기 (0) | 2022.09.21 |
|---|---|
| github 리포지토리 포크(fork)하기 (1) | 2022.09.20 |
| Git 브랜치 전략과 github 워크 플로 (0) | 2022.09.13 |
| git branch 이해하기 (0) | 2022.09.10 |
| 깃 작업 흐름, github clone부터 push까지 따라하기 (0) | 2022.09.07 |
댓글