들어가며
GitHub로 프로젝트를 체계적으로 관리할 수 있을까? 팀 프로젝트를 진행할 때 Git을 도입했지만, 모두 처음 사용하는 상황이고 프로젝트 기간상 기본적인 Commit과 Push 과정만 다뤘다. 이번에 개인 토이 프로젝트를 진행하기 전에 협업 기술을 업그레이드하고 싶었고, 효율적으로 관리하기 위해 GitHub의 Issue, Branch, Project 기능을 학습해보고자 했다. 알아갈수록 '이걸 왜 이제 알았을까?'라는 생각이 들었다. 이번 블로그에서는 학습하고 실습한 내용을 정리해보겠다.
설명
✔️ Issue
"Use GitHub Issues to track ideas, feedback, tasks, or bugs for your work on GitHub." [Github 공식 문서 속 설명]
번역 | GitHub Issues를 사용하여 GitHub에서 작업할 아이디어, 피드백, 작업 또는 버그를 추적하세요.
- issue는 레퍼지토리에서 작업 계획, 개선 사항 등을 추적하기 위해 있다.
Issue 기능을 어떻게, 왜 활용할까?
- 모든 버그, 기능 요청, 개선사항을 이슈로 기록할 수 있다.
- 이슈에 라벨을 붙여 우선 순위, 버그, 문서, 기능 등을 포함한 유형, 상태를 구분할 수 있다.
- 마일스톤을 설정하여 특정 기간 내에 완료할 작업을 기록할 수 있다.
- 커밋 메시지나 PR(Pull Request)에서 이슈 번호를 참조(#이슈번호)하여 이슈와 커밋 그리고 PR을 연결할 수 있다.
Issue의 활용했을 때 이점은 팀원과 협업시 이슈 공유를 통해 작업 내용을 명확히 알 수 있고, 모든 변경 사항을 이슈와 연계하여 추적할 수 있다. 그리고 라벨과 마일스톤을 통해 작업의 우선 순위를 알 수 있어 효율적인 커뮤니케이션을 가능하게 한다.
✔️ Branch
"You can attach a pull request or branch to an issue to indicate that a fix is in progress and automatically close the issue when the pull request or branch is merged." [Git 공식 문서 설명]
번역 | Pull Request나 Branch를 이슈에 연결하여 수정 작업이 진행 중임을 나타낼 수 있으며, 해당 Pull Request나 Branch가 병합되면 이슈를 자동으로 닫을 수 있습니다.
Branch는 어떻게 활용될까?
- 작업 단위를 나눠 별도의 브랜치로 관리하며 이에 따른 네이밍 규칙이 있다. (`feature/`, `bugfix/` 등)
- 브랜치에서 작업 완료 후, PR을 통해 코드 리뷰를 진행 후 병합하게 된다.
- 가장 중요하다고 생각하는 부분인데, 중요 브랜치를 보호할 수 있다. main, develop등의 브랜치는 직접 푸시를 금지하고 PR을 통해 변경할 수 있어야 한다.
- PR 푸시할 때 자동으로 빌드 및 테스트를 실행하여 품질을 유지한다.
이렇게 활용했을 때 Branch의 이점은 독립적인 Branch에서 작업하여 main 브랜치의 안정성이 유지되며, 여러 개발자와 협업할 때 코드 리뷰를 통해 코드 품질을 향상시킨다. 그리고 CI/CD 파이프라인을 통해 코드 변경시 자동으로 테스트 및 배포를 수행한다.
✔️ Project
"Projects is an adaptable and flexible tool for planning and tracking work on GitHub." [Github 공식 문서 내용]
번역 | Projects는 GitHub에서 작업을 계획하고 추적하기 위한 적응 가능하고 유연한 도구입니다
Project는 어떻게 활용될까?
- 프로젝트 보드 관련한 여러 템플릿을 설정해 시각적으로 관리한다.
- 특정 이벤트(이슈 생성, PR 병합 등) 발생시 카드를 자동적으로 이동시키는 규칙을 설정한다.
- 이슈와 PR을 프로젝트 보드에 추가하여 전체적인 작업 상황을 시각화한다.
즉, 정리하면 프로젝트 보드를 통해 이벤트를 자유롭게 생성하며 전체적인 작업 상황을 시각화하는 것이 Project인 것이다.
Project의 이점도 살펴보자면, 먼저 작업 상태를 한 눈에 파악할 수 있으며, 팀원 간의 협업을 용이하게 하고, 작업 진행 상황을 명확히 알려준다.
종합적으로 과정을 말로 설명해보자면
- 새로운 기능 요청이나 버그 발견 시, 이슈를 생성하고 라벨 붙임
- 프로젝트 보드에 이슈를 추가하고 작업 상태에 따라 To Do, In Progress, Done 등을 이동하여 작업 상황을 시각화함
- 해당 이슈를 해결하기 위해 'feature/이슈 번호-기능명'형태로 브랜치 생성
- 브랜치에서 작업을 진행하고 커밋 메시지에 'Fixes #이슈 번호'와 같이 이슈 번호를 참조
- 작업 완료 후 PR을 생성하여, 코드 리뷰 진행
- Merge! 리뷰가 완료되면 PR을 병합하고 이슈 번호가 PR과 연결되어 자동으로 이슈가 Closed.
실습
가장 먼저, 프로젝트를 생성합니다.
원하는 레포지토리에 Projects 카테고리로 들어가 오른쪽에 위치한 `Link a project`를 클릭!
New project를 만듭니다. New Project를 누르면 아래의 화면처럼 템플릿을 선택할 수 있는 팝업 창이 뜹니다. 저의 같은 경우네는 맨 첫번째에 있는 `Team planning`을 선택해 진행해 볼 예정입니다.
템플릿 선택 후 Create project 누르면 project 생성 완료인데 버튼 누르기 전에 Project name을 설정하신 다음 누르시면 원하는 Project name을 가지고 생성됩니다! 이 부분은 생성한 후 수정도 가능합니다!
그렇게 생성 된 후의 Project 모습입니다.
이제 Issue를 등록해보겠습니다.
Project와 비슷하게 issue 카테고리를 선택 후 New issue버튼을 클릭하면 됩니다.
Github에서는 작성한 Title로 branch명이 생성이 됩니다.
오른쪽 사이드에 Assigness, Labels, Projects와 Milestone을 설정할 수 있습니다.
Assignees : 해당 이슈의 담당자로 여러명을 지정할 수 있다.
Labels : 해당 이슈에 대한 부과적인 설명을 담당하며 여러 개를 지정할 수 있다.
Projects : 여러 프로젝트에 연결할 수 있다.
Milestone : 단 하나의 마일스톤과만 연결할 수 있다.
branch를 생성하여 연결하고 싶으면 Development 아래의 `Create a branch`를 눌러 branch를 생성 및 연결하여 코드 관리할 수 있습니다.
결론
Issue 등록 후 Branch 생성 한 후 연결하여 PR을 통해 git branch에 합칠 수 있는지 요청하는 작업을 통해 Project를 관리하는 것이 시각적으로도 관리하기 좋고 특히 팀플이나, 업무에 반영하여 사용하면 좋을 것으로 예상되었다.
참고
'Git' 카테고리의 다른 글
[Git/Github] 커밋 메시지 컨벤션 (Commit Message Convention) (0) | 2024.06.12 |
---|---|
[GitHub] Repository Public / Private 서로 변경하는 법 (0) | 2024.03.15 |
[Git] Git을 사용하는 이유 / 간단한 사용법 (0) | 2024.03.14 |