혼자 개발하다가 여러명이서 개발할때 정해야할 깃 규칙

혼자서 개발하다가 마이그레이션을 하면서 4명이서 함께 개발하다보니 정해야할 규칙들이 많았다.
혼자서도 git-flow 전략에 따라 하고 있었는데 충돌나도 혼자 해결하면 되니까 크게 문제될 일이 없었다.
하지만 4명이서 한 프로젝트를 쓰다보니 정말 일주일에 1~2번씩은 충돌 에러가 나는 것이다.

가장 골머리 앓았던 문제는 평소처럼 merge 했는데 수정하지 않은 파일이 변경되거나 추가/삭제 되는 경우가 있었다.
다같이 고민을 해보았는데, 이건 예전부터 뭔가 git history가 꼬여있어서 생긴 이슈라고 판단했고, 깔끔한 버젼을 새로 파서 거기에서 새롭게 시작하기로 했다.

하루에 1000번 배포하는 조직 되기 등 여러 글들을 참고하여 우리 팀은 Pull Request를 베이스로 하는 규칙을 정했다.

기본적인 브랜치 전략은 git-flow 전략을 따르고, commit에는 gitmoji를 활용하고 티켓 넘버를 명시하여 작업이 명확하게 드러날 수 있도록 하였다.

가장 상위 티켓과 연결되는 이슈를 만들어서 연관된 PR은 한번에 볼 수 있도록 했고,
모든 머지는 Pull Request를 통해서 하고, develop 브랜치는 프로텍션 룰을 설정하여 직접적으로 push를 할 수 없게 하였다.
Github Actions에 경험이 있는 팀원이 PR 을 올리면 슬랙에 자동 알람이 오게 만들어주었고, 한 명 이상의 리뷰어의 Approve를 받아야 머지할 수 있도록 하였다.

위 처럼 여러 이야기를 나눈 다음 더 이상 코멘트 달 내용이 없으면 그때 Approve를 요청하여 머지할 수 있게 했다.

처음에 다른 팀원 분들이 왔을때 내가 혼자 열심히 해온 코드를 평가 받는 느낌이 들어 어딘가 부끄러운 감정이 들었다. 이것도 고쳐야하고 저것도 고쳐야한다고 할 때, 당시 상황엔 어쩔 수 없었다는 말을 계속 하게 되는 것이다.
그냥 혼자 한다고 할까 생각도 해봤지만, 만약에 그랬으면 이런 소중한 경험을 할 수 없었을 것이다.
요샌 정말 next stage 문이 열린 느낌이다. 왜냐면, 다시 예전처럼 너무 부족하다는 느낌을 받고있기 때문이다.

기쁜 마음으로 열심히 공부해야지!