이슈(Issue)
란 프로젝트에서 작업해야할 단위라고 할 수 있습니다.
개발해야하는 기능 발생
, 수정해야할 사항 버그 발생
, 리팩터링 해야하는 코드 발생
등 프로젝트에서 발생되는 작업들을 이슈로 생성하여 관리합니다.
이슈를 생성하여 관리하면, 이슈에 대한 커밋 내역들을 하나의 이슈 페이지에서 관리가 가능하며
어떤 작업을 해야하는 지
, 누가 해야하는 지
, 얼마나 진행됐는 지
등에 대한 정보를 한 곳에 묶어서 관리할 수 있습니다.
또한 코멘트 기능을 통해 서로의 의견을 주고 받을 수 있어 작업을 단위로 구분하여 협업 및 관리하기 편하도록 도와줍니다.
추가적으로 이슈 생성 시, 이슈번호
가 부여되는데 이를 통해 이슈 관리가 가능합니다.
A
라는 기능을 개발해야하는 상황이 발생A
기능 개발에 대한 Issue
를 생성develop
브랜치에서 A
기능 개발에 대한 Branch
분기Branch
에서 A
기능 개발 시작#이슈번호
를 붙여주면 해당 이슈 페이지에서 커밋 내역을 확인할 수 있다.PR
은 서로 다른 브랜치에서 변경 사항을 합병(Merge)
하기 위하여,
”내가 만든 코드를 가져가줘~!” 라는 요청을 의미합니다.
즉 Pull(당기다)
+ Request(요청)
→ 가져달라고 요청
이라고 이해하면 됩니다.
보통 PR
은 이슈 단위로 수행됩니다.
A
라는 기능 개발을 위해 develop
브랜치로부터 분기한 A
브랜치에서 기능을 개발A
브랜치는 develop
브랜치에 개발한 코드를 합병하기 위해 PR
을 보낸다.코드 리뷰
를 진행하고 리뷰를 마친 PR
은 합병(Merge)
자! 다시 아까 만든 Repository
로 돌아왔습니다!
저희는 연습을 위해 신버전을 개발해야하는 개발자가 되어보겠습니다.
저희가 진행할 시나리오는 다음과 같습니다.
Hello World를 출력하는 Java 코드가 추가된 새로운 버전을 개발해서 배포해야한다!
지금까지 배운Branch
,PR
,Issue
를 사용해서 시도해보자.
develop
브랜치를 main
브랜치로부터 분기합니다.main
브랜치는 git에서 기본으로 제공하는 default 브랜치로 위에서 설명했던 master
브랜치와 같습니다.(이름만 다르며 변경 가능)이제 Hello, World 출력 기능 구현을 위한 Issue
를 생성해야 합니다.
Issue
생성은 레포지토리 좌측 상단의 Issue
클릭 후,
화면 중앙부 우측에 표시되는 New issue
버튼을 클릭하여 생성할 수 있습니다.
이슈 생성 화면은 다음과 같습니다.
좌측
에서 제목 입력
과 세부적인 설명
이 가능하며,
우측
에서는 담당자
, 라벨
, 프로젝트
, 마일스톤
등의 설정이 가능합니다.
💡 그런데
우측
탭에 뭐가 이렇게 많죠???
이슈를 생성하기 전에 우선 우측
탭에 대해 자세히 알아볼까요?
해당 이슈를 담당할 책임자를 선택하는 탭입니다.
Organization
내의 맴버들 중 선택이 가능합니다.
해당 이슈가 어떤 작업인 지에 대해 간략히 구분하기 위한 마킹 기능입니다.
기본 제공되는 라벨을 사용할 수도 있고, 하단의 Edit labels
를 클릭하여 직접 커스텀하여 사용할 수도 있습니다.
저도 이렇게 커스텀한 라벨을 사용해보겠습니다.
라벨 생성은 간단하니 자세히 다루지 않겠습니다. 직접 시도해보시기 바랍니다!
Projects
는 특정 프로젝트에 대한 이슈들을 한 눈에 확인하여,
보다 효율적으로 관리하기 위해 사용하는 기능으로 아래와 같은 과정을 통해 생성하고 적용할 수 있습니다.
Repository
상단 바에서 Projects
선택
New project
클릭하여 새로운 프로젝트 생성
template
을 지정하는 화면이 나오는데 보통 칸반 보드 형식이 자주 사용되기 때문에,
저도 Board
를 선택해보았습니다.
그럼 이렇게 프로젝트에 대한 이슈를 한 눈에 확인할 수 있는 칸반 보드
가 생성됩니다!
노션
에 칸반보드를 두고 사용하시는 분들이 많이 계신데, 깃허브를 통해서도 칸반 보드 사용이 가능합니다.이슈를 프로젝트에 등록하기 위한 설정은 이슈 생성의 우측 메뉴에서 설정이 가능합니다.
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
을 생성하러 가봅시다!
Repository 상단 탭의 Pull requests 버튼을 눌러 PR 생성 페이지로 이동합니다.
여기서 원래는 New pull request
를 눌러서 생성해야하나,
feat/#1
브랜치에 방금 push
된 commit
이 존재하는 것을 Github에서 인식하고 있기 때문에
그것에 대한 PR
을 생성하라고 추천해줍니다.
때문에 저희는 간편하게 Compare & pull request
버튼을 눌러 PR
을 생성할 수 있습니다.
이것이 PR 내용 작성 페이지입니다!
상단에 탭에서 어떤 브랜치에서 어떤 브랜치로 merge할 지 선택이 가능합니다!
base 브랜치
는 default 브랜치인 main
브랜치가 자동으로 입력되니 저희는 develop
브랜치로 직접 변경해주어야 합니다!Merge
해버리면 되돌리기 복잡해지니 각별히 신경쓰셔야 합니다.우측
탭은 Issue
와 유사하기 때문에 Reviewer
를 등록할 수 있는 Reviewers
에 대해서만 간단히 설명 드리겠습니다.
해당 PR에 대한 리뷰어를 설정하는 부분으로 Organization
환경이라면 해당 그룹 내의 맴버 중에 리뷰어를 선택할 수 있습니다.
리뷰를 요청받은 리뷰어에게는 이러한 알림이 도착합니다!
이제 설명이 끝났으니
Create pull request
를 클릭하여 PR을 생성해봅시다
PR 생성을 완료하였습니다!
PR
을 열고 하단으로 스크롤을 내리면 이렇게 Add rule
이라는 브랜치의 룰
을 정하는 기능이 있습니다.
이 부분도 깊이있게 알아보고 싶으신 분들이라면 꼭 학습해보셨으면 합니다!
오늘은 미미나의 짧은 시간이라는 특성 상, 이 기능의 존재만 알리고 넘어가도록 하겠습니다!
해당 PR의 하단을 보면 Merge
가 가능하다고 출력되었습니다!
그럼 이제 바로 Merge
하면 되는 걸까요??
🚨 절.대. 안됩니다.
혼자서 작업하는 중이라면 어쩔 수 없지만,
협업 중이라면 반드시 팀원과의 코드 리뷰를 통해 코드에 버그는 없는 지, 더 효율적으로 코드를 작성할 수는 없는 지 고민해본 뒤에Merge
해야합니다.
그럼
코드 리뷰(Code Review)
는 어떻게 하는 걸까요?
다음 시간엔코드 리뷰(Code Review)
에 대해 알아보도록 하겠습니다.