그리고 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는 업데이트 할 수도 있다.
$ git pull origin develop
$ git checkout "A branch"
$ git merge develop #conflict 발생
$ git push origin "B branch"
참고 : https://dkmqflx.github.io/development/2021/04/17/git-pr/