[Github 협업, 이것만은 알자] - Issue & PR

pgmjun·2023년 10월 6일
9
post-thumbnail
post-custom-banner

💭 Issue란?

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

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

이슈를 생성하여 관리하면, 이슈에 대한 커밋 내역들을 하나의 이슈 페이지에서 관리가 가능하며
어떤 작업을 해야하는 지, 누가 해야하는 지, 얼마나 진행됐는 지 등에 대한 정보를 한 곳에 묶어서 관리할 수 있습니다.
또한 코멘트 기능을 통해 서로의 의견을 주고 받을 수 있어 작업을 단위로 구분하여 협업 및 관리하기 편하도록 도와줍니다.

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

⚙️ Issue의 Flow

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


💭 PR이란

PR은 서로 다른 브랜치에서 변경 사항을 합병(Merge) 하기 위하여,
”내가 만든 코드를 가져가줘~!” 라는 요청을 의미합니다.

Pull(당기다) + Request(요청)가져달라고 요청 이라고 이해하면 됩니다.

보통 PR은 이슈 단위로 수행됩니다.

⚙️ PR의 Flow

  • A라는 기능 개발을 위해 develop 브랜치로부터 분기한 A 브랜치에서 기능을 개발
  • 기능 개발이 완료된 A브랜치는 develop 브랜치에 개발한 코드를 합병하기 위해 PR을 보낸다.
  • 팀원 간, 코드 리뷰를 진행하고 리뷰를 마친 PR합병(Merge)


💭 실습

자! 다시 아까 만든 Repository로 돌아왔습니다!

저희는 연습을 위해 신버전을 개발해야하는 개발자가 되어보겠습니다.


📄 시나리오

저희가 진행할 시나리오는 다음과 같습니다.

Hello World를 출력하는 Java 코드가 추가된 새로운 버전을 개발해서 배포해야한다!
지금까지 배운 Branch, PR, Issue 를 사용해서 시도해보자.



💭 Main 브랜치에서 Develop 브랜치 분기

  • 우선 새로운 버전 개발을 위한 develop 브랜치를 main 브랜치로부터 분기합니다.
    • main 브랜치는 git에서 기본으로 제공하는 default 브랜치로 위에서 설명했던 master 브랜치와 같습니다.(이름만 다르며 변경 가능)


💭 이슈 생성

이제 Hello, World 출력 기능 구현을 위한 Issue를 생성해야 합니다.

Issue 생성은 레포지토리 좌측 상단Issue 클릭 후,
화면 중앙부 우측에 표시되는 New issue 버튼을 클릭하여 생성할 수 있습니다.



이슈 생성 화면은 다음과 같습니다.

좌측에서 제목 입력세부적인 설명이 가능하며,

우측에서는 담당자, 라벨, 프로젝트, 마일스톤 등의 설정이 가능합니다.

💡 그런데 우측 탭에 뭐가 이렇게 많죠???

이슈를 생성하기 전에 우선 우측 탭에 대해 자세히 알아볼까요?



🤔 Assigness

해당 이슈를 담당할 책임자를 선택하는 탭입니다.
Organization 내의 맴버들 중 선택이 가능합니다.


🤔 Labels

해당 이슈가 어떤 작업인 지에 대해 간략히 구분하기 위한 마킹 기능입니다.


기본 제공되는 라벨을 사용할 수도 있고, 하단의 Edit labels를 클릭하여 직접 커스텀하여 사용할 수도 있습니다.


저도 이렇게 커스텀한 라벨을 사용해보겠습니다.

라벨 생성은 간단하니 자세히 다루지 않겠습니다. 직접 시도해보시기 바랍니다!



🤔 Projects

Projects는 특정 프로젝트에 대한 이슈들을 한 눈에 확인하여,
보다 효율적으로 관리하기 위해 사용하는 기능으로 아래와 같은 과정을 통해 생성하고 적용할 수 있습니다.


Repository 상단 바에서 Projects 선택


New project 클릭하여 새로운 프로젝트 생성


template을 지정하는 화면이 나오는데 보통 칸반 보드 형식이 자주 사용되기 때문에,
저도 Board를 선택해보았습니다.


그럼 이렇게 프로젝트에 대한 이슈를 한 눈에 확인할 수 있는 칸반 보드가 생성됩니다!

  • 노션에 칸반보드를 두고 사용하시는 분들이 많이 계신데, 깃허브를 통해서도 칸반 보드 사용이 가능합니다.

이슈를 프로젝트에 등록하기 위한 설정은 이슈 생성의 우측 메뉴에서 설정이 가능합니다.



🤔 Milestone

Milestone은 특정 목표를 설정하고 목표에 대한 진행도를 퍼센테이지로 확인하고 관리할 수 있도록 해줍니다.

하나의 목표에 대한 Issue들을 묶어주고
목표의 진행도를 시각화
해주는 기능을 합니다.

Milestone 생성은 아래와 같이 할 수 있습니다.

Issue 페이지에 들어가서, 이슈 생성 버튼 좌측에 있는 Milestones를 클릭합니다.


New milestone 버튼을 클릭하여 새로운 목표를 생성합니다.


Milestone에 대한 Title, Due date, Description을 입력 후,
하단의 Create milestone을 클릭하여 생성을 마무리합니다.


그럼 이렇게 Milestone을 생성하여 하나의 목표에 대한 이슈들을 관리할 수 있습니다.



✨ 이제 정말 이슈를 생성해봅시다.


지금까지 세팅한 우측의 기능들을 모두 세팅해준 후,
Submit new issue 버튼을 통해 이슈를 생성해봅시다!


짜잔! 이슈가 생성되었습니다.

💡 참고로 이슈 제목 옆에 붙은 #1 이 바로 이슈번호 입니다!


Projects 에도 이슈가 잘 등록되었음을 확인할 수 있습니다.



💭 기능 구현

이제 이슈도 생성했겠다! 기능을 구현해봐야지요!


신 버전 개발을 위한 develop 브랜치에서 #1 이슈에 대한 기능을 구현할 feat/#1 브랜치를 생성해보겠습니다.

⚠️ 브랜치 네이밍은 각자 협업 시에, 팀원과 컨벤션을 정의하여 맞추는 것이므로
무조건 제가 쓴 형태를 따라하시면 안됩니다!


이제 Hello, World!를 출력해줄 java 파일을 만들어보겠습니다!

💡 보통은 IntelliJ 또는 VScode 등과 같은 IDE에서 개발 후 프로젝트 파일 전체를 커밋하지만,
오늘은 IDE특정 프레임워크의 프로젝트가 아닌 Github 사용법에 대해 다루는 부분이니 배제하고 진행하겠습니다.


코드를 작성해주었구요!


이제 커밋하려 했는데 또 무언가를 입력하라고 하네요!

대표로 보여질 Commit message와, 추가적인 설명Extended description을 입력하고
feat/#1 브랜치에 커밋합니다.


커밋 메세지를 유심히 보신 분들은 바로 이해했겠지만
저는 Commit message에 이슈 번호를 붙여주었기 때문에 #1 에 해당하는 이슈에 이렇게 커밋에 대한 로그가 남습니다!


Markdown체크박스를 통해 task가 완료된 것을 확인시켜주었고,
이제 기능 개발이 완료되었으니 develop 브랜치로 합병(Merge)하기 위한 PR을 생성하러 가봅시다!



💭 PR 생성

Repository 상단 탭의 Pull requests 버튼을 눌러 PR 생성 페이지로 이동합니다.

여기서 원래는 New pull request를 눌러서 생성해야하나,
feat/#1 브랜치에 방금 pushcommit이 존재하는 것을 Github에서 인식하고 있기 때문에
그것에 대한 PR을 생성하라고 추천해줍니다.

때문에 저희는 간편하게 Compare & pull request 버튼을 눌러 PR을 생성할 수 있습니다.


이것이 PR 내용 작성 페이지입니다!

상단에 탭에서 어떤 브랜치에서 어떤 브랜치로 merge할 지 선택이 가능합니다!

  • base 브랜치default 브랜치main 브랜치가 자동으로 입력되니 저희는 develop 브랜치로 직접 변경해주어야 합니다!
  • 이 부분을 실수하고 Merge 해버리면 되돌리기 복잡해지니 각별히 신경쓰셔야 합니다.

우측 탭은 Issue와 유사하기 때문에 Reviewer를 등록할 수 있는 Reviewers 에 대해서만 간단히 설명 드리겠습니다.


🤔 Reviewers

해당 PR에 대한 리뷰어를 설정하는 부분으로 Organization 환경이라면 해당 그룹 내의 맴버 중에 리뷰어를 선택할 수 있습니다.

리뷰를 요청받은 리뷰어에게는 이러한 알림이 도착합니다!

이제 설명이 끝났으니 Create pull request를 클릭하여 PR을 생성해봅시다


PR 생성을 완료하였습니다!


🤔 Branch protection rule

PR을 열고 하단으로 스크롤을 내리면 이렇게 Add rule이라는 브랜치의 룰을 정하는 기능이 있습니다.

이 부분도 깊이있게 알아보고 싶으신 분들이라면 꼭 학습해보셨으면 합니다!

오늘은 미미나의 짧은 시간이라는 특성 상, 이 기능의 존재만 알리고 넘어가도록 하겠습니다!



💭 이제 Merge 하면 되나?

해당 PR의 하단을 보면 Merge가 가능하다고 출력되었습니다!

그럼 이제 바로 Merge하면 되는 걸까요??

🚨 절.대. 안됩니다.

혼자서 작업하는 중이라면 어쩔 수 없지만,
협업 중이라면 반드시 팀원과의 코드 리뷰를 통해 코드에 버그는 없는 지, 더 효율적으로 코드를 작성할 수는 없는 지 고민해본 뒤에 Merge해야합니다.



✅ 다음으로

그럼 코드 리뷰(Code Review)는 어떻게 하는 걸까요?
다음 시간엔 코드 리뷰(Code Review)에 대해 알아보도록 하겠습니다.

profile
하나씩 천천히 깊이있게 쌓아가는 백엔드 개발자 최승준입니다.
post-custom-banner

0개의 댓글