- Git 브랜치 협업 전략
Git Flow 전략을 일부 수정해서 사용했습니다.
main: 서비스를 직접 배포하는 브랜치
dev: 각 feature 브랜치의 내용을 합쳐서 개발 환경 테스트 브랜치
feature/{workingName}: 기능별로 개발하는 브랜치
hotfix: main 브랜치로 배포했으나 급한 버그가 생겼을 경우 수정하기 위한 브랜치
release 브랜치는 따로 두지 않았습니다.
feature 브랜치 작업 완료 후 dev에 머지가 성공적으로 이루어지면 해당 feature 브랜치는 삭제해서 브랜치 상태를 깔끔하게 유지했습니다.
기획에서 기능별로 task를 세분화했었기에 초기에는 병합충돌도 없이 깔끔하게 협업이 진행되었습니다.
하지만 어느 정도 기능들이 구현되고 자잘한 버그나 공용으로 사용하는 파일들을 수정하기 시작하니 병합 충돌이 일어나기 시작했습니다.
해당 충돌은 vscode 내 pull 시 병합 편집기나 github 자체 병합 편집기를 사용해서 다 같이 화면 공유를 통해 해결했습니다.
각자의 feature나 fix 등 작업을 마친 뒤에는 PR 템플릿에 맞춰 작성하여 팀원들에게 공유 및 코드 리뷰를 받았습니다.
PR에 대한 확인은 매일 아침 코어타임 전 회의에서 다 같이 확인한 뒤 추가 코드 리뷰 및 Approve을 통해 PR이 쌓이는 것을 방지하였습니다.
PR을 할 때에는 반영 브랜치, 작업한 내용에 대한 설명, 변경 사항에 대한 커밋 링크 및 task, PR 포인 및 질문, 논의 사항을 작성하였습니다.
PR을 머지하기 위해서는 최소 2명 이상의 팀원이 Approve를 해야 머지가 가능하도록 설정해서 병합 안정성을 더했습니다.
또한 깃허브 레포에서의 PR 및 커밋 사항을 슬랙과 연결해서 진행 상황을 실시간으로 확인할 수 있도록 했습니다.
- 노션 칸반보드 task 관리
저희는 노션의 칸반보드 및 리스트를 통해 task를 관리했습니다.
에픽 및 기능별로 task를 세분화해서 각 팀원들이 배분하여 데드라인을 잡고 task를 수행했습니다,
칸반보드 task 내에서 세부적인 Todo task를 나누어서 꼼꼼하게 개발을 진행했습니다.
그 외 즉각적인 이슈나 개발 중 질문사항 및 질문이 있으면 바로바로 슬랙으로 공유하면서 비동기 협업의 공백을 메꿨습니다.