Home

Rules

다들 어느정도 컨벤션은 지키는 것 같지만~ 이제 유지보수하기로 했으니 좀 더 체계적으로 해 보아요 😀
이 글은 현재 repository에서 사용하는 rule만을 적어두었습니다.
여러 정보가 얻고 싶다면 적절한 키워드로 검색하면 더 많은 글을 볼 수 있습니다.
사실 다른 협업 관리 툴들을 사용하면 편하겠지만, 배우는 단계에서 좀 불편하더라도 규칙을 적용하는게 어떨까 해서 남겨봅니다.
(본문에 서술한 방식 이외에도 다양한 방식이 있습니다.
서치하다보면 효율적인 pr방법이나 브랜치 관리방법등에 대해 배울 수 있어요.)
수정사항이나 의견 받습니다. 🤝 

Issue

• 이슈 생성시 github project에 연결하고 상태를 추가합니다. (중요 ❗ ) 기능개발의 경우 Feature Todo, 버그는 BugFix Todo로..
• 이슈는 최소의 단위로 나눠서 추가합니다. (같은 큰 맥락의 기능일경우 {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 생성 시 연결된 issue를 링크합니다.
• assignee와 reviewer를 추가합니다. 리뷰를 요청할 경우 In review 라벨을 달도록 합니다.
• 라벨을 활용합니다. (라벨을 여러개 추가해 놓을테니 자세한 라벨 설명을 읽어주길 바랍니다.)
• 하나의 pr은 하나의 이슈만 담당하도록 합니다. (위의 브랜치에서의 목적과 동일)
• 만약 main issue - sub issue 로 이루어 진 브랜치라면 base 브랜치를 feature/{main-issue} 로 하도록 합니다. 이때, 해당 pr이 머지되고 난 후 base 브랜치(feature/{main-issue}의 기능 개발이 완료되는 상황이라면, 이후 해당 브랜치를 develop에 머지해야 함을 명시합니다. (라벨로 표현해도 좋습니다.) 📌
• pr을 올린 브랜치를 수정중이라면 상태를 명시하도록 합니다. (developing 라벨)
• 코드리뷰시 netlify preview를 활용합니다. 변경사항을 직접 눈으로 확인 해 볼 수 있습니다.
• 2명의 approve를 받고 netlify build를 통과할 시에 해당 base branch에 Merge 할 수 있습니다. (본인이 리뷰어일때, 내 리뷰로 인해 기준이 통과되는 경우, merge needed 라벨을 달아서 표현해주도록 합시다.)
• 단, 급한 버그 수정(hotfix) 혹은 간단한 수정(simple)의 경우 1명의 approve로도 merge 하도록 합니다.
• Merge는 해당 pr의 assignee가 하도록 합니다. 만약 📌 항목에 해당하는 경우라면 base 브랜치를 develop에 머지하는 작업도 같이 수행합니다.
• 리뷰가 달린 후 리뷰내용을 반영하여 수정했다면, 해당 comment에 수정사항이 반영된 커밋 id를 남겨줍니다. (그냥 해당 커밋 id만 댓글로 치면 알아서 링크로 달립니다.)
• 리뷰 내용을 반영하여 수정하였다면, 다시 리뷰를 요청합니다. 라벨은 Inreivew로 변경.

내가 리뷰어라면

• 리뷰를 달 line을 잘 선택하여 달아줍니다. 해당 코드가 수정되었을 때 자연스럽게 삭제될 부분에 리뷰를 달게되면, outdate 라는 라벨이 comment에 붙게 된답니다

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