저는 프로젝트 기간동안 Github로 협업을 진행했습니다. 이전까지는 활용하지 않았던 기능들이 많았는데, 사용하면서 협업에 굉장히 많은 도움이 된다고 느꼈습니다.
이 글에서는 팀이 Git과 Github에서 어떤 전략을 적용했고, 적용하면서 느낀 장점이 무엇인지 기록하려고 합니다.
Git 전략
만약 개발자들 마음대로 브랜치를 만들고 머지하고를 반복한다면 누가 무엇을 했는지, 언제 무엇을 했는지를 파악하기 어렵게 됩니다. 따라서 이런 문제를 해결하기 위해 다양한 전략이 존재합니다.
브랜치 전략 / Git Flow
Git-flow에는 5가지 종류의 브랜치가 존재합니다. 항상 유지되는 브랜치 두 개(master, develop)와 과 일정 기간 동안만 유지되는 브랜치 세 가지(feature, release, hotfix)가 존재합니다.
- master/main : 제품으로 출시될 수 있는 브랜치
- develop : 다음 출시 버전을 개발하는 브랜치
- feature : 기능을 개발하는 브랜치
- 기능 개발을 마친 브랜치는 바로바로 삭제하기
- release : 이번 출시 버전을 준비하는 브랜치(출시 전 테스트 진행)
- hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치
그렇기 때문에 브랜치의 네이밍 규칙도 분야 별로 달리 했습니다. 예를 들어 기능 개발을 진행하는 브랜치를 새롭게 만드는 경우에는 feature/{분야}/{기능 이름} 이런 식입니다.
- ex) feature/fe/login
제가 진행한 팀 프로젝트에서는 프론트엔드/IOS/백엔드로 분야가 나뉘어져 있기 때문에
develop브랜치를 다시 세 분야의 브랜치로 나누었습니다. (develop-fe, develop-be, develop-ios)
⭐ 그런데 왜 feature는 슬래시(/)로 하고 develop 분기 브랜치는 하이픈(-)으로 했나요?
error: unable to resolve reference refs/heads/develop/fe: Not a directory
fatal: Failed to lock ref for update: Not a directory브랜치 분기 도중에 이런 오류를 만났습니다. 찾아보니 error: unable to resolve reference refs/heads/develop/fe: Not a directory 이 부분은 Git이 "refs/heads/develop/fe"라는 브랜치 참조를 해결할 수 없다는 것을 나타냅니다. 이는 Git이 해당 브랜치를 찾지 못했다는 의미입니다.
fatal: Failed to lock ref for update: Not a directory 이 부분은 Git이 해당 브랜치를 업데이트하려고 시도했지만 "Not a directory" 오류로 인해 실패했다는 것을 나타냅니다. 이 오류는 Git이 브랜치를 디렉토리로 처리하려고 했지만 해당 디렉토리가 존재하지 않는다는 것을 의미합니다.
이러한 오류는 "develop/fe"라는 브랜치 이름을 Git이 디렉토리 구조로 해석하려고 시도한 결과로 보입니다. 그러나 "develop" 브랜치가 이미 존재하는 경우에는 "develop" 디렉토리 안에 "fe" 브랜치를 자동으로 생성하지 않습니다. 대신 "develop/fe"라는 브랜치 이름을 독립적인 브랜치로 처리하고자 하며, 이로 인해 디렉토리 관련 오류가 발생할 수 있습니다.
$ cd .git/refs/heads
$ ls -l
total 1
-rw-r--r-- 1 user 197609 41 Sep 20 14:28 develop명령어를 통해 직접 확인해보니 develop는 디렉토리가 아니라 파일(분기)이었습니다. 이를 해결하는 방법은 develop 브랜치를 삭제하거나 다른 이름을 사용하는 것입니다. 그러나 브랜치 삭제는 강제로 지우는 것이기에 이름을 바꿔서 사용하기로 결정했습니다.
커밋 컨벤션
| 태그 | 설명 |
|---|---|
| feat | 새로운 기능을 추가 |
| fix | 버그 수정 및 기능 수정 |
| design | CSS, 스타일 등 사용자 UI 디자인 |
| rename | 변수명, 함수명 수정 |
| remove | 파일을 삭제하는 작업만 수행한 경우 |
| comment | 필요한 주석 추가 및 변경 |
| hotfix | 급하게 치명적인 버그를 고쳐야 하는 경우 |
| docs | 문서 수정 |
| chore | 빌드 업무 수정, 패키지 매니저 수정, 패키지 관리자 구성 등 업데이트, Production Code 변경 없음 |
- commit 형식 :
Tag: Commit Message (#Issue Number) - ex)
feat: 로그인 기능 구현 (#1) - tag는 소문자로 작성한다.
이런 식으로 컨벤션을 정해 놓으면 협업하는 서로 간의 코드 리뷰에 도움이 될 뿐 아니라, 자신의 이전 로그를 살펴보는 것에도 도움이 될 수 있을 것입니다.
⭐ 커밋에 상세한 설명 작성하기
저는 지금까지 커밋 git commit -m명령어로 제목만을 작성해서 어느정도 추상적일 수 밖에 없는 커밋 메시지를 남겨왔습니다. (커밋 메시지는 한줄만 작성 할 수 있는 줄 알았습니다 ...)
프로젝트가 끝나고 다른 개발자분의 pull request를 살펴보았는데, 커밋 제목뿐만 아니라 본문이 있는 것을 확인했습니다.
이런 식으로 커밋 메시지 본문에 상세한 설명을 담으면 제목만 작성하는 것보다 훨씬 더 팀원의 이해를 도울 수 있다고 느꼈습니다.
Github Issue & Project
GitHub Issue는 소프트웨어 개발 프로젝트에서 문제, 개선 사항, 작업 항목 등을 추적하고 토론하는 도구입니다.
Issue 컨벤션
## 🤖 title
## 💭 detail
- [ ]
- [ ]
## reference (optional)
## ⏰ 예상 소요 기간
(30분 단위)
사전에 프로젝트에 대한 백로그를 작성하고, 이를 바탕으로 이슈를 작성했습니다.
프로젝트는 기한을 준수하는 것이 매우 중요합니다. 성공적으로 기한을 맞추기 위해서는 체계적인 계획 수립과 실행이 핵심이라고 생각합니다. GitHub Issue는 이러한 목표를 달성하기 위한 효율적인 프로젝트 관리와 협업을 지원하는 도구라고 느꼈습니다.
GitHub Project는 프로젝트 관리를 위한 도구로, 작업을 보드 형식으로 구성할 수 있으며, Todo, In Progress, Done과 같은 상태로 진행상황을 관리 할 수 있습니다.
Pull Request(PR)
Pull Request는 포크가 아닌 브랜치를 생성하는 방식으로 진행했습니다.
PR 컨벤션
## PR 작성 전 체크 리스트
- PR 제목: `[파트이름] 구현사항` (예: `[FE] Login page UI 구현` )
- PR 작성 후 충돌이 안 나는지 확인, merge후 branch 삭제
- 고민사항은 공유하기
- 위 사항 확인 후 내용 지우기~~
## 🔖 관련 이슈
- `#1` ( #이슈번호 )
## 📝 구현 사항
- 한 것들 적기
## 📌 하고싶은 말 or 고민 했던 내용PR을 통해 코드 변경 사항에 대한 설명을 제공할 수 있어 팀원의 작업 사항을 쉽게 확인할 수 있었습니다.
Pull Request를 이용하면 어떤 파일이 변경되었는지 한 눈에 확인가능합니다. 협업을 하면 서로 작업한 코드를 merge해야 하기전 충돌의 여부를 쉽게 확인 할 수 있다고 느꼈습니다.
마치며
프로젝트를 진행하면서 git 전략과 다양한 규칙을 정하는 과정은 한 가지 원칙을 관통하고 있다고 느꼈습니다.
내가 무엇을 하려고 하는지, 무엇을 하고 있는지, 무엇을 했는지를 팀이 알 수 있도록 하자.
동시에 나도 팀이 무엇을 하려고 하는지, 무엇을 하고 있는지, 무엇을 했는지를 파악할 수 있다.
팀 전체가 현재의 상황을 정확히 파악할 수 있다면, 다음에 어떤 행동을 취해야 할지 더 빠르고 명확하게 정할 수 있을 것입니다. 실제로 저는 프로젝트 기간동안 백엔드 API 구현 상황을 파악하고 있어 구현 계획을 빠르게 수립할 수 있었습니다.
개발자의 협업능력은 팀의 효율성과 프로젝트 성공에 큰 영향을 미치며, 효과적인 커뮤니케이션, 문서화, 작업 관리, 코드 협업, 프로젝트 관리를 위해 협업 도구를 사용할 줄 알고 모르고의 차이는 상당할 것으로 보입니다.
