팀 내 Contribution Rule 설정을 위한 참고서

서론

본 글은 팀 내 컨트리뷰션 룰 세팅을 위해 필자가 사이드 프로젝트에서 작성했던 글이다.

컨트리뷰션 룰 관련 세팅은 상당히 팀원들과 대화를 많이 해야하는 부분이다.

다른 분들도 본 글을 참고해서 팀원들과 협의한 다음, 함께 룰 세팅하시길 바란다.

 

Branch Rules

기본적으로 Git-flow를 따라가고 있어요.

하지만, 너무 여러 브랜치가 난립하는 걸 막기 위해서 기본적으로 세 종류의 브랜치를 운영하고 있다고 생각하면 좋을 꺼 같아요

• main : 이 브랜치는 실제로 서버 Release를 위해 사용되고 있는 브랜치입니다. 실제 배포는 이 브랜치에 MR이 발생하면서 일어나요.
• develop : 이 브랜치는 서버를 미리 배포해볼 수 있는 브랜치입니다. 실제 배포 전에 이 브랜치에서 확인할 수 있고, 해당 브랜치에 개발한 내역들이 쌓여요.
• feature : 우리는 특징이 되는 기능이라면 feature를 사용하고 있어요. 만약 단순한 수정이라면 fix 를, 심각한 버그라면 hotfix를, 기능은 똑같지만 코드 구조를 개선했다면 refac 을, 문서를 수정한 것이라면 docs 를 쓰는 방식으로 브랜치 이름 앞에 prefix를 사용하고 있어요 example) feature/cookie-update, refac/cookie-update

우린 Git-flow를 사용하고 있어요 - 우아한형제들 기술 블로그

우린 Git-flow를 사용하고 있어요 - 우아한형제들 기술 블로그

 

 

Merge 관련

우리는 기본적으로 여러가지 merge 전략을 쓰고 있고, 모든 merge를 Github의 Pull requests를 통해 진행하고 있어요.

Pull Request를 생성하면 알아서 CI 툴을 통해 빌드 및 테스트 과정도 거친답니다.

아래는 각 브랜치 별 머지 전략이에요.

• main ← develop : 이 경우에는 Merge commit을 남기는 방법으로 작업하고 있어요. 전체적인 커밋 이력이 남는게 릴리즈 관련 작업 내역을 볼 수 있기 때문에 main에 더 적합하다고 생각했기 때문입니다. 물론 태그를 쓰는 방향도 존재했지만, 팀원들의 git 숙련도로 인해 그냥 간단한 방법을 채택했습니다. 또한 main에 배포된 것을 복구하고 싶을 때는 revert를 통해 재배포하는 방법을 쓰고 있어요 (물론 급하게 배포를 수정해야 할 때는, ElasticBeanstalk에서 직접하고 있답니다.. 또륵)
• develop ← feature : 이 경우에는 Squash Commit을 남기는 방법으로 작업하고 있어요. Squash는 작업 이력을 깔끔하게 한 커밋으로 만들어주는 효과가 있어요. develop에는 구체적인 모든 사항을 깔끔하게 정리해서 올리는 것이 맞다고 판단했기 때문에 Squash 커밋을 사용하고 있습니다.

만약 conflict가 발생했다면, git rebase를 사용하는 것을 선호하고 있어요.

🎢 Git Rebase 활용하기

🎢 Git Rebase 활용하기

 

시간이 된다면 이 글도 읽어보면 좋아요! (하지만 —force 옵션은 어떤 이슈가 생길지 모르기 때문에 최대한 지양하고 있어요!)

Git rebase와 친해지기 (git conflict를 해결하는 방법 & upstream에서 rebase하기)

Git rebase와 친해지기 (git conflict를 해결하는 방법 & upstream에서 rebase하기)

 

PR 포맷 관련 글은

2분 59초 안에 좋은 PR 작성하기

2분 59초 안에 좋은 PR 작성하기

 

Commit Rules

Commit은 기본적으로 이렇게 작성하고 있어요.

`커밋 종류`: `커밋의 타이틀` `커밋 내역` ... example) feature: cookie update 기능 추가 해당 커밋은 쿠키를 업데이트 하는 기능을 추가하였다. 메소드는 PATCH를 사용하게 하였다. put말고 patch를 선택한 이유는 전체를 업데이트 하는 것이 아니라 필드 일부를 업데이트하기 때문에 RESTful API에 따라 PATCH가 더 의미를 가진다고 생각했다.

 

No commit -m!

일단 commit -m을 사용하는 것은 비교적 지양해주세요.

구체적인 메시지와 상황을 써주는 게 좋습니다.

 

No commit -n!

pre-commit hook(커밋을 하기 전에 체크하는 로직을 돌릴 수 있는 기능)을 걸어놨기 때문에,

type-check가 안 된다거나 등의 이슈가 있으면 커밋이 안될 수 있어요.

이럴 때, commit -n을 사용하면 그냥 커밋을 날릴 수 있는데

이 방법은 아주 위험하기 때문에!!(빌드가 안될 수도 있거든요ㅠㅠ) 사용하지 말아주세요.

 

Please Micro commit!

이왕이면 commit을 잘게 쪼개서 작성해주세요.

내역과 메시지를 잘 나눠두면,

코드를 작성한 사람이 어떤 의식의 흐름으로 작성했는지 리뷰어가 쉽게 파악할 수 있어요.

그렇기 때문에 commit을 최대한 작게 쪼개서 작성해주세요!