병합 요청 워크플로우

모든 분들의 병합 요청을 환영합니다. GitLab 코드, 테스트 및 문서에 대한 수정 및 개선을 포함합니다.

커뮤니티 기여에 특별히 적합한 문제는 Seeking community contributions 레이블이 붙어 있지만, 원하는 모든 문제에 기여할 수 있습니다.

문제에서 작업하기

문제를 찾으면 해결책이나 개선 사항을 포함한 병합 요청을 제출하세요,

가능하다면 테스트도 포함하세요.

라벨이 없는 새로운 기능을 추가하고 싶다면, 먼저 문제를 생성하는 것이 가장 좋습니다(아직 없을 경우) 그리고 이를 Seeking community contributions로 라벨링해 달라고 댓글을 남기세요. 기능 제안 섹션을 참조하세요.

문제를 해결하는 방법을 모른다면, 문제를 노출하는 테스트를 작성할 수 있습니다. 우리는 그것도 수용합니다. 일반적으로 회귀 테스트를 포함한 버그 수정은 빠르게 병합됩니다. 적절한 테스트가 없는 새로운 기능은 피드백을 받는 속도가 느릴 수 있습니다.

GitLab 개발(또는 일반 웹 개발)에 익숙하지 않다면, 기여하는 방법 섹션을 참조하세요. 시작하기에 적합한 간단한 문제들이 있을 수 있습니다.

병합 요청 소유권

문제가 현재 마일스톤으로 표시되면, 심지어 여러분이 작업 중일 때도, GitLab 팀원이 병합 요청을 인수하여 출시일 전에 작업이 완료되도록 할 수 있습니다.

기여자가 제출된 병합 요청에서 더 이상 활성 작업을 하지 않으면, 우리는 다음과 같은 결정을 내릴 수 있습니다:

병합 요청은 우리의 병합 요청 코치 중 한 사람이 마무리합니다.
병합 요청을 닫습니다.

우리는 이 결정을 제품 비전에 대한 변경의 중요성에 따라 내립니다. 병합 요청 코치가 병합 요청을 마무리할 경우, ~coach will finish 레이블을 지정합니다.

팀원이 커뮤니티 기여를 인수할 경우, 원 저자에게 기여를 인정하는 변경 로그 항목을 추가하여 원 저자에게 크레딧을 부여하고 선택적으로 MR 내의 커밋 중 하나에 원 저자를 포함합니다.

기여자를 위한 병합 요청 지침

기여 프로세스에 대한 자세한 내용은 튜토리얼: GitLab 기여하기를 참조하세요.

모범 사례

변경 사항이 사소하지 않을 경우, 제품 관리자 또는 팀 구성원과 논의를 시작하는 것을 권장합니다. 코드 검토를 위해 제출하기 전에 MR에 태그를 달아 이들과 대화할 수 있습니다. 팀 구성원과의 대화는 디자인 결정을 내리는 데 도움이 될 수 있습니다. 변경 사항 뒤에 있는 의도를 전달하는 것도 병합 요청 리뷰를 신속하게 처리하는 데 도움이 될 수 있습니다.
프로덕션 가용성에 영향을 미칠 수 있다고 생각되면, 기능 플래그 뒤에 코드를 배치하는 것을 고려하세요. 확실하지 않다면 기능 플래그를 사용할 때를 읽어보세요.
병합 요청에 대한 빠른 피드백을 원하시면 코어 팀이나 병합 요청 코치 중 한 명을 언급하세요. 코드 검토 시 및 병합 요청을 검토할 때는 코드 리뷰 지침을 염두에 두세요. 코드가 데이터베이스를 변경하거나 비용이 많이 드는 쿼리를 실행하는 경우, 데이터베이스 리뷰 지침을 확인하세요.

간단하게 유지하기

작은 반복으로 살기. 단일 MR의 변경 사항 수를 가능한 한 작게 유지하세요.

큰 기능을 기여하고 싶다면, 최소 가치 있는 변화가 무엇인지 매우 신중하게 고려하세요.

기능을 두 개의 더 작은 MR로 나눌 수 있나요?

백엔드/API 코드만 제출할 수 있나요?

매우 간단한 UI로 시작할 수 있나요?

리팩터의 일부만 수행할 수 있나요?

작은 MR들은 더 쉽게 검토할 수 있으며, 이는 GitLab에게 최소 커밋 로그를 갖는 것보다 더 중요한 높은 코드 품질로 이어집니다. MR이 작을수록 더 빨리 병합될 가능성이 높습니다. 그 후 더 많은 MR을 보내어 기능을 향상시키고 확장할 수 있습니다. Kubernetes 팀의 더 빠른 PR 리뷰를 받는 방법 문서에도 이에 대한 훌륭한 포인트가 있습니다.

커밋 메시지 가이드라인

커밋 메시지는 Chris Beams가 Git 커밋 메시지를 작성하는 방법에서 설명한 이유에 따라 아래 가이드라인을 따라야 합니다:

커밋 주제와 본문은 빈 줄로 구분해야 합니다.
커밋 주제는 대문자로 시작해야 합니다.
커밋 주제는 72자를 초과해서는 안 됩니다.
커밋 주제는 마침표로 끝나지 않아야 합니다.
커밋 본문은 줄당 72자를 초과해선 안 됩니다.
커밋 주제나 본문에는 이모지를 포함하면 안 됩니다.
30줄 이상의 변경이 있고 최소 3개의 파일에서 변경이 있을 경우, 커밋 본문에서 이러한 변경을 설명해야 합니다.
짧은 참조 대신 이슈, 마일스톤 및 머지 요청의 전체 URL을 사용해야 하며, 이는 GitLab 외부에서 일반 텍스트로 표시됩니다.
머지 요청에는 10개 이상의 커밋 메시지가 포함되어서는 안 됩니다.
커밋 주제는 최소 3개의 단어를 포함해야 합니다.

중요한 노트:

가이드라인이 충족되지 않으면 MR이 Danger 체크를 통과하지 못할 수 있습니다.
“Applied suggestion to X files” 커밋이 포함된 경우 Squash and merge를 활성화하는 것을 고려하세요. 그렇게 하면 Danger가 이러한 커밋을 무시할 수 있습니다.
[prefix] 및 prefix: 형식의 접두사는 허용됩니다 (메시지 자체가 대문자일 경우 소문자로 쓸 수 있습니다). 예를 들어, danger: Improve Danger behavior 및 [API] Improve the labels endpoint는 유효한 커밋 메시지입니다.

이러한 기준이 중요한 이유

이러한 가이드라인을 따르는 일관된 커밋 메시지는 기록을 더 읽기 쉽게 만듭니다.
간결한 표준 커밋 메시지는 배포를 위한 중단된 변경 사항을 더 빠르게 식별하는 데 도움이 됩니다.

커밋 메시지 템플릿

위의 내용을 담은 예시 커밋 메시지 템플릿으로, 당신의 머신에서 사용할 수 있습니다 (템플릿 적용 방법에 대한 가이드: 커밋 메시지에 유용한 템플릿):

# (적용 시, 이 커밋은...) <주제>        (최대 72자)
# |<----          최대 72자 사용               ---->|


# 이 변경이 이루어진 이유를 설명하세요
# |<----   각 줄을 최대 72자로 제한하려고 노력하세요   ---->|

# 관련된 티켓, 문서 또는 기타 리소스에 대한 링크나 키를 제공하세요
# 짧은 참조 대신 이슈와 머지 요청의 전체 URL을 사용하세요,
# 이는 GitLab 외부에서 일반 텍스트로 표시됩니다.

# --- 커밋 끝 ---
# --------------------
# 기억하세요
#    주제 줄을 대문자로 시작하세요
#    주제 줄에서는 명령문 사용
#    주제 줄을 마침표로 끝내지 마세요
#    주제는 최소 3개의 단어를 포함해야 합니다
#    주제와 본문은 빈 줄로 구분하세요
#    30줄 이상의 변경이 있고 최소 3개 파일에서 변경이 있을 경우
#    커밋 본문에서 이러한 변경을 설명하세요
#    이모지를 사용하지 마세요
#    본문에서 무엇과 왜를 설명하고 방법은 제외하세요
#    본문에서 글머리 기호로 '-'를 여러 줄로 사용할 수 있습니다
#    추가 정보는: https://cbea.ms/git-commit/
# --------------------

기여 수락 기준

귀하의 병합 요청이 승인될 수 있도록 하려면 아래의 기여 수락 기준을 충족하는지 확인하세요:

변경 사항은 가능한 한 작아야 합니다.
병합 요청에 500개 이상의 변경이 포함된 경우:
- 이유를 설명하세요.
- 유지 관리자를 언급하세요.
주요 파괴적 변경 사항을 언급하세요.
적절한 테스트를 포함하고 모든 테스트가 통과해야 합니다(기존 코드의 버그를 드러내는 테스트가 포함된 경우 제외). 모든 새 클래스는 해당 단위 테스트가 있어야 하며, 클래스가 기능 테스트와 같은 더 높은 수준에서 실행되는 경우에도 마찬가지입니다.
- 실패하는 CI 빌드가 귀하의 기여와 관련이 없는 것 같다면, 실패한 CI 작업을 다시 시작하거나, 업데이트를 가져오기 위해 대상 브랜치 위에 리베이스하거나, 아직 수정되지 않은 경우 개발자에게 테스트 수정을 요청할 수 있습니다.
MR에는 몇 개의 논리적으로 구성된 커밋이 포함되어 있거나 스쿼시 커밋이 활성화되어 있습니다.
변경 사항이 문제 없이 병합될 수 있어야 합니다. 만약 그렇지 않다면, 기능 브랜치에서 본인만 작업하는 경우 리베이스를 하거나, 그렇지 않다면 기본 브랜치를 MR 브랜치로 병합해야 합니다.
하나의 특정 문제만 수정되거나 하나의 특정 기능만 구현되어야 합니다. 여러 가지를 결합하지 말고 각 문제나 기능에 대해 별도의 병합 요청을 보내세요.
마이그레이션은 하나의 작업만 수행해야 합니다(예: 테이블 생성, 데이터를 새로운 테이블로 이동, 오래된 테이블 제거)하여 실패 시 재시도가 용이하도록 해야 합니다.
다른 사용자가 이점을 누릴 수 있는 기능이 포함되어야 합니다.
구성을 복잡하게 하고 향후 변경 사항을 테스트하기 어렵게 만들기 때문에 설정 옵션이나 구성 옵션을 추가하지 마세요.
변경 사항이 성능을 저하시켜서는 안 됩니다:
- 상당한 오버헤드가 필요한 엔드포인트에 대한 반복적인 폴링을 피하세요.
- SQL 로그 또는 QueryRecorder에서 N+1 쿼리를 확인하세요.
- 파일 시스템에 대한 반복적 접근을 피하세요.
- 실시간 기능을 지원해야 하는 경우 필요한 경우 ETag 캐싱을 이용한 폴링을 사용하세요.
병합 요청이 새로운 라이브러리(예: gems 또는 JavaScript 라이브러리)를 추가하는 경우, 이들은 우리의 라이선스 가이드라인을 준수해야 합니다. “license-finder” 테스트가 Dependencies that need approval 오류와 함께 실패할 경우 도움을 받으세요. 또한, 리뷰어에게 새로운 라이브러리에 대해 알리고 그 필요성을 설명하세요.
병합 요청이 GitLab의 완료 정의를 충족해야 합니다.

완료 정의

GitLab에 기여하는 경우, 변경 사항은 단순한 코드 이상의 것을 포함한다는 점을 알아두세요. 우리는 다음의 완료 정의를 사용합니다. 완료 정의를 달성하려면 병합 요청이 회귀를 일으키지 않아야 하며 모든 기준을 충족해야 합니다:

GitLab.com에서 프로덕션에서 작동하는 것이 확인되었습니다.
자기 관리 인스턴스에서 작동하는 것이 확인되었습니다.
셀프 서비스 프레임워크를 통해 Geo를 지원하는 것이 확인되었습니다. 자세한 내용은 Geo는 완료 정의의 요구 사항입니다를 참조하세요.

회귀가 발생하는 경우, 변경 사항을 되돌리는 것을 선호합니다.

귀하의 기여는 이러한 모든 요구 사항을 충족할 때까지 미완료입니다.

기능

필요한 부분에 주석이 달린 작동 및 깨끗한 코드입니다.
변경 사항은 광범위한 작업의 영향을 제한하기 위해 평가됩니다.
성능 지침을 준수했습니다.
보안 코딩 지침을 준수했습니다.
애플리케이션 및 비율 제한 지침을 준수했습니다.
/doc 디렉토리에 문서화되었습니다.
MR이 셸 명령을 실행하거나 파일을 읽거나 여는 코드에 영향을 미친다면 셸 명령 지침을 준수하는지 확인하세요.
코드 변경 사항에는 가시성 도구가 포함되어야 합니다.
코드가 파일 저장을 처리해야 하는 경우 업로드 문서를 참조하세요.
만약 병합 요청이 하나 이상의 마이그레이션을 추가하면, MR 검토 전에 새 데이터베이스에서 모든 마이그레이션을 실행해야 합니다. 검토로 인해 MR에 큰 변경이 있다면, 검토가 완료된 후 다시 마이그레이션을 실행하세요.
병합 요청이 기존 모델에 새로운 유효성 검사를 추가한다면, 데이터 처리가 하위 호환성을 유지하는지 확인하기 위해:
- #database Slack 채널에 문의하여 기존 행에 영향을 미치지 않는지 확인하는 데이터베이스 쿼리를 실행하는데 도움을 요청하세요.
- 필요한 유효성 검사를 기능 플래그와 함께 추가하여 배포 단계를 따라 점진적으로 배포하세요.
이 병합 요청이 긴급한 경우 코드 소유자는 기존 행 검토가 병합 요청의 즉각적인 후속 작업으로 포함되어야 하는지에 대한 최종 결정을 내려야 합니다.

참고: 고객의 데이터가 셀프 관리 인스턴스에서 어떤 것인지 알 수 있는 방법이 없으므로, 병합 요청과 관련된 데이터의 영향을 고려하세요.
셀프 관리 기능 및 업그레이드 경로를 고려하세요. 변경 사항은 다음 두 가지를 모두 고려해야 합니다:
- 셀프 관리 가능성을 위한 추가 작업이 필요한지,
- GitLab 버전을 업그레이드할 때 필수 중단이 필요한지.
업그레이드 중단은 가끔 GitLab 코드 변경이 이미 완료된 백그라운드 마이그레이션에 의존할 때 요청됩니다. 이상적으로는, 필수 업그레이드 중단을 유발하는 변경 사항은 다음 주요 릴리즈까지 보류해야 하며, 불가피한 경우에는 최소 3 milestone 전에 공지해야 합니다.

테스트

모든 CI 서버에서 통과하는 단위, 통합 및 시스템 테스트.
변경 위험이 클 경우 동료 멤버 테스트는 선택 사항이지만 권장됩니다. 여기에는 광범위한 변경이나 보안에 중요한 구성요소를 위한 경우가 포함됩니다.
회귀 및 버그는 문제 발생 위험을 줄이는 테스트로 확인됩니다.
Capybara를 사용하는 테스트의 경우, 신뢰할 수 있는 비동기 통합 테스트 작성 방법을 읽어보세요.
블랙 박스 테스트/엔드 투 엔드 테스트가 필요한 경우 추가합니다. 질문이 있는 경우 품질 팀에 문의하세요.
가능한 경우, 적절할 경우 검토 앱에서 변경 사항을 테스트합니다.
기능 플래그에 영향을 받는 코드는 자동화된 테스트로 기능 플래그가 활성화되고 비활성화된 상태에서 테스트되거나, 두 상태 모두가 동료 멤버 테스트의 일환으로 또는 배포 계획의 일환으로 테스트됩니다.
병합 요청이 하나 이상의 마이그레이션을 추가하는 경우, 더 복잡한 마이그레이션에 대한 테스트를 작성합니다.

UI 변경 사항

GitLab 디자인 시스템의 사용 가능한 구성 요소를 사용합니다, Pajamas.
UI 변경이 이루어지면 MR에는 Before 및 After 스크린샷이 포함되어야 합니다.
MR이 CSS 클래스를 변경하는 경우 grep css-class ./app -R을 실행하여 찾을 수 있는 영향을 받는 페이지 목록을 포함해야 합니다.

변경 사항 설명

기여의 관련성을 설명하는 명확한 제목과 설명을 작성합니다.
설명에는 리뷰어가 변경 사항을 확인할 수 있도록 보장하는 데 필요한 단계나 설정이 포함되어야 합니다(예: 기능 플래그에 대한 정보 포함).
필요한 경우, Changelog 항목 추가.
병합 요청이 GitLab을 소스에서 설치할 때 추가 단계가 필요한 변경 사항을 도입하는 경우, 동일한 병합 요청의 doc/install/installation.md에 추가합니다.
병합 요청이 GitLab을 소스에서 업그레이드하는 경우 추가 단계가 필요한 변경 사항을 도입하는 경우, 동일한 병합 요청의 doc/update/upgrading_from_source.md에 추가합니다. 이러한 지침이 특정 버전과 관련된 경우 “버전별 업그레이드 지침” 섹션에 추가합니다.

승인

MR은 MR 수용 체크리스트에 대해 평가되었습니다.
기여가 기본 설정을 변경하거나 새로운 설정을 도입하는 경우, 인프라 부서에 알리기 위해 인프라 문제 추적기에 문제를 생성합니다, 필요한 경우.
합의된 배포 계획이 있습니다.
관련 리뷰어의 검토를 받았으며, 가용성, 회귀 및 보안에 대한 모든 우려 사항이 해결되었습니다. 문서 검토는 가능한 한 빨리 이루어져야 하지만 병합 요청을 차단해서는 안 됩니다.
병합 요청에는 최소 1개의 승인이 있지만, 변경 사항에 따라 추가 승인이 필요할 수 있습니다. 승인 가이드라인을 참조하세요.
- 특정 승인자를 선택할 필요는 없지만, 특정 사람들이 병합 요청을 승인하기를 원하면 선택할 수 있습니다.
프로젝트 유지 관리자가 병합했습니다.

프로덕션 사용

병합 요청이 병합된 후 다음 항목이 확인됩니다:

가능할 경우 프로덕션에서 변경 사항을 구현하기 전에 스테이징에서 작동하는지 확인했습니다.
기여가 배포된 후 새로운 Sentry 오류 없이 프로덕션에서 작동하는지 확인했습니다.
배포 계획이 완료되었음을 확인했습니다.
변경 사항에 성능 위험이 있는 경우 변경 전후의 성능을 분석했습니다.
병합 요청이 기능 플래그, 프로젝트별 또는 그룹별 활성화, 그리고 단계적 롤아웃을 사용하는 경우:
- GitLab 프로젝트에서 작동하는지 확인했습니다.
- 추가된 모든 프로젝트에 대해 각 단계에서 작동하는지 확인했습니다.
관련된 경우, 릴리즈 게시물에 추가했습니다.
관련된 경우, 웹사이트에 추가했습니다.

기여는 제품 팀 의 승인을 요구하지 않습니다.

의존성

GitLab에 의존성을 추가할 경우(운영 체제 패키지와 같은),

다음 사항을 업데이트하는 것을 고려하고, 각 사항의 적합성을 병합 요청에 명시하십시오:

릴리즈 블로그 포스트에 추가 사항을 기록하세요. (아직 존재하지 않는 경우 하나를 생성합니다).
업그레이드 가이드.
GitLab 설치 가이드.
GitLab 개발 키트.
CI 환경 준비.
Omnibus 패키지 생성기.
Cloud Native GitLab Dockerfiles

점진적 개선

우리는 작은 문제를 수정하기 위해 엔지니어링 시간을 허용합니다(문제가 있든 없든), 이러한 점진적 개선 사항은 다음과 같습니다:

우선 순위가 지정되지 않은 버그 수정(예: 프로젝트 이동에 대한 배너 경고가 모든 곳에 표시되고 있습니다)
문서 개선
RuboCop 또는 코드 품질 개선

~"작동해야 할 내용" 태그를 사용하여 이 범위의 작업을 추적하십시오.