팀 프로젝트를 시작하니 나 혼자서 내 repo만 관리할 때보다 훨씬 조심스러워진다. 팀 레포를 건드릴 때마다 수전증이 올 것 같다. ㅋㅋㅋㅋㅋㅋㅋㅋ

git branch 전략

그 과정이 사알짝 좌충우돌이긴했지만! ㅋㅋㅋㅋ 우리 팀의 브랜치 전략도 최종적으로는 잘 합의가 되었다. 초장에 팀 브랜치 전략이 제대로 잡혀있지 않으면 컨플릭 덩어리에 지저분한 레포가 되고, 결국 컨플릭 책임 소재도 불분명해져서 갈등의 원인이 된다는 이야기를 여러번 들었다. 그래서 최종 합의된 브랜치 전략을 구두로 공유하는 것만으로는 부족하다는 생각이 들었고, 기획 단계에서 아예 우리가 정한 브랜치 전략이 팀원 모두의 손에 익은 상태에서 코드 작성을 시작해야겠다고 마음 먹었다.

그래서 고민 끝에

• 노션에 우리 팀의 PR 루틴과 규칙을 매뉴얼화하여 언제든지 모두가 볼 수 있도록 하고,
• git-practice라는 폴더를 만들어서 팀원분들과 매일의 루틴을 연습

하는 시간을 가졌다.

브랜치 전략 매뉴얼화

우리 팀의 브랜치 전략은 요약하면 다음과 같다.

• 각자 feature 브랜치를 만들어 기능 개발
• 매일 아침 9시까지 팀 레포의 dev 브랜치로 PR을 날리기
• 9시 회의 때 팀 레포 dev 브랜치에 merge
• 개인 레포로 변경된 팀 코드 pull해오기

이것이 우리 팀의 에브리데이 루틴이 될 것이다.
이렇게 브랜치 전략이 루틴화되면 예측 가능하고 일관성 있게 팀 레포를 관리할 수 있을 듯 하다.

나를 포함하여 이제 막 github의 브랜치 전략을 배우기 시작하신 팀원분들이 많았기 때문에, 당분간 PR 시 모두가 참고할 수 있는 자료를 노션에 만들어놓았다.

git-practice 폴더를 만들어서 다같이 연습

team repo dev 브랜치에 임시로 git-practice 폴더를 만들고 다함께 우리의 브랜치 전략을 손에 익히는 시간을 가졌다.
이렇게 먼저 폴더를 만들어서 team 레포의 dev 브랜치에 올려놓고 팀 회의 시간에 다같이 dev에 PR 날리기 연습할 준비를 해보았다.

노트북이 잠시 아파해서 연습에 참여하지 못하신 무생님을 제외하고는 모두 성공할 수 있었다!! 👏🏻👏🏻👏🏻👏🏻👏🏻

처음으로 맞춰보는 날이어서 중간중간 에러도 나고 대략 30분 정도 걸렸지만, 매일의 루틴을 한 번 다같이 연습을 해봤으니 개발 단계에 들어가면 훨씬 수월하게 PR과 pull을 하실 수 있을거라 생각이 든다.

gitmoji 활용 제안 및 도입

나를 제외하고 gitmoji를 사용하시는 분들이 우리 팀원 중에 아무도 안 계셨다. 나는 gitmoji를 지금까지 사용해오면서 장점이 많다고 느꼈고, 우리 팀에도 도입해보면 좋겠다고 생각하여 제안했다. 그리고 팀 전체에서 활용하기로 최종 결정!

내가 느꼈던 gitmoji 장점

• 시각적으로 명료하다.
  • 색깔이 다 다르기 때문에 어떤 작업이 어디에 있는지를 history에서 보다 명료하게 파악할 수 있다.
• 커밋의 일관성
  • gitmoji 규칙이 팀에 확립되면 협업이 간편해지고 코드 리뷰도 원활하게 진행할 수 있다.

그래서 우리 팀 gitmoji 규칙도 노션에 정리를 해보았다.

다들 잘 사용하고 계신다.

아주 굳굳!! 👍 👍

Milestone, Issues, Kanban board

칸반 보드는 이전에 solo project를 할 때 한 번 활용해보아서 나름 익숙하지만 (물론 티켓 단위로 작업을 쪼개는 건 아직 어렵다.) Milestone이랑 Issues는 처음으로 다뤄봤다.

Kanban board

프론트엔드

백엔드

티켓을 하나의 작업에서도 좀 더 세세하게 쪼개면 좋겠지만, 아직은 연습 단계여서 칸반 보드를 이용하는 것에 익숙해지는 데 의의를 두고 있다. ㅎㅎㅎ

Milestone, Issues

Milestone은 처음에 익숙하지가 않아서 어떻게 활용해야 하는지 좀 헤맸다. 일단 진척도 파악이 필요한 작업 단위로 만들어보았다. 각 Milestone에 해당하는 Issue들이 있을 것이고, 해당 Issue에서 Milestone을 지정하면 진척도를 표시해가면서 활용할 수 있다.

우측에 Milestone을 지정하는 곳이 있다.

한 블로거분에 의하면 Milestone과 Issues는 1:N 관계라고 생각할 수 있다고 하는데, 직접 만들어서 사용해보니까 이해가 된다.
https://jnhro1.github.io/web/2021/06/10/github-issue,milestone.html

회고

milestone, issues는 처음 활용해보는 거라 제대로 이점을 누리는 건 어려웠고 이번에는 사용 방법을 익히는 데에 의의를 두기는 했지만, "나중에는 이렇게 사용하면 더 좋겠다."라는 생각이 들어서 정리를 해두려고 한다.

• 기획 단계에서 Milestone과 Kanban board를 유기적으로 활용할 것
  • 전체적인 그림에서 Milestone을 먼저 큰 목표 단위로 만들고, Milestone을 쪼개서 Kanban board 티켓을 만들면 더 체계적으로 활용할 수 있을 듯 하다. 이번에는 뭐가 뭔지 몰라서 헤매다가 Kanban board를 먼저 만들고, 마지막에 Milestone을 만들었는데 순서가 이렇게 되면 작은 단위 작업에 맞춰서 큰 단위 작업을 생각하게 되므로 합리적이지 못한 것 같다.
• 티켓의 우선순위 설정
  • backlog에 있는 티켓들을 쭉 보면서 처음에 실현 가능한 티켓들을 ToDo로 옮기는 작업을 기획 단계에서 했어야 했다. 팀 프로젝트가 처음이어서 그런지 백엔드분들의 티켓들과 유기적으로 생각해서 프로젝트의 이상적인 순서나 중요도를 파악하는 것이 쉽지 않았던 것 같다. 이번 pre-project에서 프로젝트 순서에 대한 감을 좀 잡고, main 프로젝트에서는 티켓의 우선순위와 순서를 기획단계에서 잘 정하고 더 체계적으로 갈 수 있을 것 같다.