개인 프로젝트를 하다보면, "내가 예전에 이 코드를 왜 수정했더라?", "지금 내가 당장 개발해야 할 기능이 뭐였지?" 하고 헷갈릴 때가 많습니다.
단순히 git commit -m "수정" 처럼 의미 없는 커밋을 남기거나, 할 일을 메모장에만 적어두면 프로젝트 규모가 커질수록 관리가 힘들어집니다. 오늘은 GitHub의 Issue 기능과 커밋 메시지 컨벤션(Commit Convention)을 활용해 체계적으로 프로젝트를 관리하는 방법을 알아보겠습니다.
1. GitHub Issue: 개발 작업의 나침반
GitHub Issue는 쉽게 말해 프로젝트의 '게시판'이자 '작업 목록(To-Do)'입니다. 버그 제보, 새로운 기능 제안, 개선 사항 등을 모두 Issue로 등록하여 관리할 수 있습니다.
- 체크리스트(Task Lists) 활용: Issue 내용에 - [ ] 문법을 사용하면 체크리스트를 만들 수 있습니다. 예를 들어 '게시판 CRUD 구현'이라는 Issue 안에 [x] 글쓰기, [ ] 수정, [ ] 삭제 처럼 세부 진행 상황을 한눈에 파악하기 좋습니다.
- 담당자 지정 및 라벨링: 누가 이 작업을 할 것인지(Assignees), 이 작업이 버그인지 기능 추가인지(Labels) 명확하게 표시할 수 있어 협업에 매우 유리합니다.
2. 커밋 컨벤션 (Commit Convention): 협업을 위한 약속
Issue를 보고 작업을 마쳤다면 커밋을 남겨야 합니다. 이때 일관된 규칙을 가지고 커밋 메시지를 작성하는 것을 '커밋 컨벤션'이라고 합니다. 보통 AngularJS의 커밋 컨벤션을 널리 사용합니다.
가장 자주 쓰이는 Prefix(접두어)
- feat: 새로운 기능 추가 (예: feat: 게시판 페이징 처리 기능 추가)
- fix: 버그 수정 (예: fix: 게시물 작성 시 발생하는 NPE 에러 해결)
- docs: 문서 수정 (README.md 등)
- style: 코드 포맷팅, 세미콜론 누락 수정 등 (코드 로직 변경 없음)
- refactor: 코드 리팩토링
- test: 테스트 코드 추가 및 수정
- chore: 빌드 업무 수정, 패키지 매니저 설정 등
이렇게 컨벤션을 지키면 git log만 봐도 이 커밋이 어떤 목적을 가지고 있는지 단번에 파악할 수 있습니다.
3. 마법 같은 연동: Commit으로 Issue 닫기
이 두 가지 기능을 함께 쓸 때 진정한 시너지가 발생합니다. GitHub는 커밋 메시지에 특정 키워드와 Issue 번호를 적으면, 코드가 메인 브랜치에 반영될 때 자동으로 해당 Issue를 해결(Close) 처리해 줍니다.
사용 방법: 커밋 메시지 내용에 키워드 #이슈번호 형식으로 작성합니다.
feat: 게시판 페이징 기능 추가
Resolves: #12
주요 연동 키워드:
- Close, Closes, Closed (일반적인 종료)
- Fix, Fixes, Fixed (버그 수정 후 종료)
- Resolve, Resolves, Resolved (이슈 해결 후 종료)
이렇게 설정해두면 이슈 번호 #12와 해당 커밋이 서로 링크되어, 나중에 이슈 히스토리만 봐도 "아, 이 코드를 추가해서 이 이슈가 해결되었구나" 하고 코드의 문맥을 완벽하게 추적할 수 있습니다.
'개발 공부 > 기타 공부' 카테고리의 다른 글
| 리눅스 명령어 (1) | 2025.10.27 |
|---|---|
| Git & Github 공부 - Branch, Branch 합치기 (0) | 2025.09.15 |
| Git & Github 공부 - Git 기본 (1) | 2025.09.15 |
| 비즈니스 로직 vs. 도메인 로직 (0) | 2025.09.14 |
| 최단 경로 탐색 알고리즘 : 다익스트라, 벨만-포드, 플로이드-워셜 (0) | 2025.09.07 |