Home

다들 어느정도 컨벤션은 지키는 것 같지만~ 이제 유지보수하기로 했으니 좀 더 체계적으로 해 보아요 😀
이 글은 현재 repository에서 사용하는 rule만을 적어두었습니다.
여러 정보가 얻고 싶다면 적절한 키워드로 검색하면 더 많은 글을 볼 수 있습니다.
사실 다른 협업 관리 툴들을 사용하게 되면 이런 작업들이 편해지지만,, 좀 불편하더라도 추가하는 것이 어떤가 하여 글 남겨봅니다.
수정사항이나 의견 받습니다 🤝 

Issue

• 이슈 생성시 github project에 연결하고 상태를 추가합니다.
• 이슈는 최소의 단위로 나눠서 추가합니다. (같은 큰 맥락의 기능일경우 {main-issue}-{sub-issue1}, {main-issue}-{sub-issue2} 식으로 명명하는 것도 좋습니다.)
• 라벨을 활용합니다.

Commit

• 커밋 시 최소 단위로 쪼개서 커밋합니다. 여러 단위의 수정사항이 한 커밋에 담기지 않도록 합니다.
• 보편적인 커밋 컨벤션에 맞도록 메세지를 작성합니다. (search keyword: 커밋 컨벤션)

Branch

• develop : 개발 브랜치입니다. 따로 master는 두지 않았기 때문에 본 브랜치가 master입니다.
• feature : 기능 개발시 사용합니다. 이슈 넘버를 트래킹하여 번호를 붙이기도 합니다. ex) feature/{issue-number}-{feature-name} 만약 한 기능에 대해 여러개의 작은 이슈가 포함되는 경우라면 feature/{main-issue} 브랜치를 생성 후, feature/{main-issue}/{issue-number}-{sub-issue} 브랜치에서 개발 한 후 feature/{main-issue} 에 Pr을 올려 병합하며, 이후 main issue가 완료되었을 때 develop 브랜치에 병합하는 방식으로 활용할 수 있습니다. 이 경우 한 sub issue에 대해 여러명이 작업을 동시에 진행할 수 있다는 장점이 있습니다.
• bug : 버그 수정시 사용합니다. 이슈 넘버를 트래킹하여 번호를 붙이기도 합니다. ex) bug/{issue-number}-{name}
• 브랜치 생성 시 중복되는 커밋이 발생하지 않도록 현재 브랜치를 확인합니다.
• 한 브랜치에서는 한 기능만 개발하도록 합니다. 여러가지 기능이 중복 될 경우 해당 브랜치의 목적성이 흐려집니다.

Pull request

• 하나의 pr은 하나의 이슈만 담당하도록 합니다. (위의 브랜치에서의 목적과 동일)
• 만약 main issue - sub issue 로 이루어 진 브랜치라면 base 브랜치를 feature/{main-issue} 로 하도록 합니다. 이때, 해당 pr이 머지되고 난 후 base 브랜치(feature/{main-issue}의 기능 개발이 완료되는 상황이라면, 이후 해당 브랜치를 develop에 머지해야 함을 명시합니다. (라벨로 표현해도 좋습니다.) 📌
• 라벨을 활용합니다. (라벨을 여러개 추가해 놓을테니 자세한 라벨 설명을 읽어주길 바랍니다)
• pr을 올린 브랜치를 수정중이라면 상태를 명시하도록 합니다.
• 코드리뷰시 netlify preview를 활용합니다. 변경사항을 직접 눈으로 확인 해 볼 수 있습니다.
• 두명의 approve를 받고 netlify build를 통과할 시에 해당 base branch에 Merge 할 수 있습니다.
• Merge는 해당 pr의 assignee가 하도록 합니다. 만약 📌 항목에 해당하는 경우라면 base 브랜치를 develop에 머지하는 작업도 같이 수행합니다.
• 리뷰가 달린 후 리뷰내용을 반영하여 수정했다면, 해당 comment에 수정사항이 반영된 커밋 id를 남겨줍니다. (그냥 id만 댓글로 치면 알아서 링크로 달립니다.)

> 만약 project에서 트래킹이 안되는 issue가 있다면.. 관리해줍시다 이슈 우러욥 😢