2023년 1월 1일
08:00 AM
Buffering ...

최근 글 👑

[GitHub-TIL] GitHub 협업시 Issue(이슈)와 Pull Request(PR) 작성법

2024. 5. 1. 16:05ㆍgit & github/git&github-TIL
SMALL

Issue(이슈)와 Pull Request(풀리퀘스트 : 줄여서 PR)에 대해 알아봅시다.

깃허브 협업을 할 때의 가장 기본적인 사항은 1)이슈를 생성하고,

2)이슈를 토대로 브랜치를 파서 3)풀리퀘스트(PR)하고,

4)브랜치를 병합 하는 과정을 볼 수 있습니다.

 

여기서 그러면 Issue(이슈)란 무엇인가?

프로젝트 또는 저장소에 관련된

문제, 버그, 제안 또는 개선 사항을 추적하고

토론할 수 있는 기능인데,

 

가장 쉽게 말을 하자면 

이슈는"내가 작업해야 할 사항"을 말하는겁니다.

 

그렇다면 이슈는 어떻게 파나요?

간단하게 레포지스토리를 파봅시다.

많은 개발자들이 개인 깃허브 내 자신의 레포지스토리의 관리 경험은 해보았으나

풀리퀘스트 줄여서 'PR'는 처음이다 보니 걱정을 많이 합니다.

저 또한 말로만 들어봤지 개인 레포지토리 관리할 때는 쓰지도 않았죠

앞으로 협업을 진행하면서 PR을 많이 많이 하게 될 예정인지라

이곳에 써서 다른 분들께 도움이 되시리라 봅니다.

 

본론으로 돌아가 봅시다.

1. Issue

이슈와 PR을 하기 전 조건이 있습니다!
1. ".gitignore 파일"과 함께 협업 하게 될 레포지스토리를 파셨는지 여부
2. "로컬 저장소"와 "원격 저장소"를 연결 하셨다는 가정 하에 이슈와 PR을 진행한다는 점을 이해 하셨는지 여부.

1 - 1 issue안에서 New issue를 클릭해줍니다.


1 - 2 New issue를 누르게 되면 바로 들어오는 것이 아니라 Issue Template 을 선택할 수 있습니다.

그런데 Issue Template의 경우 협업할 때 2개의 템플릿을 넣어줄 수도 있고,

3개의 템플릿을 넣어줄 수도 있고, 규모가 커지면 템플릿이 많아 질 가능성도 있겠죠?

 

둘 중에 하려는 작업의 목적에 맞게 선택하시면 됩니다.

하려는 작업이 버그 픽스라면 버그 리포트 이슈

하려는 작업이 일반 기능 작업이라면 기능 이슈로

"Get started"를 눌러서 작성하시면 됩니다.


1 - 3 New issue를 누르게 되면 바로 들어오는 것이 아니라 Issue Template 을 선택할 수 있습니다.

1. 하시려는 작업의 제목

이슈 탭에 들어갔을 때 바로 보이는 만큼,

어떤 작업을 하려고 하는지 명확하게 적어주시면 됩니다.

 

2. 이슈의 내용 작성부분

템플릿에 맞게 작성해 주시고, 예시는 사진을 참고하여 진행하시면 됩니다.

작업을 상세히 나눠서 적고 나눈 작업을 단위로 커밋하는 방식입니다.

 

3. Assignees

작업의 담당자를 설정해주는 부분이며, 보통 이슈를 만든 본인이 됩니다.

다른 사람의 이슈를 만들어주는 작업이라면 작업의 담당자를 선택해주시면 됩니다.

 

4. Labels

이슈의 label을 설정하는 부분이며, 해시태그(?)와 비슷하다고 보시면 됩니다.

라벨을 통해 이슈 탭에서 보았을 때

해당 이슈가 어떤 내용의 작업과 연관이 있는지 알 수 있게되는 것이죠.

 

5. Projects

깃허브에 프로젝트가 생성되어 있는 경우 해당 프로젝트를 선택해 줍니다.

지금은 프로젝트가 생성되어 있지 않아서 보이지 않는 것입니다.

 

6. Submit new issue

이슈를 생성하는 버튼입니다.

누르면 이슈 생성이 완료 됩니다.

 

위에서 6번까지 진행했다면 이와 같이 이슈 탭에서 내가만든 이슈를 볼 수 있게 되고,

안에 들어가게 되면 내가 만든 이슈로 생성이 되어 있을 겁니다.

 

이제 브랜치를 생성해봅시다.

위 그림에서 Create a branch를 누르면 아래와 같은화면을 볼 수 있고,

첫번째로 기능을 파셨다면 1- 라는게 보여지고 보통의 브랜치 이름은 되도록 영어로 지어주시면 좋습니다.

ex.) #1-myPage-Login

 

이후 

Open in codespace

Checkout locally

Open branch with GitHub Desktop

 

체크 박스를 확인 할 수 있는데

 

필자는 Checkout locally과 Open branch with GitHub Desktop 두개를 사용했고,

GitHub Desktop은 익숙치 않고 버그도 있는 듯 하여 Checkout locally을 사용했으며,

위 이미지와 같이 설정 후 Create branch를 누르면 새로운 브랜치가 만들어지고,

아래 이미지와 같이 로컬상에서 체크아웃을 할 수 있도록 코드를 제공을 해줍니다. 

git fetch origin

원격 저장소인 origin에서 변경된 내용을 로컬로 가져오는 작업을 수행해주는 명령어이며,

이 명령을 실행하면 로컬 저장소에는 원격 저장소의 최신 변경 사항이 반영되지 않지만,

변경 사항을 로컬로 확인할 수 있게 되는 것 입니다. (반드시 최신화를 진행해 주셔야 문제가 안납니다.)

 

이후 체크아웃을 진행 하면 됩니다.

 

Xcode 상에서도 브랜치가 변경이 되었는지 꼭 확인을 해주어야 합니다.


Pull Request(PR, 풀 리퀘스트)

위 이슈 과정을 통해 브랜치를 만들고 작업을 진행 후 완성을 시켰다면,

내가 작업한 작업물들을 commit, push를 해주고,

깃허브에 들어가면, 자동으로 초록색 버튼의 Compare & Pull Request가 뜨게됩니다.

이런 화면이 보인다면 성공적으로 commit, push가 되었다는 것 또한 알 수 있게 되는 것이고,

Compare & pull request 를 눌러주면 아래와 같은 화면을 확인 할 수 있습니다.

1. 제목작성

PR 전체 내용 요약 정도 작성 하시면 좋을 것 같습니다.

 

2. 내용작성

템플릿에 맞게 작성 하시고,

내용은 마크다운 문법을 참고하여

템플릿에 맞게 작성합니다.

테이블로 구성 정보 - GitHub Docs

기본 쓰기 및 서식 지정 구문 - GitHub Docs

 

preview를 확인해야합니다.

 

테이블을 작성할 때는 마크다운 문법을 참고하여

줄바꿈과 띄어쓰기 없이 작성하는 것을 채택합니다.

 

[이슈 번호]

브랜치 번호이기 때문에 작업한 브랜치,

관련 이슈 모두 브랜치 번호를 입력하시면

자동으로 브랜치와 이슈가 생성되어 있습니다.

그렇게 자동으로 생성된 브랜치와 이슈를 클릭하시면 됩니다.

 

3. Reviewer

[리뷰요청]

리뷰를 요청할 팀원분들 목록을 볼 수 있으며,

보통 팀원분들 모두 선택을 권장합니다.

 

 

4. Assignees

[담당자 설정]

보통 작성자 본인을 설정합니다.

 

5. Labels

작업한 내용에 맞는 label을 선택해주시면 됩니다.

이슈를 만들 때 고른 것과 동일합니다.

 

6. Create pull request

PR 제출~!

728x90