저번주 스터디에서 PR에 관한 이야기를 들었다.
현협에서 쓰기도 한다는데, git에서 내가 작업하고 싶은 repository를 fork 뜬 후,
fork를 뜬 repository에서 작업하고, 작업한 내용을 push한다.
이렇게 되면 지금 내가 fork를 뜬 repository는 변경 사항이 push 되었지만, 내가 fork를 떠온, 즉 원래 original한 repository에 변경사항은 아직 적용되지 않았다. 이러한 이점 때문에 회사에서 PR을 사용하는 것 같다. git repository에 CI/CD를 적용해 push되면 자동으로 서버에 올라가는 시스템이 갖추어져 있다면 original Repository에 push하는 행동은 매우 민감한 행동이라고 생각된다. 그렇기 때문에 CTO나 팀장이 직원이 수정한 코드를 보고 이걸 적용시켜도 되는지 안되는지를 판단해 merge하는게 훨씬 더 안정성 있는 매커니즘 이라고 생각된다.
순서를 잠깐 살펴보자면.
- original repository를 fork
- fork뜬 repository(이하 fork_repo)에서 작업
- 작업한 내용들을 fork_repo에 push
- fork_repo에서 origin_repo에 PR 요청을 보내 merge 요청
- origin_repo에서 받아서 본 후 검토 및 merge
4번부터 잠깐 살펴 보자면
저기 보이는 New pull request 를 클릭해 들어가보자
여기서 pull request를 origin_repo에게 보내게 된다. 위에 화살표 모양을 잘 보면 오른쪽이 fork_repo 이고 왼쪽이 origin_repo 이다. 이렇게 Pull request를 생성해서 오른쪽 하단의 초록색 Create pull request 를 클릭하면
origin_repo에 가보면 Pull request가 온 걸 볼수있다. 이제 저기 들어가서 검토하고 merge하면 된다.
참고 링크
https://wayhome25.github.io/git/2017/07/08/git-first-pull-request-story/
git 초보를 위한 풀리퀘스트(pull request) 방법 · 초보몽키의 개발공부로그
개발을 하다 보면 코드를 여러 개로 복사해야 하는 일이 자주 생긴다. 코드를 통째로 복사하고 나서 원래 코드와는 상관없이 독립적으로 개발을 진행할 수 있는데, 이렇게 독립적으로 개발하는 것이 브랜치다. - pro git book
wayhome25.github.io
