Git (11)

깨진알·2023년 11월 30일

Git

목록 보기

11/13

Pull Request(PR)

Pull Request(PR)란?

Pull Request란, 다른 GitHub 사용자들에게 자신의 작업한 내용을 검토하고 머지해 달라고 요청하는 GitHub의 기능이다. 줄여서 PR이라고도 한다. PR을 활용하면 다른 개발자들에게 여유가 될 때, 코드를 검토해 달라고 피드백을 요청할 수 있다. 특정 시간에 맞추지 않아도 되고, 서로의 의견을 자유롭게 교환할 수 있으며, 더 효율적이고 품질 놓은 코드를 작성할 수 있다.

개인/팀 프로젝트에서 Pull Request를 사용한다면?

개인 프로젝트

개인 프로젝트에서도 PR을 활용하면 자신이 작성한 코드를 체계적으로 검토하고 문서화하는데 큰 도움이 된다. PR을 통해 코드의 변경 사항을 재검토하면서 오류를 발견하는 일은 흔하다. PR은 꼭 문서로 코드를 설명하지 않더라도 PR 자체가 의미를 가지는 코드의 단위이다. PR 자체가 코드를 문서화하는 것이다. 즉, 변경 점의 최소 단위인 커밋 단위의 기록이, feature 단위의 기록이 PR로 남기 때문에 일종의 기록, 혹은 자동화된 documentation의 기능을 수행하는 것이다.

PR을 만드는 것은 복구 가능한 시점을 만드는 것이기도 해서, 초심자분들에게 큰 도움을 줄 수 있다. PR을 사용하지 않고 머지하게 될 경우 복구가 어려운 반면, PR을 사용하면 대부분의 기록이 remote에 남게 되고, 실수한 경우 쉽게 되돌릴 수 있다.

모든 변경 사항을 PR로 관리하려면 처음에는 시간이 많이 소요될 수 있고, 특히 처음에는 익숙하지 않아 실수를 할 수도 있다. 그러나 PR을 통한 작업 관리에 익숙해진다면, 이로 인한 시간 소모는 점차 줄어들게 될 것이며, 향후에 팀 프로젝트를 진행할 때 큰 도움이 될 것이다.

팀 프로젝트에서 사용할 때

팀 프로젝트에서는 PR의 장점이 더 두드러진다. 모든 팀원이 코드 리뷰를 통해 다른 사람이 작성한 코드를 확인하면서 지식을 공유하고 코드의 품질을 개선할 수 있다.

PR은 프로젝트의 투명성을 높여주고, 작성자의 의도를 쉽게 파악할 수 있게 해준다. 코드의 작성 배경, 목적 그리고 주요 내용을 문서화해 두면, 다른 팀원들의 관련 작업이 쉬워지는 것이다. 혜택을 받는 대상에는 다른 팀원뿐만 아니라 작성자 본인도 포함된다. PR을 통해 문서화하는 일은 수고가 들지만, 그만한 가치가 있다. PR을 통해 프로젝트의 참여하는 개개인이 절약하는 시간을 모두 합쳐 본다면 상당히 큰 부분일 것이기 때문이다.

Pull Request 만들어보기

작업할 프로젝트 생성하기

GitHub에 들어가 repository를 하나 만들어라. GitHub의 우슥 상단의 + 버튼을 통해 새로운 repository를 생성할 수 있다.

프로젝트 clone 하기

$ git clone 주소

녹색 버튼을 누르면 clone할 수 있는 주소가 나온다.

새로운 브랜치 생성하기

$ git checkout -b [브랜치이름]

코드 변경하기

$ git add .
$ git commit -m "커밋 메시지"

변경 사항 푸시하기

$ git push origin

PR 생성하기
Create pull request를 클릭하면 PR이 생성된다.

Pull Request의 상태

Open

Open 상태의 PR은 아직 검토가 완료되지 않았거나, 추가적인 작업이 필요한 상태를 말한다. 이 상태에서는 더 많은 커밋을 추가하거나, 토론을 진행하며 수정을 요청할 수 있다. 해당 상태의 PR은 아래의 녹색 아이콘으로 표시된다.

Merged

Merged 상태의 PR은 소스 코드의 기본 브랜치로 병합된 상태를 말한다. Pull Request 화면에서 Merge 버튼을 누르게 되면 해당 상태로 변경되게 된다. 이는 해당 PR의 변경 사항이 승인되었고, 코드에 통합되었다는 것을 의미한다. PR이 병합된 후에는 Closed 상태로 표시되며, 이후 추가적인 변경이나 커밋을 추가할 수 없다.

Closed

Closed 상태의 PR은 거부되었거나, 더 이상 유효하지 않은 PR을 말한다. 이 PR은 병합되지 않았지만 더 이상 필요하지 않거나 다른 이유로 인해 종료된 상태이다. UI에서 Closed 버튼을 눌렀을 경우 PR은 Closed 상태가 된다. Closed 상태로 전환된 후에도 브랜치가 존재한다면 다시 Open 상태로 되돌릴 수 있다. Merged 상태도 Closed 상태로 취급하기 때문에 Closed 탭에는 Merged와 Closed 상태의 모든 PR을 확인할 수 있다.

PR Merge

merge pull request 녹색 버튼을 누르면 선택된 두 브랜치를 머지하게 된다. GitHub에서 두 개의 브랜치를 머지하는 방법은 총 3가지이다.

merge commit을 만들며 합치기
squash and merge 하기
rebase and merge 하기

Merge Commit을 만들며 합치기

Merge commit 방식은 두 브랜치의 변경 사항을 모두 유지하면서 병합한다. 이 방식을 사용하면, 각 브랜치의 변경 사항이 과거의 커밋으로 보존되고, 새로운 커밋이 추가되어 최종 병합이 완료된다.

장점
브랜치의 히스토리를 모두 유지하면서 변경 사항을 병합할 수 있다는 장점이 있다. 이를 통해 프로젝트의 진행 상황을 명확하게 이해하고 추적할 수 있다. 또한, 모든 커밋들의 커밋 아이디가 바뀌는 경우가 없기 때문에 다음에 다룰 squash와 rebase 방식에 비해 비교적 사용이 쉽다.
단점
커밋 히스토리가 복잡해진 수 있다. 다양한 브랜치에서 여러 작업이 이루어지면 커밋 로그가 빠르게 복잡해질 수 있다.

Squash and Merge

Squash and Merge는 브랜치에서의 모든 변경 사항을 하나의 커밋으로 압축하여 병합하는 방식이다. 이 방식은 각각의 커밋에서 발생한 모든 변경 사항을 병합 후에 하나의 새로운 커밋을 생성한다. 위 이미지에서 3rd-4th-5th 커밋이 하나의 커밋 feature/f1으로 합쳐져서 병합이 된 것을 확인할 수 있다.

장점
커밋 히스토리를 간단하게 유질할 수 있다는 장점이 있다. 각 커밋이 특정 Pull Request를 대변하게 되고, 그 의미를 이해하기 쉽게 된다. 즉, 커밋 하나하나가 완성된 기능을 의미하게 된다. PR에서 발생한 자잘한 문제들을 숨기고, 그 PR에서 가장 중요하고 필요했던 내용들만 압축하여 담게 된다.
단점
작업의 상세한 이력을 잃게 된다. 각 커밋에 대한 개별적인 맥락이나 작업작의 정보 등이 포함되지 않기 때문에 추후 문제 해결이 어려울 수 있다. 또한 기존의 작업 커밋의 아이디들이 하나로 합져치며 사라지고 새로운 커밋 아이디가 생성되기 때문에 여러명이서 해당 브랜치를 기반으로 작업을 수행하고 있었다면 병합이 이뤄지는 경우 복잡한 문제를 야기할 수 있다.

Squash 방식을 사용한다고 해서 모든 커밋 내역이 날아가는 것은 아니다. Git 자체가 아닌 GitHub에는 해당 커밋 기록들이 모두 남아있기 때문에 Pull Request를 검색해서 해당 작업의 커밋 히스토리를 확인할 수 있다.

Rebase and Merge

Rebase and Merge는 현재 브랜치를 target 브랜치에 재위치(rebase)시킨 후 병합하는 방식이다. 이는 target 브랜치의 커밋 위로 현재 브랜치의 모든 커밋을 옮겨 놓는 것과 같다. 이렇게 되면 커밋 히스토리는 선형적으로 유지된다.

장점
깨끗하고 선형적ㅇ니 커밋 히스토리를 만들어 준다는 장점이 있다. 이로 인해 히스토리 파악 및 코등의 변화 이해가 더욱 쉬워진다.
단점
관련된 커밋 ID들이 모두 바뀌게 되어 혼란을 초래할 수 있다. 이는 특히 브랜치가 크게 분기된 경우에는 복잡하고 어려울 수 있다. 여러 개발자가 동시에 작업을 수행한 경우에는 rebase 방식이 복잡한 충돌을 일으킬 수 있다. 추가로 PR별로 다른 기능으로 나뉘어 있던 작업 이력이 하나의 선형적인 히스토리로 합쳐지는 단점이 있다. 즉, 특정 기능이 어디서부터 어디까지의 커밋으로 구현되었는지 알기 어려워진다.

Fork의 개념

Fork는 Git의 기능이 아니라 Git을 호스팅 하는 서비스인 GityHub나 GitLab과 같은 서비스에서 제공하는 기능이다. Fork는 이미 존재하는 원격 Git repository를 사용자의 계정으로 복사하는 기능이다. 기존 repository에서의 모든 변경 사항을 담고 있는, 새로운 repository를 만들어 주는 기능이다. Fork된 repository는 기존 repository와 완전히 분리되어 있으므로 사용자는 자신의 repository에서 자유롭게 변경 사항을 반영할 수 있다. 작업이 끝난 후에는 Pull Request 기능으로 원본 repository에 기여할 수 있다.

왜 굳이 Fork로 PR을 만들까?

Fork를 사용한 방식은 Fork된 저장소에서 작업을 진행하고, 원본 저장소의 소유자에게 PR을 제안하는 방식이다. 오픈소스 프로젝트는 Fork를 사용해 PR을 생성하는 대표적인 예이다. 오픈소스는 다양한 규모의 팀, 커뮤니티 및 개인들이 참여하는 매우 큰 규모의 프로젝트이다. 이러한 규모의 프로젝트에서는 다양한 개인, 팀이 참여하는 만큼, 코드를 수정할 수 있는 권한 관리도 필요하다. 또한 단일 브랜치만으로는 작업이 충분하지 않을 때, 다수의 개발자가 각자의 저장소에서 독립적으로 작업하고 변경 사항을 제안할 수 있는 Fork를 기반한 PR을 많이 사용한다. 또한, 개발자는 자신의 저장소에서 브랜치를 생성하고 작업하기 때문에 심리적인 부담도 적다.