Github Issue & PR 관리

github issue

이번 프로젝트를 시작하면서, Github Project 내 Issue 를 만들어 관리를 하고 있습니다. 

그런데 회사에서는 SVN 을 사용하다보니, 사용방법이 익숙하지 않아 히스토리가 꼬여버리는 둥 .. 용도에 맞지 못하게 사용하고 있다는 생각이 들었는데요, 이참에 Github Issue & PR 관리에 대해서 한번 정리하는 시간을 갖고자 합니다. 

 

Issue 란?

이슈(Issue) 란 프로젝트에서 작업해야 할 단위라고 할 수 있습니다. 

 

개발해야야 하는 기능, 수정해야할 버그, 리팩터링 해야 할 코드 등 프로젝트에서 발생되는 작업들을 이슈로 생성하여 관리합니다. 

이슈를 생성해 관리한다면, 이슈에 대한 커밋 내역들을 하나의 이슈 페이지에서 관리가 가능하며, 이슈 관련 정보를 한 곳에서 묶어서 관리할 수 있다. 

또한 코멘트 기능을 통해 서로의 의견을 주고받을 수 있어 작업을 단위로 구분하여 협업 및 관리하기 편하도록 도와준다. 

 

추가적으로 이슈 생성 시, 이슈번호가 부여되는데 이를 통해 이슈 관리가 가능하다. 

Issue Flow 

1. A 라는 기능을 개발해야 하는 상황 발생 
2. A 기능 개발에 대한 Issue 생성 
3. A 기능 개발에 대한 A 브랜치 분기 
4. 생성한 브랜치에서 A 기능 개발 시작 
   (이때, 커밋메시지에 #이슈번호 를 붙여주면 해당 이슈 페이지에서 커밋 내역을 확인할 수 있다)

PR 이란? 

PR 은 서로 다른 브랜치에서 변경 사항을 merge 하기 위해, "내가 만든 변경사항을 반영해줘" 라는 요청을 의미한다. 

보통의 PR 은 이슈 단위로 수행된다. 
(이슈 단위로 브랜치를 생성하고, PR 을 하게 된다) 

PR Flow

1. A 기능 개발을 위해 만든 A 브랜치에서 기능 개발 
2. 기능 개발이 완료된 A 브랜치는 merge 를 위해 PR 을 보낸다.
   (원격 저장소에 push 를 하게 되면 자동적으로 PR 을 보내게 된다)
3. 팀원 간, 코드리뷰를 진행하고 리뷰를 마친 PR 은 merge 한다. 

실전 Issue & PR Flow

잘 정리한 블로그가 있어 해당 블로그에서 실습 시나리오를 확인해보자. 
실습 시나리오