팀별 / 개인별 과제를 시작한지 3일차이다.

많은 분들이 부트캠프 출신인것 같은데, 그곳에서 많은 경험을 쌓으신것 같다. 나는 부트캠프 출신도 아니고 제대로 된 개발도 배워보지 못해서 지금 매우 해매고 있다.

일단 깃허브를 사용해서 푸쉬하고 PR 날리는 것 부터 나에게는 물음표였다.

회사에서는 깃허브를 안 쓰고 자체 깃을 만들어 쓰는 데다가 pull requests 를 이용하지도 않는다. 보통 그냥 마스터에 푸쉬해서 작업을 하는데 알고보니 이런 행동이 굉장히 위험한 것임을 알았다.

요즘 많은 회사들이 깃허브에 PR(pull requests)를 이용해서 코드 충돌로 인한 사고를 막는것 같다.

1. Fork

일단 나의 첫번째 난관이였던 다른사람이 만든 코드를 내 저장소로 어떻게 가져오는가?
에 대한 해결 방법이다.

포크를 누르면

이 창으로 전환된다.

create fork 버튼을 누르면,

이렇게 내 저장소에 새로운 레파지토리가 생성된다.

그러면 이 깃 주소를 카피해서 에디터에서 clone 하면 된다.

2. Pull Requests(PR)

일명 풀리케 라고 하는것이 이 pull requests 이다.

협업을 할때 꼭 필요한 작업인데, 내가 branch를 따서 작업한 내용을 마스터에 merge 하기전에
reviewer 에게 확인을 받는 작업이라고 할 수 있다.

보통 reviewer 는 상급자 또는 팀장 님이 맡아서 하시는데 꼭 그런건만은 아니고 팀원들 모두가 리뷰어가 될 수 있다.

마스터에다가 바로 작업하면 pull requests 가 뜨지 않는다.
브랜치에서 작업해야만이 pull requests를 날릴 수 있다.

원격브랜치로 내가 만든 코드를 푸쉬하면

git push origin 만든브랜치이름


이렇게 노란색 박스가 뜬다.

Compare & pull request 버튼 눌러서 들어가보면

이런 창이 뜨고 저 박스에 내가 수정한 코드에 대한 설명을 쓴다.

그리고 create pull request 를 누르면

요런 화면이 뜬다.

빨간 부분 클릭(내 브랜치이름이다)


열어보면 어디가 수정되었는지 확인가능.

충돌이 나서

요기가 활성화가 안 되어있다면 PR 날린사람이 에디터로 본인 branch 에서 마스터를 당긴후에 충돌을 해결하고 다시 원격브랜치에 푸시한다. 그다음 리뷰어에게 확인 받고 해결이 되었다면 충돌 메세지가 안뜨고 머지 가능하다는 메세지가 뜬다. 그러면 리뷰어가 머지를 진행한다.

내가 작업했던

PR 을 받은 관리자(리뷰어)는 코드 변경 내역을 확인하고 merge 할지 여부를 결정한다.

PR이 끝난 작업은

이곳에 기록이 된다.

profile
프론트앤드 개발자로 일하고 있는 kind J 입니다.

0개의 댓글