제출해야 하는 파일만 따로 올려 git 링크로 과제를 제출하던 중,
어느날 매니저님께서 말씀하시기를..
"PR 링크 제출 부탁드립니다."
.
.
.
.
(⌒‿⌒) ?
PR이요? 내가 아는 PR은 자기PR 뿐..
.
.
장난입니다 :)
현재 현업에서 쓰고 있는건 Azure DevOps Server로, 한 파일을 체크인 하는동안 다른 사람은 수정을 못하는 방식으로 쓰고 있다. (좀 구시대적입죠..)
git의 Pull Request 기능은 사실 대학생 때 이후로는 쓸 일이 없어서 아주 오랜만에 들어보는 단어였다.
이참에 실습이나 해보며 다시한번 익히고 정리하는 시간을 가져보도록 하겠다.
Fork
다른 사람의 Repository들 중 기여하고 싶은 맘에 드는 프로젝트를 포크로 푹 찔러 그대로 퍼오는 것이다.
즉, 다른 사람의 깃허브에 있는 Repository를 나의 깃허브(내 원격 저장소)로 복사해오는 것이다.
그리고 그 fork해온 나의 Repository를 내 로컬에서 Clone 하여 수정작업을 진행하면 된다.
Fork: 상대방 원격 저장소 👉🏼 내 원격 저장소
Clone: 원격 저장소 👉🏼 내 로컬
Pull Request (PR)
로컬에서 수정 작업이 끝나고, 본래 소유자의 Repository에도 내가 수정한 멋진 코드가 합쳐지면 좋을 것 같을 때!
그때 바로 이거 합쳐줘! 하는 Pull Request 요청을 보내는 것이다.
원래 주인이었던 사람은 PR 요청을 보고 마음에 들면 검토 후 수락하여 병합하고, 아니면 거절하게 된다.
이와 같은 방식으로 "오픈소스에 기여"할 수 있다.
즉, 내 branch 를 검토 후 병합을 요청하는 것이 Pull Request 이다.
아마 매니저님은 PR 요청이 오면 본래 소스와 한눈에 비교할 수 있으니 과제에서 수정된 코드를 좀 더 쉽고 한눈에 알아보기 위해 PR 링크를 제출해달라고 하지 않았나 싶다.
branch: 동일한 소스 코드에서 가져온 독립적인 개발 라인(새 기능이나 버그 수정 작업을 할 때 브랜치를 사용하여 다른 팀 구성원의 작업과 분리)
순서 정리
Pull Request 를 수행하는 순서는 다음과 같다.
forkclone,remote설정branch생성- 수정 작업 후
add,commit,push(포크 떠온 내 원격 저장소로) Pull Request생성- 코드 리뷰 후
Merge Pull Reqest Merge이후branch삭제 및 동기화
실습
다음 과제 PR 링크 생성을 위해 겸사겸사 실습을 진행하도록 하겠다.
1. Fork
먼저, fork를 진행할 대상 Repository에 들어가 우측 Fork 버튼을 클릭하여 Create fork를 진행한다.
그리고 내 깃허브로 돌아오면 다음과 같이 새 Repository가 생성된 것을 확인할 수 있다.
그리고 clone 작업을 위해 새로 만들어진 Repository의 clone 주소를 복사하도록 하자.
2. Clone, Remote
먼저, 위에서 복사한 내 Repository의 주소를 로컬에서 Clone 한다.
Clone 을 진행하면 자동으로 로컬 저장소 생성이 되므로 git init 과 내 원격저장소의 remote add 과정이 필요 없다.
# clone 전 작업을 진행할 폴더 내로 이동!
$ git clone <내 레포지터리 URL>
나는 여기서 왜 로컬 저장소가 생성이 안되지? 싶어서 구글링을 엄청 했다. (clone 의 동작 방식이 바꼈다거나 할까봐..)
근데!!!! 방금 clone 해온 폴더 내로 한번 더 이동해야 하는 것이었습니다!!!!!!
여기서 정말 많은 시간을 버렸는데, 다신 안까먹을 것 같다.
$ cd ./front_1st이동 후, 터미널에 브랜치가 표시되는 것을 확인할 수 있다.
그리고 이렇게 자동으로 기본 branch와 remote가 잘 연결된 걸 확인할 수 있다.
$ git branch
$ git remote -v
그 다음으로는 내가 포크떠온 상대방의 원본 Repository를 remote로 연결한다.
원본이 업데이트 되었을 경우 최신화를 위해 추가해야 한다!
$ git remote add real_origin <상대방의 원본 레포지터리 URL>연결된 remote 목록은 다음 명령어로 확인 가능하다.
# 연결된 remote 목록
$ git remote -v
3. Create branch
이제, 작업 분기를 위해 새 branch를 생성한다.
branch를 생성하여 작업하면 수정된 코드가 사이드 이펙트를 발생한다고 해도 main에 코드가 남아있기 때문에 다시 이전 코드로 되돌리기가 쉽다.
# 브랜치 생성후 이동
$ git checkout -b <branch 이름>
# 브랜치 리스트
$ git branch
4. add/commit/push
그 다음, 코드 수정을 하고 add/commit/push 작업을 한다.
이때 push는 당연하지만 포크를 떠온 "나의 원격 저장소"의 "새로 만든 브랜치" 에 push 한다.
$ git add .
$ git commit -m "2주차 과제 A 제출"
$ git push origin develop
그럼 다시 원격 저장소로 이동하여 확인해보자.
branch를 내가 새로 생성한 develop으로 변경 후,
commit 된 내용을 확인하면
다음과 같이 develop branch에만 추가된 것을 볼 수 있다.
진짜다. main branch로 돌아가면 commit 기록이 없는 것을 볼 수 있다.
5. Pull request
다시 나의 원격 저장소 메인으로 돌아가면,
다음과 같이 develop branch에 push 내역이 보이며 Compare&pull request 버튼이 활성화 되어있다.
버튼 클릭 후, 제목과 설명을 수정 후 Create pull requeset 버튼을 클릭한다.
근데 여기서 좀 스크롤 내리면, 원본 파일과의 차이점을 한눈에 볼 수 있다.
이제 원본 원격 저장소로 가서 pull request 탭을 확인하면 내 요청이 추가된 것을 볼 수 있다.
나는 우선 요청을 올렸다가 취소해서, closed 상태에서 확인 가능했다.
매니저님이 제출하라던 PR링크는 바로 이 링크를 말하는 것!!
6. Merge & delete branch
나는 5번까지만 하면 과제 제출에 성공이지만, 협업을 하는 상황에서는 그 이후 작업도 중요하다.
원작자가 승인을 해서 원본 저장소에 Merge가 되면, 내 로컬 코드와 원본 저장소의 코드를 동기화 후 작업이 끝난 로컬의 branch는 삭제해야한다.
# 코드 동기화
$ git pull real-origin # 원본 remote 와 동기화
# branch 삭제
$ git branch -d develop마치며..
근데 어쨌든 Pull Request도 관리자에게 내껄 봐줘! 내 소스 어때? 하는 의미인 것 같으니..
어떻게 보면 자기PR일 수도 있겠다는 실없는 생각이 들었다.
그리고 한편으로는 다른 개발자들은 당연히 한번에 알아듣는 말을 나는 한번 검색해보고 깨닫는 것을 보고 좀 더 분발해야겠다는 생각도 들었다.
근데 또 이번에 이렇게 알았으니 얼마나 다행인가!
그래도 현업의 업무가 좀 폐쇄적인 구조의 개발이다보니, 일반적인 범주에 들어가기 위해 남보다 더 노력해야겠다.
참고
[GIT] ⚡️ 깃헙 Pull Request 보내는 방법 - 알기 쉽게 정리
git 초보를 위한 풀리퀘스트(pull request) 방법
