협업 프로젝트에 필요한 Github 활용 방법
개발 공부를 하다보면 종종 "정답은 없다"라는 말을 듣곤 합니다.
어딘가 더 나은 방법이 있을 수 있다는 개발자들의 철학이 담긴 말이지만,
초심자에게는 이런 말은 그저 광야와 같은 느낌이죠..
협업 개발의 방법도 여러 가지가 있습니다.
본 포스트는 예제를 찾고 있는 분들에게 조심스럽게 한 가지 예시가 되어드립니다.
물론, 이것은 정답이 아닙니다.
순서
1. [Github] Issue
2. [Github] Projects
3. Branch 전략
4. Commit 단위
5. Pull-Request
6. Code Review
1. Issue를 이용한 작업 등록
What
- issue : 새로 추가할 기능, 개선해야할 기능, 버그 등 프로젝트에 필요한 모든 작업 이슈(issue)라고 칭합니다.
- 한 줄 요약 : [A 개발 할 예정입니다! (담당자 : 캐슬)] 또는 [BUG! B 수정 필요합니다!]
Why
- 다른 개발자들과 함께 개발할 때는, 일반적으로 전체 프로젝트에 필요한 세부 작업들을 개발자별로 분배하게 됩니다. 작업량이 많아지면 내가 어떤 작업을 했는지, 다른 사람들이 현재 어떤 작업을 하고 있는지, 앞으로 남은 작업이 어떤 것이 있는지 파악하기가 쉽지 않은데, 그런 작업의 흐름을 알 수 있게 도와주는 툴이 Issue입니다.
- issue는 결국 세부 개발 작업을 체계적으로 파악하기 위함입니다. 부여되는 이슈 번호를 통해 다른 개발자들과 해당 이슈를 수월하게 공유할 수 있고, 함께 적용되는 [Label]로 원하는 분류의 작업만 따로 모아 볼 수도 있습니다. 물론, 이슈의 담당자를 파악하는 것도 가능하고요!
How
- 회사마다 이슈를 활용하는 방법이 다양합니다. 어떤 회사는 Jira라는 애자일 프로세스 툴로 이슈 관리를 하고, 이슈별로 부여되는 번호(ex. HDW-1012)를 깃허브 이슈에 연동하는 등의 방법을 활용하기도 합니다.
하지만 제가 Jira를 이용한 경험이 없기 때문에 Jira에 대한 이야기는 패스하겠습니다.
- 깃허브에서 제공되는 기능들을 활용한다면, 다음과 같은 순서로 작업하시면 됩니다.
1) 프로젝트에 필요한 작업을 이슈에 등록한다. 이 때, 해당 작업의 단위는 팀원들과 협의하는게 좋지만, 일반적으로 기능별로 수행한다.
2) 이슈를 등록할 때, 해당 작업에 알맞는 Label, Assignee, Projects, Milestone 등을 설정한다.
- Label : 해당 이슈가 어떤 분류인지 나타내는 스티커이며, Issues 탭의 Labels에서 커스터마이징이 가능
- Assignee : 작업 담당자 (다른 사람의 계정을 설정하는 것도 가능하다)
- Projects : 깃허브 Projects의 칸반 보드에 추가하는 기능
- Milestone : Sprint를 위한 도구로, Due Date를 설정하여 해당 마일스톤에 등록한 이슈들은 달성 퍼센트를 보여줌
3) issue 작성 방법은 자유이지만, 협업에서 같은 양식을 사용하려면 settings 탭에서 template를 설정할 수 있다.
4) 이슈를 작성하면 자동으로 부여되는 번호(ex. #4)를 확인. 추후 해당 이슈 번호로 Commit, Pull Request 시에 적용
[GitHub] PR 템플릿, 이슈 템플릿 등록하기 (Pull Request Template, Issue Template)
GitHub을 이용해서 소스 코드를 관리할 때 PR(Pull Request)라는 과정을 거치게 된다. PR 등록을 하면 소스코드를 관리하는 개발자나 다른 팀원이 PR에 대한 코드 리뷰를 진행하게 된다. PR을 등록할 때
soft.plusblog.co.kr
2. Github Projects를 이용한 프로젝트 관리
Why
- 칸반보드의 핵심은 작업의 시각화입니다. 작업이 복잡해질수록 필요한 도구입니다.
How
- 간단하게 사용한다면, 해야할 작업 / 진행 중인 작업 / 완료된 작업 으로 분류하여 작업할 수 있겠습니다.
- 작업이 많아질 것으로 예상된다면, Projects 내에서 여러 보드로 나눠서 작업할 수 있습니다.
- 작업을 나누는 column은 커스터마이징할 수 있으니, 필요에 맞게 활용하시면 됩니다.
- issue에 작업을 등록할 때, Projects를 설정하면 자동으로 해당 project의 To do에 들어갑니다.(개별 설정)
3. Branch 전략 (Git-Flow vs Github-Flow)
What
1) Git-flow 전략
- master / develop / feature / hotfix / release 등의 브랜치로 운영
- [master] : 배포되었거나 배포될 브랜치
- [develop] : 배포를 위해 개발 중인 브랜치
- [feature] : 각 개발자에 의해 작업 중인 기능 단위의 브랜치
- [hotfixs] : 배포 버전에서 발생된 문제로 빠른 트러블슈팅이 필요할 때 사용되는 브랜치
- [release] : 내부적으로 배포할 준비가 되었다고 판단되는 브랜치(테스트 진행)
- 세부 기능은 이슈 단위로 feature 브랜치를 생성하여 작업 후 삭제 반복 (ex. feature/10-header)
- release에서 수정한 버그가 있다면 develop 브랜치로 적용함
2) Github-flow 전략
- master 브랜치에 명확한 role를 부여한 후 나머지 브랜치는 자유롭게 운영
- 다른 브랜치 생성 시, 자세한 작업 내용을 작성하는 것을 권장
- 자동 배포를 기반으로 한 브랜치 전략
- 자유도가 높다는 장점이 있지만, 프로젝트가 복잡해지고 작업자가 많으면 혼란 가능성
- (개인 의견) 각 작업들이 프로젝트에 미칠 영향에 대해 잘 파악할 수 있는 팀장이 있어야한다고 생각함
How
- 만약 Git Flow 전략을 수행한다면, issue에 작업을 등록한 후, 해당 이슈 내용을 바탕으로 브랜치를 형성하면 됩니다.
- feature 브랜치명은 feature/{issue-number}-{feature-name} 형식으로 이슈 번호를 기입하여 작업을 명확하게 합니다.
- 작업이 완료되어 develop으로 병합된 브랜치가 추후 사용되지 않는다면 삭제한 후, 다시 새로운 작업의 branch를 생성하여 브랜치가 너무 많아지지 않도록 관리합니다.
4. Commit 단위 설정
Why
- Pull request를 보내고 팀원의 코드 리뷰를 진행할 때, 커밋 단위로 변경 내용을 볼 수 있는데, 관련된 작업별로 커밋을 진행해야 리뷰하는 개발자가 보다 원활하게 코드를 이해할 수 있습니다.
- 만약 연관성이 없는 작업들이 같은 커밋에 섞여 있다면, 다른 개발자는 해당 코드가 왜 필요한지 이해하는 과정에서 불필요한 에너지가 소모됩니다. 이는 전체 프로젝트 개발 시간을 증가시키는 원인이 될 수 있습니다.
How
- 커밋은 관련 작업 단위로 나누어서 진행
- 완료되지 않은 작업을 커밋으로 남기지 않기 (실시간 코드 백업 X)
- 작업과 상관 없는 코드 변경은 해당 커밋에 미포함 (ex. 작업과 연관 없는 코드의 lint 수정 등)
깃(Git) 커밋 가이드 - 스타트업 엔지니어링
깃(Git) 커밋마다 겪는 일 팀을 이루어 소프트웨어 개발을 진행하면서 깃(Git)으로 버전 관리를 하는 것은 이젠 너무 당연한 일이 되었습니다. 푸시하고 풀 받고 머지하고, 컨플릭트 수정해서 다시
tech.10000lab.xyz
5. Pull Request 보내고 코드 리뷰 받기
HOW
- PR은 이슈 단위로 작게 진행하는 것이 코드 리뷰하기 편합니다.
- PR 보내는 브랜치를 잘 확인하고 보냅니다.
(실수로 master로 보내고 받았던 경험이...) - Pull Request도 이슈 번호가 생성되기 때문에 PR 보낼 때, 제목에 작업한 이슈 번호를 정확하게 작성합니다.
- Title은 해당 이슈 번호 및 제목으로 작성
- (개인 의견) 리뷰어가 해당 PR에 자신의 Label을 등록하는 것이 한 눈에 파악하기 좋을 것 같습니다.
*PR template 적용 방법
- 최상위 디렉토리에서 .github 디렉토리를 생성 후, PULL_REQUEST_TEMPLATE.md 파일을 만듭니다.
- 해당 .md 파일에 마크다운 형식으로 PR 템플릿 양식을 작성하고, 해당 변경 내용을 repository의 default 브랜치(master)에 병합하면 됩니다.
5. 코드 리뷰
- 코드 리뷰는 코드의 문제점이나 더 나은 방법이 없는지 체크하는 것을 위주로 진행
- 글과 더불어 이모티콘을 잘 활용하여 딱딱하지 않게 작성하기
- 코드 검사가 아닌, 서로 돕고 배운다는 마음가짐으로 리뷰를 주고 받기
- 코드 리뷰의 본질은 code quality 향상을 위함입니다. 코드 스타일보다는 quality에 집중하여 리뷰를..!
코드리뷰의 진짜 목적은 따로있다
코드리뷰의 중요성 코드리뷰란, 한 명 또는 여러 명의 개발자가 본인이 만들지 않은 코드의 내용을 점검(examining)하고, 피드백을 주는 과정을 말합니다. 여기에서 피드백이란 오타, 버그 가능 성,
blog.logi-spot.com
코드 리뷰 in 뱅크샐러드 개발 문화 | 뱅크샐러드
안녕하세요, 뱅크샐러드 BanksaladX iOS Engineer…
blog.banksalad.com
'Development > Front-End' 카테고리의 다른 글
| 반응형 웹(Responsive Web)의 이해 (1) | 2021.10.11 |
|---|---|
| 웹 접근성(Web Accessibility)의 이해 (0) | 2021.10.10 |
| Material-ui (with Typescript) type 수정하기 (0) | 2021.08.19 |
| import 구문 정리 sort-imports + ESlint rules (0) | 2021.07.12 |
| [TIL] - [Javascript] 커링 Curring (& Partial application) (0) | 2021.05.18 |