실제 PR 작성 예시 (github)

실제 PR 작성 예시 (bitbuckit)

pull request를 하는 이유
- 깃허브 레포지토리에 있는 브랜치에 푸시한 내역들, 변경된 사항들을 다른 사람들에게 알리는 것
- master 브랜치에 merge되기 전, 변경 사항에 대해 다른 사람들과 논의, 검토할 수 있음 (자연스러운 코드 리뷰로 이루어지기도 쉽다.)
- 해당 브랜치에서 어떤 작업이 이루어졌는지 명시적으로 확인할 수 있다. (코드에 대한 기록도 가능)
- Push 권한이 없는 오픈 소스 프로젝트에 기여할 때
- 협업했을때, 다른 사람의 commit을 볼 일이 많지 않고, 보더라도 master branch와 merge할 때서야 보게되는데, Pull Request는 이러한 접근성을 높혀주는 효과도 있다. (클릭한번이면 변경사항들을 전부 볼 수 있으니까)
pull request 순서
- A라는 브랜치를 만든다.
- A라는 브랜치에서 커밋을 날린다.
- A라는 브랜치를 master로 merge하기 위한 pull request를 만든다.
- 해당 작업이 모두 끝나고, merge 이후, 해당 브랜치를 삭제한다. (pull request에서 merge시에 해당 브랜치를 삭제할지 선택 가능)
pull request의 규칙?
- PR의 제목은 내가 작업한 내용을 한 문장으로 요약해서 작성한다.
- 1개의 PR에는 1개의 기능 추가/변경만 포함하는 것이 좋다. 그래야 리뷰하기도, PR후에 commit을 관리하기도 좋다.