Skip to content

Home

Jump to bottom
KIM MIN JEONG edited this page Feb 22, 2022 · 13 revisions

Rules

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

Issue

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

Commit

  • 커밋 시 최소 단위로 쪼개서 커밋합니다. 여러 수정사항이 한 커밋에 담기지 않도록 합니다.
  • 보편적인 커밋 컨벤션에 맞도록 메세지를 작성합니다. (search keyword: 커밋 컨벤션)
  • 의미없는 커밋 혹은 다른 개발자가 알아들을 수 없는 커밋은 적지 않습니다.

Branch

  • main : 실제 배포중인 브랜치입니다. develop 브랜치가 서비스 가능한 레벨에 도달했을때 main에 머지합니다.
  • develop : 개발 브랜치입니다. 개발 중 병합을 위해 사용합니다.
  • 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}
  • hotfix : 크리티컬한 오류 수정 시 사용합니다. pr에서 1명만 approve 해도 바로 머지할 수 있습니다.
  • 브랜치 생성 시 중복되는 커밋이 발생하지 않도록 현재 브랜치를 확인합니다.
  • 한 브랜치에서는 한 기능만 개발하도록 합니다. 여러가지 기능이 중복 될 경우 해당 브랜치의 목적성이 흐려집니다.

Pull request

  • pr 생성 시 연결된 issue를 링크합니다. (글에 resolve #이슈번호 이런식으로 하면 바로 연결됩니다. 버튼 안눌러도 됨.)
  • 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 브랜치는 1명으로도 merge 가능하도록 합니다.
  • Merge는 해당 pr의 assignee가 하도록 합니다. 만약 📌 항목에 해당하는 경우라면 base 브랜치를 develop에 머지하는 작업도 같이 수행합니다.
  • 리뷰가 달린 후 리뷰내용을 반영하여 수정했다면, 해당 comment에 수정사항이 반영된 커밋 id를 남겨줍니다. (그냥 해당 커밋 id만 댓글로 치면 알아서 링크로 달립니다.)
  • 리뷰 내용을 반영하여 수정하였다면, 다시 리뷰를 요청합니다. 라벨은 Inreivew로 변경.

내가 리뷰어라면

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

❗ 머지할 때

image

그냥 머지 버튼 누르지 말고 옵션을 선택합시다.

  1. develop(or stage) → main : create a merge commit 옵션 사용 : merge commit이 남는다. main 브랜치에는 merge 시점이 필요하니 해당 전략을 사용한다. 기존에는 이 전략을 모든 브랜치에 사용해서 커밋 히스토리 곳곳에 머지 커밋이 자주 나타났다.

  2. feat or fix → develop: squash and merge 옵션 사용 : PR의 커밋 로그를 하나로 묶을 수 있다. 원자적인 커밋 또는 PR 기능과 전혀 상관 없는 커밋 로그(ex. 콘솔 로그 제거)를 하나로 합쳐서 의미 있는 커밋 로그만 남긴다. PR 제목이 커밋 로그가 된다.

  3. develop → feat or fix: rebase and merge 옵션 사용 : merge commit이 남지 않는다. develop 브랜치를 내 브랜치로 pull할 때 사용해 쓸데 없는 merge commit을 남기지 않는다. 주로 개발하다가 develop이 업데이트 되면 실행하면 된다. 터미널에서 사용할 때는 해당 브랜치에서 git rebase develop 이런식으로 사용하면 됨. 이 경우는 PR X

출처


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

Clone this wiki locally