Pull Request 생성 창(1)

main <- pull_request_window(노란색 네모)

base : main

어느 브랜치를 Base로 하여 Pull Request를 진행할지 결정하는 창으로 원하는 브랜치를 선택할 수 있다.

베이스란 말이 어려울 수 있는데 "어떤 브랜치에 내가 작업할 내용을 추가할 것인가"에 대한 질문에서 "어떤 브랜치"에 해당하는 브랜치를 지정하면 된다.

compare : pull_request_window

내가 작업한 작업물이 존재하는 브랜치, 혹은 Base 브랜치에 병합시킬 작업물을 가진 브랜치를 의미한다.

base와 compare를 동시에 생각해 본다면 compare에 지정된 브랜치의 작업물을 main 브랜치에 Push 하는 작업이 수행되는 것이다.

Able to merge.

충돌(Conflict) 없이 병합(Merge)이 가능하다는 의미를 가진다.

만약 병합 시 Conflict가 예측된다면 아래와 같은 창이 발생한다.

이러한 충돌은 Github에서 Pull Request를 생성한 후에도 해결할 수 있지만 필자는 로컬 저장소에서 미리 이러한 충돌을 해결한 뒤 Pull Request를 생성하는 것을 추천한다.
(충돌이 예상되더라도 Github에서는 Create pull request 버튼이 활성화된다)

Commits on Sep 25, 2023(주황 네모)

PR 결과를 통해 원격 저장소 main 브랜치(base 브랜치)의 HEAD에 어떠한 커밋들이 추가되는지를 알려주는 공간이다.

위 사진에선 Pull Request를 수행할 경우 원격 저장소의 main 브랜치에 Pull Request 창 확인을 위한 커밋이라는 메시지를 가진 커밋이 추가됨을 알 수 있다.

그 아래 창에서는 Pull Request가 진행될 경우 어떤 부분이 달라지는지를 볼 수 있는데 이는 많이 활용되지 않으므로 넘어가겠다.

Create pull request

Pull Request를 생성하는 창이다.
Conflict 발생 유무에 상관없이 활성화되며 누를 경우 Pull Request가 생성된다.

---

Pull Request 생성 창(2)

위 단계(1번 창)에서 Create pull request창을 선택했다면 2번 창이 나올 것이다.

이 창에선 Pull Request에 대한 Comment와 제목을 생성할 수 있다.

PR의 제목으론 해당 PR이 어떤 이유로 생성되었는지(ex. A 기능 개발, 버그 핫픽스 등) 입력하는 곳이 좋으며 Comment로는 그를 위해 어떤 작업을 수행했는지(ex. NPE가 발생하므로 null 체크 로직을 추가함) 간단히 입력해 주면 좋다.

Conventional commit

Commit이나 PR에 대한 Comment를 달 때 Convention이 존재한다.
물론 이 Convention은 필수 사항은 아니고 회사마다 혹은 프로젝트 그룹마다 다를 순 있지만 일단 대표적인 Convention에 대해서는 알아보자.

• feat : 새로운 기능을 구현했거나 기존 서비스를 변경했을 때

• fix : 버그 수정

• perf : 성능 개선

• refactor : 단순 코드 리팩토링

• test : 테스트 추가 혹은 테스트 강화

• build : 빌드 시스템이나 npm 배포에 대한 수정

• ci : CI(Jenkins, Travis 등) 설정 수정

• chore : 실제 코드엔 영향이 없는 단순 수정

  • README.md 수정

위 단어를 앞에 붙인 뒤 : 뒤에 PR에 대한 제목을 달아주면 된다.
예를 들어 A 기능을 개발했다면 Commit Message는 feat : A 기능 개발로 지어질 것이다.

---

PR 병합 창

오른쪽 PR 설정 창(주황색 네모)

Reviewrs

Project의 작업물을 리뷰해 줄 사람들을 지정해 주면 된다.

Test Code 및 Test Case를 생성하여 QA를 진행할 사람들을 추가시켜도 되고, Code Review를 수행해 줄 사람들을 추가시켜도 된다.

Assignees

해당 PR 목적을 달성하기 위해 작업할 실무자들을 등록해 주면 된다.
Assignees 존재 이유를 이해하기 위해선 PR의 특이점에 대해 알아야 한다.

Github는 PR이 생성된 이후 compare로 지정한 브랜치에 추가 커밋이 Push 되었다면 Push 된 추가 커밋 또한 (Merge pull request를 수행하지 않았다면) PR에 추가된다는 특징을 가진다.
따라서 PR을 먼저 생성하고 해당 PR을 위한 작업물을 저장할 브랜치와 실무자들을 등록해놓는다면 업무자들이 브랜치에 커밋을 수행할 때마다 PR에도 자동으로 커밋이 추가될 것이므로 실시간으로 업무 상황을 파악할 수 있게 된다.

그 외의 Labels, Projects, Milestone, Development, Notification은 큰 활용도가 없다고 생각하여 설명을 생략하겠다.

Merge pull request 버튼

병합 커밋 생성(Create a merge commit)

가장 기본적인 방법으로써 두 브랜치 상태를 비교하여 새로운 커밋을 만들면서 코드를 병합하는 방법이다.
Merge Commit(병합 커밋)과 동일한 과정이며 단지 이 과정이 원격 저장소에서 일어났을 뿐이다.

스쿼시 해서 병합(Squash and merge)

합병할 브랜치의 변경사항들을 하나로 묶어버린 후 병합하는 방법이다.

Rebase와 유사하다.
단지 Rebase의 경우 브랜치에 "커밋2, 커밋3"이 추가되었을 때 2개의 커밋을 다른 브랜치에 이어붙이지만 Squash and merge에서는 커밋2와 커밋3의 변경사항을 커밋4라는 새로운 커밋으로 묶어버림으로써 커밋4만 다른 브랜치에 이어붙인다.

Base 브랜치의 히스토리가 한 줄로 깔끔하게 남는 PR 방법이다.

리베이스 후 병합(Rebase and merge)

이전에 언급했던 Rebase와 동일하며 단지 Rebase가 원격 저장소에서 진행될 뿐이다.
Merge Commit(병합 커밋)처럼 병합 결과를 저장할 커밋을 새로 생성하지 않으므로 Log는 깔끔히 남으면서도 병합시킨 브랜치의 작업 내용(커밋 이력) 또한 유지시킬 수 있다는 특징을 가진다.

Rebase VS Squash

PR 중 Conflict 발생 상황

Commits 섹션

해당 PR을 통해 Base 브랜치에 추가될 커밋들을 확인할 수 있는 섹션이다.

File Changed 섹션

PR을 수행함으로써 Base 브랜치의 HEAD와 비교했을 때 몇 개의 파일이 변경되었는지, 최종적으로 어떻게 변경되는지 확인할 수 있는 창이다.

이 섹션에선 몇 가지 재미있는 동작을 수행할 수 있는데 코드의 문제점을 알려주거나 코드 리뷰를 도와주는 기능들이다.

Review comment

변경된 파일의 라인에 마우스를 갔다 대보면 파란색 + 버튼이 활성화되며 이를 클릭하면 위 이미지와 같이 Comment 창이 발생한다.

여기에서 해당 코드에 대한 커멘트를 달 수 있다.

Review changes

오른쪽 위를 보면 Reveiw Changes 버튼이 존재하며 이를 클릭하면 위와 같은 창이 나온다.
이 버튼은 "Review Comment"를 통해 피드백한 내용(커멘트)들을 어떻게 PR에 반영할지 선택할 수 있게 해준다.

• Comment : Merge를 수행하지 않고 Comment만 추가한 채로 PR 상태를 변경

  • Review changes의 Comment는 Review comment 전체를 설명하는 Head Comment라고 보면 된다.

    • (ex) Review Comment : NPE에 대한 검증 로직 추가 / Review Changes Comment : 1차 코드 리뷰

• Approve : Comment는 남기되 PR을 수용함으로써 브랜치 2개를 Merge 시킴

• Request changes : Feedback(Comment)를 모두 확인해야지 Merge를 수행할 수 있음

  • 많이 활용되지 않는 것 같은 옵션