깃 관리 규칙

[x-0o0]

개요

작업 흐름 순서에 따라 규칙을 나열했습니다. 협업을 위한 규칙이므로 꼭 준수해주시길 부탁드립니다. 디테일한 사항은 플랫폼 내에서 변경하셔도 좋습니다.

Branch

하나의 브랜치는 반드시 하나의 작업만을 해야합니다.

예를 들어 하나의 브랜치에서 버그 수정, 기능 추가가 동시에 들어가서는 안됩니다. 다양한 버그 수정도 한 브랜치에서 진행해서는 안됩니다.

새로운 브랜치는 Merge 하려는 브랜치를 베이스로 생성해야합니다.

main 에서 나온 브랜치는 다시 main으로 merge 해야하며, develop에서 나온 브랜치는 반드시 다시 develop 브랜치로 merge 되어야합니다. 새로운 브랜치 생성시 반드시 merge 할 브랜치에서 생성해야합니다.

브랜치 네이밍은 이 브랜치가 무엇에 대한 작업인지 명확하게 해야합니다.

네이밍 룰은 플랫폼 간에 상이할 수 있습니다. (iOS 기준: {작업종류}/{작업자이름}/{작업내용})

예시 1) bugfix/jaesung/sending-feedback (피드백 전송 관련 버그 수정 브랜치)

예시 2) feature/jaesung/feedback (피드백 기능 작업에 대한 브랜치)

예시 3) feature/jaesung/image-feedback (이미지 타입의 피드백 전송에 대한 작업 브랜치)

예시 4) release/1.0.0 (1.0.0 버전 배포 브랜치)

브랜치 관리 전략 (Branch management strategy)를 반드시 준수해야합니다.

각 플랫폼은 브랜치 관리 전략을 채택하고 이를 반드시 준수해야합니다.

브랜치 관리 전략 종류는 다음과 같습니다:

• 깃 플로우 (Git-flow)
• 트렁크 기반 관리 (Trunk Based Development)
• 깃랩 플로우 (GitLab flow)
• 깃헙 플로우 (GitHub flow)

한국어로 된 관리전략간 비교글은 여기를 참고해주세요.

Commit

커밋내용을 명확하게 작성해야합니다.

커밋은 작업 기록을 남기는 것이므로 그 기록을 찾아볼 수 있게 커밋내용을 가급적 명확하게 작성해야합니다.

예시 1) [추가] 피드백 전송 버튼 추가

예시 2) [수정] 전송 버튼 높이값 수정

예시 3) [제거] 전송 실패 화면 제거

Pull Request

1개의 작업 = 1개의 브랜치 = 1개의 PR

PR은 오직 하나의 작업에 대해서 요청해주세요.

300줄 이상 넘기지 말아야합니다

너무 많은 변화량은 코드 리뷰가 어려우며 그 퀄리티도 급격히 떨어져 로직의 문제점이나 각 종 버그들을 놓치기 쉽습니다. 요청하는 리뷰의 변화량은 200줄 이내를 권장하며 가급적 300줄을 넘기지 않아야 합니다. 300줄을 넘길 것 같은 경우 현재 브랜치에 추가로 브랜치를 생성하여 쪼개서 PR을 요청해주세요.

PR 제목을 명확하게 작성해야합니다.

PR 제목을 명확하게 작성하여 무엇에 대한 작업인지 알 수 있도록 해야합니다. (iOS 기준: [작업한버전] {작업내용})

예시 1) [1.0.0] 피드백 기능 추가