[Github] Pull Request

Pull Request

협업을 진행하다 보면 Pull Request, PR을 많이 이용하게 된다.

바로 Main에 Merge를 때리는 것이 아닌, 해당 브랜치를 Main에 합쳐도 되겠습니까?라고 함께 작업하는 사람들에게 동의 요청하는 것이다.

 

이 과정에서 리뷰를 나누고, 수정한 다음 모두의 승인(Approve)이 떨어지게 되면 우리는 Main에 Merge를 진행하게 되는 것이다.

(Main에서 해당 Branch를 Pull 하는 것이다.)

 

PR 진행

feature/sign을 진행하는 중

일단, 브랜치를 만들어서 작업을 진행해야한다.

모든 작업을 마쳤으면 커밋과 push를 진행한다.

다음과 같이 feature/sign -> origin: feature/sign이라는 브랜치로 push를 진행하게 된다.

main에 push 하는 것이 아닌, 작업 중인 브랜치를 remote환경으로 push하는 것이다.

Push후 작업중인 github Repository에 들어가게 되면 다음과 같이 해당 브랜치가 푸시되었다는 것을 보여주며 Compare & pull request를 진행할 수 있게 버튼을 보여주고 있다.

 

해당 버튼을 클릭하면 Pull Request를 진행할 수 있다.

Base와 Compare branch를 선택한다.

Compare은 현재 작업을 진행했던 branch, Base는 현재 작업했던 Compare branch를 합치고자 하는 branch라고 생각하면 된다.

현재 사진의 경우에는 feature/setting으로 base를 설정하였는데, 그 이유는 현재 작업중인 feature/sign이라는 브랜치가 feature/setting에서 파생되었기 때문이다.

 

이때 feature/setting이 아닌 main을 base로 설정했을 때 발생하는 상황에 대해서는 아래에 서술했다.

 

PR을 날리고, 모든 리뷰어들의 Approve를 받게 되었다면 이제 Merge를 진행하면 된다.

Merge Pull reuqest를 클릭하면 Main에 Merge가 진행된다.

여러 사람이 같은 파일을 작업할 경우 Conflict가 발생되어 Merge pull request가 disable 되는 상황이 발생하는 경우가 있는데, 그때는 안내 문구에 따라 수정하면 된다.

 

짫은 Conflict 해결 과정

Main으로 돌아가서 Main을 pull 하고, 다시 작업 중인 branch로 돌아와서 Main에 머지한다.

이때 Error가 발생하면서 수정하라고 뜨는데, conflict난 부분들을 확인하며 해결하면 된다.

이후 해당 branch를 push 한 후, PR에 들어가게 되면 disable 되었던 버튼이 다시 활성화된다.

 

추가적으로...

본인이 PR을 진행하며 한 가지 실수를 범했던 적이 있다.

다행스럽게도 온보딩 과제였다..

 

코드리뷰를 받고 나는 수정을 위해 PR을 close 하고 다시 개발 작업을 진행했는데, 이렇게 할 필요가 없다.

PR을 보내고, 리뷰를 받았으면 그냥 그대로 작업하고 push 하면 된다.

 

그럼 그 상황들이 실시간으로 PR에 반영됨으로, 수정 후 해당 리뷰에 코멘트를 달아서 수정했으니 검토를 부탁하면 된다.

위에 받았던 리뷰들을 수정한 커밋 기록

 

Source Branch를 무시하고 Main에 Merge 할 경우 발생하는 상황

 

Source Branch로 Base로 설정했을 경우에는 현재 브랜치에서 작업했던 커밋 기록만 보이게 된다.

Main으로 Base를 변경하며 커밋기록이 갑자기 늘어나게 된다.

그 이유는 Source Branch가 현재 Main에 Merge 되기 이전이므로 해당 Source Branch의 Commit기록이 Main에 없기 때문이다.

Source Branch가 Main에 Merge 된 상태에서 PR을 날렸다면 위처럼 커밋 기록이 정리되었을 것이다.

 

여기서 상기해야 할 점은

feature/sign의 base로 feature/setting을 설정하여 pr을 날렸지만, feature/setting이 main에 머지되는 순간 자동으로 feature/sign의 base는 main으로 변경되게 된다. feature/setting이 main에 병합되었기 때문에 자동으로 base가 변경되는 것이다.

 

그러므로 A branch의 PR을 올리고 머지될 때까지 기다린 다음 작업하는 것이 아니라, A branch를 source로 선택하여 B branch를 만들어 작업 후 A branch를 base로 PR을 날리면 된다.

참고 그림