00. 개요
이번에 각자 배웠던 Security, Spring, JWT 등을 바탕으로 팀 프로젝트로 게시판 CRUD를 작성하게 되었다.
항상 팀 프로젝트를 할 때마다 느끼는 거지만, 어떻게 협업해야 더 좋은 코드가 탄생하고, 어떻게 진행해야 하는지 고민에 빠지게 된다.
사람마다 성향도 다르고, 실력도 다르고, 코드 스타일도 다르고 모든게 다른데, 어떻게 기업 단위로 협업을 하고 맞춰나가는지 신기할 따름이다.
이에 관해, 우리 팀은 깃허브와 관련해 어떤 전략을 추구하고자 하는지 적어보고자 한다.
01. 팀 프로젝트
깃을 최대한으로 활용하고자 노력했다.
기존에 쓰지 않았던 다양한 기능들을 사용하고, 여러 기능들을 맛보면서 깃과 깃허브에 대해 깨닫는 시간을 갖자도 팀원들과 얘기했다.
그래서, 내가 평소 해보고 싶던 다양한 기능들을 적용할 수 있었다.
01. GitHub Issues
가장 먼저 Issue 들이다.
프로젝트에서 발생한 버그나, 추가 요청사항에 대해 Issue를 던지고 Asignee를 설정한다.
혼자 신나서 이것저것 이슈를 던지긴 했는데, 팀원분들이 이슈를 자주 확인해주시고 해당 요구사항을 반영해주셔서 원활히 돌아갔었다.
Label도 적용해보았는데, 다음에는 커스텀하여 마일스톤이나 프로젝트 같은 추가 기능을 더 사용해보아야겠다고 생각했다.
02. GitHub PullRequest
develop branch로 부터 각자 기능 개발 브랜치로 분기하여 작업하기로 했는데, 이후 해당 브랜치 작업이 완료되었을 때 develop branch로 Merge하는 Pull Request를 날리는 것을 원칙으로 했다.
이를 위해, 깃허브의 기능을 통해 가장 먼저 main 브랜치를 막아두고, develop 브랜치에 대한 규약을 설정해두었다.
Merge하기 이전에 Pull Request를 통해서만 Merge가 가능하도록 규약을 설정해두어, 일방적인 Merge를 방지하고자 했다.
이를 통해 모든 팀원들이 작업한 내용은 PR을 통해서만 develop 브랜치에 merge할 수 있게 되었다.
팀 내에서, 코드를 리뷰하고 문제점은 없나 파악한 뒤 Merge를 수락하거나 Close 하는 역할을 맡아서 담당했다.
또한, Conflict가 있는 경우 직접 수정해 내가 다시 Merge를 진행하기도 했다.
이를 통해 PR을 수락하기도, 거절하기도 해보고, PR Conflict에 대한 대처 방식도 익혔다.
아직 컨벤션이나 PR 내용들이 뒤죽박죽이긴 하지만, 그래도 해당 기능을 적극적으로 활용했다는 것이 뿌듯하다. 다음에는 PR에 관한 컨벤션을 더 견고히 만들어 좀더 현업같은 분위기에서 PR을 진행하면 좋겠다고 생각했다.
03. Git Convention
프론트쪽에서 현업을 지내다 오신 팀원분의 주도하에 깃 컨벤션에 대해 고민했다.
브랜치 명을 팔때, 기능 요청서에 작성된 브랜치 명을 바탕으로 진행했다.
예를 들어, 대댓글 기능을 구현할 때 2-7 이라는 브랜치를 파서 그 곳에서 작업하는 방식이다.
커밋에 대한 컨벤션은 흔히 찾아볼 수 있는 컨벤션을 적용하였다.
02. 결론
이를 바탕으로 다음과 같은 이쁜 깃 협업 로그를 남겨둘 수 있게 되었고, 충분히 훌륭한 협업을 진행할 수 있었다.
깃과 깃헙은 참 재미있는 것 같다.
가독성을 좋아하는 나로서는, 최대한 예쁜 커밋 로그와 메세지, Issue, PR 등을 남길 수 있도록 노력했는데, 되돌아보면 그마저도 상당히 중구난방하다는 것을 깨닫는 계기가 되었다.
이를 바탕으로 다음에는, 프로젝트 협업에 대한 약속을 진행함에 있어 더 많은 시간을 투자해, 더 규칙성 있는 프로젝트 제작과 협업이 될 수 있도록 해야겠다고 생각하게 되었다.
항상 돌아보면 부족함이 보이는 것 같다. 계속해서 리팩터링을 진행하는 이유이기도 하고,
적어도 그 일을 했던 나보다는 조금 더 성장 했다는 뜻이니 긍정적으로 받아들이기로 했다.
02. 오늘의 한 문단
좋은 프로젝트는 좋은 팀 분위기와 약속 지키기에서 나온다.
