- 다른 팀원이 PR을 올렸다면, 여러분에게는 코드를 리뷰하고 승인할 의무가 생긴다.
- GitHub에 접속해서 "Pull requests" 탭으로 이동한다.
- "Open pull requests" 중 자신이 올리지 않은 것 하나를 선택한다.
- 올라온 코멘트가 있는지, 머지가 자연스럽게 가능한지 확인한다.
- 초록색으로 "This branch has no conflicts with the base branch"가 표시되면 큰 문제 없이 머지가 가능한 것이다.
- 회색으로 "This branch has conflicts that must be resolved"가 표시되면 "Resolve conflicts" 버튼을 눌러보자. 머지 컨플릭트를 해결해야 하기 때문이다.
- 이번 실습에서는, 가장 먼저 PR을 날린 사람의 것은 자연스럽게 머지가 되겠지만 그 뒤에 PR을 날린 사람들은 모두 머지 컨플릭트가 나도록 의도하였다.
- "Files changed" 탭으로 이동한다.
- 변경 사항들을 쭉 보면서 각 파일의 어떤 부분이 어떻게 바뀌었는지 확인한다.
- 이 변경 사항들이
main 브랜치에 합쳐졌을 때 문제가 발생할 여지가 있는지 확인한다.
- 참고: 사용법에 머지 컨플릭트 해결법 문서가 있다.
- 위 링크의 문서는
git pull을 하다가 로컬 환경에서 머지 컨플릭트를 해결해야 하는 경우를 다룬다.
- 이번 실습에서는 GitHub 내에서 해결하는 방법을 다뤄보겠다. 공식 문서는 여기를 참조하라.
- 머지 컨플릭트가 난 상황에서는 해당 파일의 해당 위치에
<<<<<<<, =======, >>>>>>> 표시가 생겨 있다.
<<<<<<<와 ======= 사이에는 PR을 날린 사람의 이름이 적혀 있을 것이고, =======와 >>>>>>> 사이에는 이미 main 브랜치에 반영된 다른 사람들의 이름이 적혀 있을 것이다.- 이 상황에서는 둘 다 남아있도록 합쳐야 하므로, 그냥
<<<<<<<, =======, >>>>>>> 표시가 있는 줄들만 지워서 자연스럽게 합쳐주자.
- 파일 편집이 끝나면 "Mark as resolved" 버튼을 눌러 머지 컨플릭트를 해결했다고 표시하자.
- 모든 머지 컨플릭트를 해결했으면 "Commit merge"를 눌러 머지 컨플릭트 해결을 반영한 새 커밋을 만들 수 있다.
- 새 커밋을 어디에 올릴지 묻는 창이 뜬다.
- 현재 브랜치(PR을 날린 사람의 개인 브랜치)에 바로 커밋하는 것(첫 번째 선택지)을 선택하자.
- 참고: 만약 현재 브랜치가
main이라면 바로 커밋하지 말고 새 브랜치를 만들어서 PR을 새로 날리는 것(두 번째 선택지)을 권장한다.
- 풀 리퀘스트의 "Files changed" 탭으로 이동한다.
- 여기서는 딱히 리뷰할 내용은 없기 때문에, 오른쪽 상단의 초록색 "Review changes" 버튼을 누른다.
- 참고: 코드의 각 줄마다(여러 줄도 드래그로 가능) 커서를 올리면 파란색 "+" 버튼이 나타난다. 이 "+"를 누르면 해당 코드에 대한 리뷰를 작성할 수 있다.
- 여기서 리뷰를 작성하고 "Start a review"를 누르더라도 아래 과정("Submit review")을 거치기 전까지는 다른 사람들에게 리뷰가 보이지 않는다.
- 해당 PR에 대한 전반적인 코멘트를 작성하고, "Approve"에 체크한 후에, 초록색 "Submit review"를 누른다.
- 머지 컨플릭트를 위에서 해결한 상황이기 때문에 PR을 승인해도 된다.
- 코멘트에는 가급적이면 긍정적인 말을 적어줍시다!
- 다시 "Conversation" 탭으로 돌아온다.
- 초록색 "Merge pull request" 버튼을 누른다.
- 머지가 완료되면 "Delete branch" 버튼을 눌러서 해당 개인 브랜치를 제거할 수도 있다.
- 단, 브랜치 삭제는 브랜치 주인의 허락을 받고 하는 것이 좋다.
- 브랜치를 삭제하면 레포지토리를 깔끔하게 유지하는 데 도움이 된다.