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가 How to Write a Git Commit Message에서 설명한 이유로 아래 가이드라인을 따라야 합니다:

• 커밋 제목과 본문은 빈 줄로 구분되어야 합니다.

• 커밋 제목은 대문자로 시작해야 합니다.

• 커밋 제목은 72자를 초과하면 안 됩니다.

• 커밋 제목은 마침표로 끝나면 안 됩니다.

• 커밋 본문의 각 줄은 72자를 초과하면 안 됩니다.

• 커밋 제목이나 본문에 이모지를 포함하면 안 됩니다.

• 최소 3개 파일에 걸쳐 30줄 이상을 변경하는 커밋은 커밋 본문에 해당 변경 사항을 설명해야 합니다.

• GitLab 외부에서는 일반 텍스트로 표시되므로, 이슈, 마일스톤, 머지 리퀘스트의 짧은 참조 대신 전체 URL을 사용하세요.

• 머지 리퀘스트에는 10개 이상의 커밋 메시지가 포함되면 안 됩니다.

• 커밋 제목은 최소 3개의 단어를 포함해야 합니다.

중요 참고 사항:

• 가이드라인을 충족하지 않으면, MR이 Danger 검사를 통과하지 못할 수 있습니다.

• 머지 리퀘스트에 "Applied suggestion to X files" 커밋이 포함된 경우, Danger가 해당 커밋을 무시할 수 있도록 스쿼시 후 병합 활성화를 고려하세요.

• [prefix] 및 prefix: 형태의 접두사는 허용됩니다(메시지 자체가 대문자로 시작하는 한 소문자여도 됩니다). 예를 들어, danger: Improve Danger behavior와 [API] Improve the labels endpoint는 유효한 커밋 메시지입니다.

이러한 표준이 중요한 이유#

• 이러한 가이드라인을 따르는 일관된 커밋 메시지는 기록을 더 읽기 쉽게 만듭니다.

• 간결한 표준 커밋 메시지는 두 시점 사이의 커밋을 검토할 때 주요 변경 사항이나 ~"master:broken" 상황을 더 빠르게 파악하는 데 도움이 됩니다.

커밋 메시지 템플릿#

위 내용을 구현한 머신에서 사용할 수 있는 커밋 메시지 템플릿 예시입니다 (템플릿 적용 방법 가이드):

# (If applied, this commit will...) <subject>        (Max 72 characters)
# |<----          Using a Maximum Of 72 Characters                ---->|

# Explain why this change is being made
# |<----   Try To Limit Each Line to a Maximum Of 72 Characters   ---->|

# Provide links or keys to any relevant tickets, articles or other resources
# Use issues and merge requests' full URLs instead of short references,
# as they are displayed as plain text outside of GitLab

# --- COMMIT END ---
# --------------------
# Remember to
#    Capitalize the subject line
#    Use the imperative mood in the subject line
#    Do not end the subject line with a period
#    Subject must contain at least 3 words
#    Separate subject from body with a blank line
#    Commits that change 30 or more lines across at least 3 files should
#    describe these changes in the commit body
#    Do not use Emojis
#    Use the body to explain what and why vs. how
#    Can use multiple lines with "-" for bullet points in body
#    For more information: https://cbea.ms/git-commit/
# --------------------

기여 수락 기준#

머지 리퀘스트가 승인될 수 있도록 아래의 기여 수락 기준을 충족하는지 확인하세요:

• 변경 사항은 최대한 작아야 합니다.

• 머지 리퀘스트에 500개 이상의 변경 사항이 포함된 경우:

이유를 설명하세요.

• 메인테이너를 언급하세요.

• 주요 주요 변경 사항을 언급하세요.

• 적절한 테스트를 포함하고 모든 테스트가 통과되도록 하세요(기존 코드의 버그를 노출하는 테스트가 포함된 경우 제외). 모든 새로운 클래스는 기능 테스트와 같이 더 높은 수준에서 테스트되더라도 해당하는 단위 테스트가 있어야 합니다.

실패한 CI 빌드가 기여와 관련이 없어 보이는 경우, 실패한 CI job을 다시 시작하거나, 업데이트를 가져오기 위해 타깃 브랜치 위에 리베이스하거나, 아직 수정되지 않은 경우 개발자에게 테스트 수정을 도와달라고 요청할 수 있습니다.

• MR에는 논리적으로 구성된 소수의 커밋이 포함되어 있거나, 커밋 스쿼시가 활성화되어 있어야 합니다.

• 변경 사항이 문제 없이 병합될 수 있어야 합니다. 그렇지 않은 경우, 기능 브랜치에서 혼자 작업 중이라면 리베이스하고, 그렇지 않으면 기본 브랜치를 MR 브랜치에 병합하세요.

• 특정 이슈 하나만 수정하거나 특정 기능 하나만 구현합니다. 내용을 합치지 말고, 각 이슈나 기능에 대해 별도의 머지 리퀘스트를 보내세요.

• 마이그레이션은 실패 시 재시도를 용이하게 하기 위해 하나의 작업만 수행해야 합니다 (예: 테이블 생성, 새 테이블로 데이터 이동, 또는 이전 테이블 삭제).

• 다른 사용자가 혜택을 받을 수 있는 기능을 포함합니다.

• 향후 변경 사항을 만들고 테스트하는 것을 복잡하게 만들기 때문에 구성 옵션이나 설정 옵션을 추가하지 않습니다.

• 변경 사항이 성능을 저하시키지 않아야 합니다:

상당한 오버헤드가 필요한 엔드포인트의 반복적인 폴링을 피하세요.

• SQL 로그 또는 QueryRecorder를 통해 N+1 쿼리를 확인하세요.

• 파일 시스템에 반복적으로 액세스하는 것을 피하세요.

• 실시간 기능을 지원하기 위해 필요한 경우 ETag 캐싱을 이용한 폴링을 사용하세요.

• 머지 리퀘스트에 새 라이브러리(예: gem 또는 JavaScript 라이브러리)가 추가된 경우, 라이선스 가이드라인을 준수해야 합니다. "license-finder" 테스트가 Dependencies that need approval 오류로 실패하는 경우 해당 지침에서 도움을 받으세요. 또한, 리뷰어에게 새 라이브러리에 대해 알리고 필요한 이유를 설명하세요.

• 머지 리퀘스트는 아래의 GitLab 완료 정의를 충족해야 합니다.

완료 정의#

GitLab에 기여하는 경우, 변경 사항은 단순히 코드 이상을 포함한다는 것을 알아두세요. 다음 완료 정의를 사용합니다. 완료 정의에 도달하려면 머지 리퀘스트가 회귀를 발생시키지 않고 다음 기준을 모두 충족해야 합니다:

• GitLab.com 프로덕션에서 작동 확인됨.

• GitLab Self-Managed / Dedicated 인스턴스에서 작동 확인됨.

• 자체 서비스 프레임워크를 통해 Geo를 지원하는 것으로 확인됨. 자세한 내용은 Geo는 완료 정의의 요구 사항을 참고하세요.

• GitLab.com에 영향을 미치는 변경 사항의 경우 Cells 아키텍처와 호환되는 것으로 확인됨. 다음을 확인하세요:

컴퓨팅(웹 요청, Sidekiq 워커)은 단일 조직으로 범위가 지정되어야 합니다.

• 고객에 속한 새 데이터베이스 행에는 샤딩 키가 있어야 합니다.

• 조직 외부에 새로운 고객 소유 리소스가 존재하면 안 됩니다.

• 조직 데이터는 다른 셀로 마이그레이션 가능해야 합니다.

자세한 내용은 Cells 개발 원칙을 참고하세요.

회귀가 발생하면 변경 사항을 되돌리는 것을 선호합니다. 이러한 모든 요구 사항을 충족했는지 확인할 때까지 기여는 완료되지 않습니다.

기능#

• 필요한 곳에 주석이 달린 작동하고 깔끔한 코드.

• 변경 사항은 광범위한 작업의 영향을 제한하도록 평가됩니다.

• 성능 가이드라인을 따랐습니다.

• 보안 코딩 가이드라인을 따랐습니다.

• 애플리케이션 및 속도 제한 가이드라인을 따랐습니다.

• /doc 디렉터리에 문서화되었습니다.

• MR이 셸 명령을 실행하거나 파일을 읽거나 열거나 디스크의 파일 경로를 처리하는 코드를 포함하는 경우, 셸 명령 가이드라인을 준수하는지 확인하세요.

• 코드 변경 사항에는 관찰 가능성 계측이 포함되어야 합니다.

• 코드에서 파일 스토리지를 처리해야 하는 경우, 업로드 문서를 참고하세요.

• 머지 리퀘스트에 하나 이상의 마이그레이션이 추가된 경우, MR이 검토되기 전에 새로운 데이터베이스에서 모든 마이그레이션을 실행하세요. 검토로 인해 MR에 대규모 변경 사항이 생긴 경우, 검토가 완료된 후 마이그레이션을 다시 실행하세요.

• 머지 리퀘스트가 기존 모델에 새 유효성 검사를 추가하는 경우, 데이터 처리가 하위 호환 가능한지 확인하기 위해:

변경 사항이 기존 행에 영향을 미치지 않는지 확인하기 위해 기존 행을 검사하는 데이터베이스 쿼리를 실행하는 도움을 받으려면 #database Slack 채널에 문의하세요.

• 롤아웃 단계에 따라 점진적으로 롤아웃될 기능 플래그와 함께 필요한 유효성 검사를 추가하세요.

이 머지 리퀘스트가 긴급한 경우, 코드 소유자는 기존 행 검토가 머지 리퀘스트의 즉각적인 후속 작업으로 포함되어야 하는지 최종 결정을 내려야 합니다.

GitLab Self-Managed 인스턴스에서 고객 데이터에 대해 알 수 있는 방법이 없으므로, 머지 리퀘스트의 데이터 영향에 대해 그 점을 염두에 두세요.

• Self-Managed 기능과 업그레이드 경로를 고려하세요. 변경 사항은 다음 두 가지를 모두 고려해야 합니다:

• Self-Managed 가용성을 위해 추가 작업이 필요한 경우, 그리고

• GitLab 버전 업그레이드 시 필수 정지가 필요한 경우.

  업그레이드 정지는 GitLab 코드 변경이 백그라운드 마이그레이션이 이미 완료되어 있는 것에 의존하는 경우 때때로 요청됩니다. 이상적으로는, 필수 업그레이드 정지를 발생시키는 변경 사항은 다음 주요 릴리즈까지 보류하거나, 불가피한 경우 최소 3개 마일스톤 전에 사전 고지해야 합니다.

테스팅#

• CI 서버에서 모두 통과하는 단위, 통합 및 시스템 테스트.

• 변경 위험이 높은 경우 동료 멤버 테스팅은 선택 사항이지만 권장됩니다. 여기에는 변경 사항이 광범위한 경우 또는 보안에 중요한 컴포넌트인 경우가 포함됩니다.

• 회귀 및 버그는 이슈가 다시 발생하는 위험을 줄이는 테스트로 커버됩니다.

• Capybara를 사용하는 테스트의 경우, 신뢰할 수 있는 비동기 통합 테스트 작성 방법을 읽어보세요.

• 필요한 경우 블랙박스 테스트/엔드-투-엔드 테스트가 추가됩니다. 질문이 있으면 품질 팀에 문의하세요.

• 가능하고 적절한 경우 리뷰 앱에서 변경 사항을 테스트합니다.

• 기능 플래그의 영향을 받는 코드는 기능 플래그가 활성화되고 비활성화된 자동화 테스트로 커버되거나, 두 상태 모두 동료 멤버 테스팅 또는 롤아웃 계획의 일부로 테스트됩니다.

• 머지 리퀘스트에 하나 이상의 마이그레이션이 추가된 경우, 더 복잡한 마이그레이션에 대한 테스트를 작성하세요.

UI 변경 사항#

• GitLab 디자인 시스템인 Pajamas에서 사용 가능한 컴포넌트를 사용하세요.

• MR에 UI 변경 사항이 있는 경우 "이전"과 "이후" 스크린샷이 포함되어야 합니다.

• MR이 CSS 클래스를 변경하는 경우, grep css-class ./app -R을 실행하여 찾을 수 있는 영향을 받는 페이지 목록을 포함하세요.

변경 사항 설명#

• 기여의 관련성을 설명하는 명확한 제목과 설명.

• 설명에는 리뷰어가 변경 사항을 볼 수 있도록 필요한 단계나 설정이 포함됩니다(예: 기능 플래그에 관한 정보 포함).

• 필요한 경우 체인지로그 항목 추가.

• 머지 리퀘스트가 GitLab을 직접 컴파일할 때 추가 단계가 필요한 변경 사항을 도입하는 경우, 동일한 머지 리퀘스트에서 doc/install/self_compiled/_index.md에 추가하세요.

• 머지 리퀘스트가 소스에서 GitLab을 업그레이드할 때 추가 단계가 필요한 변경 사항을 도입하는 경우, 동일한 머지 리퀘스트에서 doc/update/upgrading_from_source.md에 추가하세요. 이러한 지침이 특정 버전에 해당하는 경우, "버전별 업그레이드 지침" 섹션에 추가하세요.

승인#

• MR이 MR 수락 체크리스트에 대해 평가되었습니다.

• 기여가 기본 설정을 변경하거나 새 설정을 도입하는 경우, 해당되는 경우 인프라 부서에 알리기 위해 인프라 이슈 트래커에 이슈를 생성하세요.

• 합의된 롤아웃 계획.

• 관련 리뷰어에 의해 검토되었으며, 가용성, 회귀 및 보안에 관한 모든 우려 사항이 해결되었습니다. 문서 검토는 가능한 빨리 이루어져야 하지만 머지 리퀘스트를 차단해서는 안 됩니다.

• 머지 리퀘스트에는 최소 1개의 승인이 있어야 하지만, 변경 사항에 따라 추가 승인이 필요할 수 있습니다. 승인 가이드라인을 참고하세요.

특정 승인자를 선택할 필요는 없지만, 특정 사람이 머지 리퀘스트를 승인하기를 원한다면 선택할 수 있습니다.

• 프로젝트 메인테이너에 의해 병합됩니다.

프로덕션 사용#

다음 항목은 머지 리퀘스트가 병합된 후 확인됩니다:

• 가능한 경우 프로덕션에서 변경 사항을 구현하기 전에 스테이징에서 작동하는 것을 확인했습니다.

• 기여가 배포된 후 새로운 Sentry 오류 없이 프로덕션에서 작동하는 것을 확인했습니다.

• 롤아웃 계획이 완료되었음을 확인했습니다.

• 변경 사항에 성능 위험이 있는 경우, 변경 전후의 시스템 성능을 분석했습니다.

• 머지 리퀘스트가 기능 플래그, 프로젝트별 또는 그룹별 활성화, 단계적 롤아웃을 사용하는 경우:

GitLab 프로젝트에서 작동하는 것을 확인했습니다.

• 추가된 모든 프로젝트에 대해 각 단계에서 작동하는 것을 확인했습니다.

• 해당하는 경우 릴리즈 포스트에 추가됩니다.

• 해당하는 경우 웹사이트에 추가됩니다.

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

의존성#

GitLab에 의존성을 추가하는 경우(예: 운영 체제 패키지), 다음을 업데이트하는 것을 고려하고 머지 리퀘스트에서 각각의 적용 가능성을 기록하세요:

• 릴리즈 블로그 포스트에 추가 내용을 기록하세요 (아직 없는 경우 생성).

• 업그레이드 가이드.

• GitLab 설치 가이드.

• GitLab Development Kit.

• CI 환경 준비.

• Linux 패키지 크리에이터.

• Cloud Native GitLab Dockerfiles

점진적 개선#

이슈가 있거나 없더라도 다음과 같은 점진적 개선인 소규모 문제를 수정하는 엔지니어링 시간을 허용합니다:

• 우선순위가 낮은 버그 수정 (예: Banner alerting of project move is showing up everywhere)

• 문서 개선

• RuboCop 또는 코드 품질 개선

이 영역의 작업을 추적하려면 머지 리퀘스트에 ~"Stuff that should Just Work" 태그를 붙이세요.

관련 주제#

• 머지 리퀘스트 작성자의 책임

• 머지 리퀘스트 검토 받기