• git의 pull request에 대해서 공부하고 정리한 글입니다.

Pull request

• pull request는 협력자에게 브랜치 병합을 요청하는 메세지를 보내는 것
• 최근에 푸시한 브랜치가 있는 경우 github의 code탭에서 compare & pull request 버튼이 보여지고, 해당 버튼을 누르면 아래처럼 pull request할 수 있는 화면이 뜬다.
• 베이스 브랜치(base branch) : 병합 결과물이 올라가는, 기준이 되는 브랜치
• 비교 브랜치(compare branch) : 기준 브랜치의 비교대상이 되는 브랜치
  내가 만들어서 base branch에 반영시키고 싶은 브랜치

• Pull request를 작성할 때, Title은 간결하게 작성하되 내용은 어떤 것을 수정했는지, 어떤 것을 리팩토링했는지, 어떤 것을 추가했는지 등 가능한 자세하게 설명하는 것이 좋다.
• 내용을 작성하는 부분에서 markdown 지원된다.

그리고 Pull Request를 작성할 때,

• Assignees : 이 pull request를 담당하는 동료. 보통 자기 자신

• Label : 이 pull request에 고나한 라벨을 달아준다. 예를 들어 [프론트엔드],[백엔드]

• Reviewers: 협력자를 지정할 수 있다.

• base : 병합된 커밋이 들어갈 브랜치를 선택한다.

• compare : 내가 만들어서 base 브랜치에 반영시키고 싶은 브랜치

• Able to merge : 충돌없이 병합될 수 있다는 뜻

• github의 Pull request탭에서 풀 리퀘스트를 확인하고 새롭게 추가된 코드를 검토할 수 있다.

• 코드의 라인마다 댓글을 달 수 있기 때문에 해당 코드가 왜 고쳐졌는지 또는 어떻게 개선할 수 있는지 풀 리퀘스트 내부에서 토론을 진행할 수 있다.

• 풀 리퀘스트에 대해서 수락(Accept), 수정 요청(Request), 병합(Merge pull request) 해준다.

• 만약 해당 풀 리퀘스트의 코드를 검토해보았을 때 문제가 없었다면 병합(Merge pull request) 해준다.

• 위 그림처럼 master 브랜치에 풀 리퀘스트를 하고 병합을 하면 새로운 병합 커밋이 생기고, master 브랜치가 그 커밋을 가르키게 된다.

• 하지만 소스트리를 쓸 때 즉시 반영이 되지 않는 경우가 있는데 이때 [fetch]기능을 사용해서 Git에서 새로운 이력을 업데이트 한다

• Pull은 실제 코드를 내려 받는데 비해 fetch는 그래프만 업데이트 한다

• [fetch] 후 브랜치의 병합이 잘 된 것을 확인한 이후에 [master] 로 브랜치를 옮긴다음에 [pull]을 해서 로컬 저장소의 [master]와 원격 저장소의 [master]를 동일하게 만들어준다

• Pull request 탭에서 어떠한 내용의 풀 리퀘스트 요청이 왔는지 확인할 수 있다

• Pull request - File changed 탭에서는 어떤 새로운 코드가 이 풀 리퀘스트에 담겨 있는지 확인할 수 있다

• 코드 리뷰를 끝낸 다음, Review changes 탭을 누르면 write 창이 열린다

• Comment : 그냥 댓글 달기

• Approve : 댓글 달고 바로 병합해도 될 것 같을 때

• Request changes : 수정 요청하고 싶을 때

• Approve하고 난 후, Review를 확인해보면 풀 리퀘스트 하단에 댓글처럼 보여진다

• 그 다음 Merge pull request 버튼을 눌러 풀 리퀘스트를 병합한다. 이는 원본 저장소 주인만 할 수 있다.

• 작업이 끝난 후 Code 탭의 commits에서 변경사항을 확인할 수 있다

• 풀 리퀘스트를 보내면 이 풀 리퀘스트도 하나의 커밋으로 추가된다

• 추가적으로, Pull Request는 업데이트 할 수도 있다.

confilict가 발생하는 경우

• develop 브랜치를 기준으로 A라는 작업자가 새로운 브랜치를 만든 다음, 특정 부분에 대해서 코드를 수정해서 Pull Reqeust를 했고 B라는 작업자도 새로운 브랜치를 만든 다음 같은 부분에 대해 수정을 하고 이후에 Pull Request를 했다고 가정해보자.
• 이러한 경우에는 두개의 PR이 존재하게 되는데, 만약 A라는 작업자가 요청한 Pull Request에 대해서 먼저 Merge pull request를 한 경우에는 B의 PR을 확인해 보면 conflict가 발상하는 것을 확인할 수 있다.
• 그 이유는 B의 작업은 A의 작업에 대해 Merge된 devlope의 상태가 아니라 그 이전의 develop 상태에서 작업을 했기 때문이다
• 이를 해결하는 방법으로는 웹 에디터에서 수정하는 방법이 있다.
• 이 방법은 github에서 직접 해당 코드를 수정하는 방법이다. 다만 이 방법은 코드를 수정한 다음에 로컬에서 제대로 작동하는지 바로 확인할 수 없기 때문에 권장되지 않는다.
• 또 다른 방법은 커맨드라인에서 해결하는 방법이다.
• 이 때 github에서는 단계를 설명해주는데 이는 다음과 같은 단계를 통해 해결할 수 있다.
• 우선 pull 명령어를 통해서 로컬의 develop을 origin 의 develop과 일치 시켜준다.

$ git pull origin develop

• 그 다음 A의 브랜치로 이동해서 develop과 merge 해보면 충돌이 일어나는 것을 확인할 수 있다.

$ git checkout "A branch"
$ git merge develop        #conflict 발생 

• 충돌이 발생하면 해결한 다음 merge를 하면 정상적으로 merge가 되는 것을 확인할 수 있다.
• 그리고 해결한 부분을 다시 원격 저장소에 push해서 PR을 업데이트해준다.

$ git push origin "B branch" 

• 다시 B의 PR을 보면 conflict가 해결된 것을 확인할 수 있고, 해당 PR을 merge해준다.

참고 : https://dkmqflx.github.io/development/2021/04/17/git-pr/