개요
Pull Reqeust는 자신이 작업한 내용을 다른 사람들에게 공유 후 코드 리뷰를 진행 후 브랜치에 병합하는 과정을 의미합니다. Pull Request는 개발 팀원이 많을 때, 프로젝트가 클 때 많이 사용하게 됩니다. 개발 회사에서는 자주 사용하는 기능이며, 코드 리뷰의 기반이 되기 때문에 Pull Request(PR)를 많이 사용하게 됩니다.
PR를 사용하는 이유
- 자연스러운 코드 리뷰를 할 수 있다.
- 오픈 소스 프로젝트에 기여가 가능하다.
- PR를 하면 Merge 전에 코드를 확인할 수 있고, 각 코드별로 코멘트를 달 수 있다.
- Merge를 신중하게 할 수 있으며, Merge 할 때 팀원들이 확인하는 규칙을 정할 수 있다.
- 결국 코드 안정성을 높일 수 있다.
PR 생성 및 Merge 방법
PR를 하기 전 프로젝트를 가져와야 하며, 새로운 Branch를 만들고, commit → push 과정을 거쳐야 합니다.
PR은 자신이 한 작업을 기존 Main Branch에 병합하는 방법이기 때문에 PR를 만들기 전에 자신이 작업한 것이 있어야 합니다.
자신이 만든 Branch에서 Github에 Push 까지 완료한다면 PR를 만들 수 있습니다.
위에 보면 feature/swagger branch가 push 됐다고 알림이 나와 있습니다. 그리고 오른쪽에 Compare & pull request 버튼이 있습니다. 최근에 push 된 branch를 비교하고 PR를 만들 것인지 물어보는 것으로 저 버튼을 눌러도 PR를 생성할 수 있습니다.
Compare & pull request 아래에 New pull request 버튼이 있습니다. 해당 버튼을 누르면 원하는 branch를 선택해서 PR를 만들 수 있습니다.
간단한 코드 수정을 기존 main branch로 merge하기 위해 PR를 생성합니다. 위 선택 박스를 보면 현재 존재하는 branch가 나오며 base branch와 compare branch를 선택할 수 있습니다. 원하는 base에 적용할 branch를 선택하여 PR를 만들어 줍니다.
위 사진은 Compare & pull request 버튼을 누르면 나오는 화면입니다. 제목과 내용을 이해하기 쉽게 작성하고 Create pull request 버튼을 눌러서 PR를 생성합니다.
이 화면에서도 compare를 변경할 수 있으며 base도 변경할 수 있습니다.
현재는 Reviewer 설정이 되지 않아 바로 Merge pull request를 할 수 있습니다. Reviewer가 있다면 Reviewer들이 코드를 확인하고 체크 버튼을 누르게 됩니다. 코드를 확인하여 안정성을 올리는 장치로 사용됩니다. 덕분에 코드 리뷰가 자연스럽게 이뤄질 수 있습니다. 또한, 잘못된 코드 배포로 인한 장애 상황을 줄일 수 있습니다.
아래 코멘트를 달 수 있는 기능도 있으니 해당 PR에 대한 의견을 자유롭게 나눌 수 있습니다. 빼먹은 중요 사항이나 이슈를 적는 용도로도 사용 가능합니다.
Merge pull reqeust를 하기 전에 아래 화살표가 보여서 누르면 3개의 메뉴가 나옵니다. 각자 다른 기능을 제공하며 각각의 기능은 아래와 같습니다.
Create a merge commit
우리가 흔히 알고 있는 일반 Merge입니다. 그대로 합쳐지고 git history에도 합쳐지는 그래프가 나옵니다.
이 방식의 장점은 Git history에서 자세한 과정을 확인할 수 있다는 점입니다.
단점은 Branch가 매우 많아질 수 있으며, Branch가 많다 보니 복잡한 history 그래프가 그려질 수 있다는 점입니다. 프로젝트 규모가 크고, 많은 사람들이 Branch를 만들어서 사용할 때는 사용하지 않는 것이 좋습니다.
소규모로 진행하는 기능 개발에 대해서는 많이 사용되니 일반적으로 많이 사용하게 됩니다. 큰 회사라 할지라도 하나의 프로젝트에 무수히 많은 사람들이 붙어서 기능 개발을 한꺼번에 하는 일은 많지 않기 때문에 위 장단점만 잘 알아두고 사용하시면 됩니다.
Rebase and merge
Rebase merge는 말그대로 합치고자 했던 branch의 commit들을 그대로 base branch로 옮겨준다. 일반 merge처럼 합치는 것이 아니라 commit 내역을 그대로 떠서 옮겨준다. 그래서 git history 상에는 그래프가 합쳐지진 않고 base만 위로 올라가면서 갱신된다.
위 그림처럼 기존 origin/main은 한 칸 올라가면서 feature/swagger가 가지고 있던 commit 내용이 이동한 것을 볼 수 있다. rebase 한 swagger branch는 그대로 끊기게 된다.
이 방식의 가장 큰 장점은 git history를 깔끔하게 볼 수 있다. 합치고 분리되는 모든 과정이 그려지면 그래프가 복잡해지는데 rebase를 진행하면 합쳐지는 그래프가 생성되지 않아서 보기 좋다.
단점은 여러 commit을 rebase merge를 했는데 충돌이 나면 merge 하려던 모든 commit에서 충돌이 발생한다. 이것을 해결하는 것이 쉽지 않다. 또한 의미 없는 commit들이 history에 계속 남게 된다.
Squash and merge
Squash merge는 Rebase merge에 옵션이 붙은 Merge라고 이해하면 됩니다.
Squash merge는 Rebase를 진행하고 Merge할 Commit 들을 하나의 Commit에 합친다. Squash merge를 하면 많은 Commit들을 하나의 Commit에 합쳐 깔끔한 Git history 그래프가 나오도록 한다. 자주 Commit을 했고, HIstory를 정리하기 위해서는 이 옵션을 사용하면 된다.
자잘한 commit들이 많을 때, 깔끔하게 history를 정리할 때 Squash and merge를 추천한다. 하나의 commit에 의미 없는 commit들도 합쳐주기 때문에 관리하기 쉽다.
PR은 여러 장점을 가지고 있는 Process이기 때문에 위와 같은 방식으로 Merge를 진행하며, 라이브 제품을 배포할 때는 위의 과정을 필수로 거칩니다.
물론 개발망이나 테스트용 branch에 Merge할 때는 이 과정을 생략하고 로컬 Merge를 진행하기도 합니다. 일반 Merge와 관련된 글은 맨 아래에 링크를 남겨두었으니 참고하세요!
같이 보면 좋은 글
카디널리티(cardinality)와 선택도(selectivity), 인덱스(index)의 관계