머지 리퀘스트 워크플로

GitLab에 코드, 테스트, 문서를 기여하기 위한 머지 리퀘스트 워크플로와 기여 수락 기준 및 완료 정의를 설명합니다.

GitLab 코드, 테스트, 문서에 대한 수정과 개선이 담긴 머지 리퀘스트는 누구에게나 환영합니다. 커뮤니티 기여에 특히 적합한 이슈에는 다음 Seeking community contributions 레이블이 붙어 있지만, 원하는 어떤 이슈에든 기여할 수 있습니다. 이슈 기반 작업 # 이슈를 발견했다면 가능한 범위에서 수정이나 개선을 담은 머지 리퀘스트를 제출하고, 테스트를 포함합니다. 레이블이 없는 새 기능을 추가하고 싶다면, 먼저 이슈를 만들고(이미 있다면 생략) Seeking community contributions 레이블을 붙여 달라는 댓글을 남기는 편이 좋습니다. 기능 제안 절을 참고합니다. 이슈를 고치는 방법은 모르지만 그 이슈를 드러내는 테스트를 작성할 수 있다면, 그것도 환영합니다. 일반적으로 회귀 테스트가 포함된 버그 수정은 빠르게 머지됩니다. 적절한 테스트가 없는 새 기능은 피드백을 받기까지 더 오래 걸릴 수 있습니다. GitLab 개발(또는 웹 개발 전반)이 처음이라면 기여 방법 절을 참고해 비교적 쉬운 이슈부터 시작합니다. 머지 리퀘스트 소유권 # 이슈가 현재 마일스톤으로 지정되면, 그 이슈를 작업하는 중이더라도 릴리스 날짜 전에 작업이 끝나도록 GitLab 팀원이 해당 머지 리퀘스트를 넘겨받을 수 있습니다. 제출된 머지 리퀘스트에 기여자가 더 이상 적극적으로 참여하지 않으면 GitLab은 다음과 같이 대응할 수 있습니다. 머지 리퀘스트 코치 중 한 명이 해당 머지 리퀘스트를 마무리하도록 결정합니다. 머지 리퀘스트를 닫습니다. 이 결정은 해당 변경이 GitLab 제품 비전에서 얼마나 중요한지를 기준으로 합니다. 머지 리퀘스트 코치가 머지 리퀘스트를 마무리하는 경우에는 ~coach will finish 레이블을 붙입니다. 팀원이 커뮤니티 기여를 이어받는 경우, 원저자를 명시한 변경 로그 항목을 추가해 기여를 밝히고, 필요하면 MR의 커밋 중 최소 하나에 원저자를 포함합니다. 기여자를 위한 머지 리퀘스트 가이드라인 # 기여 절차를 처음부터 살펴보려면 튜토리얼: GitLab에 기여하기 를 참고합니다. 모범 사례 # 변경이 사소하지 않다면 제품 관리자나 팀 구성원 과 논의를 시작하는 것을 권장합니다. 코드를 리뷰에 올리기 전에 MR에서 해당 인원을 태그하면 됩니다. 설계를 결정할 때 팀원과 이야기하면 도움이 됩니다. 변경의 의도를 함께 전달하면 머지 리퀘스트 리뷰도 빨라집니다. 프로덕션 가용성에 영향을 줄 수 있다고 판단되면 코드를 기능 플래그 뒤에 두는 방안을 검토합니다. 판단이 서지 않는다면 기능 플래그를 사용하는 시점 을 참고합니다. 머지 리퀘스트에 대해 빠른 피드백을 받고 싶다면 코어 팀 구성원이나 머지 리퀘스트 코치 를 멘션해도 됩니다. 코드를 리뷰받을 때와 머지 리퀘스트를 리뷰할 때는 코드 리뷰 가이드라인 을 염두에 둡니다. 코드가 데이터베이스를 변경하거나 비용이 큰 쿼리를 실행한다면 데이터베이스 리뷰 가이드라인 도 확인합니다. 단순하게 유지 # 작은 단위로 반복합니다. 하나의 MR에 담기는 변경량을 최대한 작