GitLab 이슈를 사용하면 작업을 추적하고 팀과 협업할 수 있습니다. 이슈 관리로 다음을 수행할 수 있습니다.

• 제목, 설명, 담당자, 메타데이터 등 세부 정보를 편집합니다.
• 컨텍스트와 히스토리를 유지하면서 프로젝트 간에 이슈를 이동합니다.
• 완료된 이슈를 닫고 필요하면 다시 엽니다.
• 일괄 편집으로 여러 이슈를 효율적으로 업데이트합니다.
• 이슈 헬스 상태를 추적하여 진행 상황을 모니터링하고 위험을 식별합니다.

이슈의 하위 항목 관리에 대한 자세한 내용은 하위 항목을 참고합니다.

이슈 편집#

히스토리

• 이슈를 편집하는 데 필요한 최소 권한이 GitLab 17.7에서 Reporter에서 Planner로 변경되었습니다.

이슈의 제목과 설명을 편집할 수 있습니다.

사전 요구 사항:

• 프로젝트에 대한 Planner, Reporter, Developer, Maintainer, Owner 권한이 있거나 이슈 작성자이거나 이슈에 할당되어 있어야 합니다.

이슈를 편집하려면 다음과 같이 합니다.

1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Plan > Work items를 선택한 다음 Type = Issue로 필터링하고 이슈를 선택합니다.
3. 제목 오른쪽에서 Edit를 선택합니다.
4. 사용 가능한 필드를 편집합니다.
5. Save changes를 선택합니다.

Issue Description Generation으로 이슈 채우기#

Model information

• 기본 LLM: Anthropic Claude Sonnet 4.6
• GitLab Duo self-hosted 모델에서는 사용할 수 없습니다.

히스토리

• GitLab 16.3에서 experiment로 도입되었습니다.
• GitLab 17.6부터 GitLab Duo 애드온이 필요하도록 변경되었습니다.
• GitLab 18.0에서 Premium을 포함하도록 변경되었습니다.

제공하는 짧은 요약을 기반으로 이슈에 대한 상세 설명을 생성합니다.

개요 보기

사전 요구 사항:

• experiment 및 beta 기능 설정이 켜져 있는 그룹에 하나 이상 속해 있어야 합니다.
• 이슈 생성 권한이 있어야 합니다.
• 일반 텍스트 편집기에서만 사용할 수 있습니다.
• 새 이슈를 생성할 때만 사용할 수 있습니다. 기존 이슈를 편집할 때 설명 생성을 지원하는 기능 추가 제안은 issue 474141을 참고합니다.

이슈 설명을 생성하려면 다음과 같이 합니다.

1. 새 이슈를 생성합니다.
2. Description 텍스트 상자 위에서 GitLab Duo ([tanuki-ai]) > Generate issue description을 선택합니다.
3. 짧은 설명을 작성하고 Submit을 선택합니다.

이슈 설명이 AI가 생성한 텍스트로 교체됩니다.

이 experimental 기능에 대한 피드백은 issue 409844에 남깁니다.

데이터 사용: 이 기능을 사용하면 입력한 텍스트가 대규모 언어 모델로 전송됩니다.

이슈 일괄 편집#

히스토리

• 이슈를 일괄 편집하는 데 필요한 최소 권한이 GitLab 17.7에서 Reporter에서 Planner로 변경되었습니다.
• GitLab 18.7에서 일괄 편집 속성이 더 추가되었습니다.

그룹 또는 프로젝트에서 여러 이슈를 한 번에 편집할 수 있습니다.

사전 요구 사항:

• 그룹 또는 프로젝트에 대한 Planner, Reporter, Developer, Maintainer, Owner 권한이 있어야 합니다.

여러 이슈를 한 번에 편집하려면 다음과 같이 합니다.

1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Plan > Work items를 선택한 다음 Type = Issue로 필터링합니다.
3. Bulk edit를 선택합니다. 오른쪽에 편집 가능한 필드가 있는 사이드바가 나타납니다.
4. 편집할 각 이슈 옆의 체크박스를 선택합니다.
5. 사이드바에서 사용 가능한 필드를 편집합니다.
6. Update selected를 선택합니다.

이슈를 일괄 편집할 때 다음 속성을 편집할 수 있습니다.

• State (open 또는 closed)
• Status
• Assignees
• Labels
• Health status
• Notification 구독
• Confidentiality
• Iteration
• Milestone
• 상위 항목
• 다른 프로젝트로 이동

이슈 이동#

히스토리

• 이슈를 이동하는 데 필요한 최소 권한이 GitLab 17.7에서 Reporter에서 Planner로 변경되었습니다.

이슈를 이동하면 이슈가 닫히고 대상 프로젝트로 복사됩니다. 원본 이슈는 삭제되지 않습니다. 이슈가 어디서 왔고 어디로 갔는지 나타내는 시스템 노트가 두 이슈 모두에 추가됩니다.

GitLab은 이슈 설명이나 댓글에 첨부된 파일도 대상 프로젝트로 복사합니다. 업로드한 파일은 프로젝트 단위로 범위가 지정되므로, GitLab은 대상 프로젝트에서 각 복사본에 새 URL 시크릿을 부여해 생성합니다.

• 원본 첨부 파일 URL에 직접 접속하면 404 오류가 반환됩니다.
• 복사된 파일은 원본 프로젝트가 아니라 대상 프로젝트의 마크다운 업로드에 나열됩니다.

액세스 규칙이 다른 프로젝트로 이슈를 이동할 때는 주의합니다. 이슈를 이동하기 전에 민감한 데이터가 포함되어 있지 않은지 확인합니다.

사전 요구 사항:

• 프로젝트에 대한 Planner, Reporter, Developer, Maintainer, Owner 권한이 있어야 합니다.

이슈를 이동하려면 다음과 같이 합니다.

1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Plan > Work items를 선택한 다음 Type = Issue로 필터링하고 이슈를 선택합니다.
3. 오른쪽 상단 모서리에서 More actions (⋮) > Move를 선택합니다.
4. 이슈를 이동할 프로젝트를 검색합니다.
5. Move를 선택합니다.

댓글 또는 설명에서 /move 빠른 작업을 사용할 수도 있습니다.

이슈 일괄 이동#

히스토리

• 이슈를 일괄 이동하는 데 필요한 최소 권한이 GitLab 17.7에서 Reporter에서 Planner로 변경되었습니다.

Work items 목록에서#

프로젝트에서 여러 이슈를 한 번에 이동할 수 있습니다. 태스크 또는 테스트 케이스는 이동할 수 없습니다.

사전 요구 사항:

• 프로젝트에 대한 Planner, Reporter, Developer, Maintainer, Owner 권한이 있어야 합니다.

여러 이슈를 한 번에 이동하려면 다음과 같이 합니다.

1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Plan > Work items를 선택한 다음 Type = Issue로 필터링합니다.
3. Bulk edit를 선택합니다. 오른쪽에 편집 가능한 필드가 있는 사이드바가 나타납니다.
4. 이동할 각 이슈 옆의 체크박스를 선택합니다.
5. Move 드롭다운 목록에서 대상 프로젝트를 선택합니다.
6. Move items를 선택합니다.

Rails 콘솔에서#

한 프로젝트의 모든 open 이슈를 다른 프로젝트로 이동할 수 있습니다.

사전 요구 사항:

• GitLab 인스턴스의 Rails 콘솔에 액세스할 수 있어야 합니다.

수행 방법은 다음과 같습니다.

1. 선택 사항(권장). 콘솔에서 변경을 시도하기 전에 백업을 생성합니다.

2. Rails 콘솔을 엽니다.

3. 다음 스크립트를 실행합니다. project, admin_user, target_project를 실제 값으로 변경해야 합니다.

   project = Project.find_by_full_path('full path of the project where issues are moved from')
   issues = project.issues
   admin_user = User.find_by_username('username of admin user') # make sure user has permissions to move the issues
   target_project = Project.find_by_full_path('full path of target project where issues moved to')
   
   issues.each do |issue|
      if issue.state != "closed" && issue.moved_to.nil?
         Issues::MoveService.new(container: project, current_user: admin_user).execute(issue, target_project)
      else
         puts "issue with id: #{issue.id} and title: #{issue.title} was not moved"
      end
   end; nil
   

4. Rails 콘솔을 종료하려면 quit을 입력합니다.

설명 목록 및 태스크 목록#

이슈 설명에서 순서가 있는 목록, 순서가 없는 목록, 또는 태스크 목록을 사용할 때 다음을 수행할 수 있습니다.

• 드래그 앤 드롭으로 모든 목록 항목의 순서를 바꿉니다.
• 태스크 목록 항목을 삭제합니다.
• 태스크 목록 항목을 태스크 작업 항목으로 변환합니다.

태스크 목록 항목 삭제#

사전 요구 사항:

• 프로젝트에 대한 Reporter, Developer, Maintainer, Owner 권한이 있거나 이슈의 작성자 또는 담당자여야 합니다.

태스크 목록 항목이 있는 이슈 설명에서 다음과 같이 합니다.

1. 태스크 목록 항목에 마우스를 올리고 옵션 메뉴 (⋮)를 선택합니다.
2. Delete를 선택합니다.

이슈 설명에서 태스크 목록 항목이 제거됩니다. 중첩된 태스크 목록 항목이 있으면 한 단계 위로 이동합니다.

이슈 설명의 목록 항목 순서 바꾸기#

히스토리

• 이슈 설명의 목록 항목 순서를 바꾸는 데 필요한 최소 권한이 GitLab 17.7에서 Reporter에서 Planner로 변경되었습니다.
• Esc로 목록 항목 드래그 작업을 취소하는 기능이 GitLab 19.3에서 도입되었습니다.

설명에 목록이 있는 이슈를 볼 때 목록 항목의 순서도 바꿀 수 있습니다.

사전 요구 사항:

• 프로젝트에 대한 Planner, Reporter, Developer, Maintainer, Owner 권한이 있거나 이슈 작성자이거나 이슈에 할당되어 있어야 합니다.
• 이슈 설명에 순서가 있는, 순서가 없는, 또는 태스크 목록이 있어야 합니다.

이슈를 보면서 목록 항목의 순서를 바꾸려면 다음과 같이 합니다.

1. 목록 항목 행에 마우스를 올려 그립 아이콘 ([grip])을 표시합니다.
2. 그립 아이콘을 선택하고 누르고 있습니다.
3. 행을 목록의 새 위치로 드래그합니다.
4. 그립 아이콘을 놓습니다.

순서 바꾸기를 취소하려면 그립 아이콘을 놓기 전에 Esc를 누릅니다.

이슈 닫기#

히스토리

• 이슈를 닫는 데 필요한 최소 권한이 GitLab 17.7에서 Reporter에서 Planner로 변경되었습니다.

이슈가 해결되었거나 더 이상 필요하지 않다고 판단되면 닫을 수 있습니다. 이슈는 닫힌 것으로 표시되지만 삭제되지는 않습니다.

사전 요구 사항:

• 프로젝트에 대한 Planner, Reporter, Developer, Maintainer, Owner 권한이 있거나 이슈 작성자이거나 이슈에 할당되어 있어야 합니다.

이슈를 닫으려면 다음 중 하나를 수행합니다.

• issue board에서 이슈 카드를 목록에서 Closed 목록으로 드래그합니다.
• GitLab UI의 다른 페이지에서 다음과 같이 합니다.
  1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.
  2. Plan > Work items를 선택한 다음 Type = Issue로 필터링하고 이슈를 선택합니다.
  3. 오른쪽 상단 모서리에서 More actions (⋮)를 선택한 다음 Close issue를 선택합니다.

댓글 또는 설명에서 /close 빠른 작업을 사용할 수도 있습니다.

닫힌 이슈 다시 열기#

히스토리

• 닫힌 이슈를 다시 여는 데 필요한 최소 권한이 GitLab 17.7에서 Reporter에서 Planner로 변경되었습니다.

사전 요구 사항:

• 프로젝트에 대한 Planner, Reporter, Developer, Maintainer, Owner 권한이 있거나 이슈 작성자이거나 이슈에 할당되어 있어야 합니다.

닫힌 이슈를 다시 열려면 오른쪽 상단 모서리에서 More actions (⋮)를 선택한 다음 Reopen issue를 선택합니다. 다시 연 이슈는 다른 open 이슈와 다르지 않습니다.

댓글 또는 설명에서 /reopen 빠른 작업을 사용할 수도 있습니다.

이슈 자동 닫기#

커밋 메시지 또는 머지 리퀘스트 설명에서 _closing pattern_이라는 특정 단어를 사용하면 이슈를 자동으로 닫을 수 있습니다. GitLab Self-Managed 관리자는 기본 closing pattern을 변경할 수 있습니다.

커밋 메시지 또는 머지 리퀘스트 설명에 closing pattern과 일치하는 텍스트가 포함되어 있으면, 일치한 텍스트에서 참조된 모든 이슈는 다음 중 하나가 발생할 때 닫힙니다.

• 커밋이 프로젝트의 default 브랜치에 push됩니다.
• 커밋 또는 머지 리퀘스트가 기본 브랜치에 머지됩니다.

예를 들어 머지 리퀘스트 설명에 Closes #4, #6, Related to #5를 포함하면 다음과 같이 동작합니다.

• 이슈 #4와 #6은 MR이 머지될 때 자동으로 닫힙니다.
• 이슈 #5는 관련 이슈로 표시되지만 자동으로 닫히지는 않습니다.

또는 이슈에서 머지 리퀘스트를 생성하면 이슈의 마일스톤과 레이블을 상속합니다.

성능상의 이유로 기존 리포지터리에서 처음 push할 때는 자동 이슈 닫기가 꺼져 있습니다.

머지 시 사용자 책임#

머지 리퀘스트를 머지할 때 대상 이슈를 닫는 것이 적절한지 확인하는 것은 사용자의 책임입니다. 사용자는 머지 리퀘스트 설명뿐 아니라 커밋 메시지 본문에도 이슈 closing pattern을 포함할 수 있습니다. 커밋 메시지의 closing 메시지는 놓치기 쉽습니다. 두 경우 모두 머지 리퀘스트 위젯에 머지 시 닫힐 이슈에 대한 정보가 표시됩니다.

머지 리퀘스트를 머지하면 GitLab은 closing pattern으로 지정된 이슈를 닫을 권한이 있는지 확인합니다. 공개 리포지터리에서는 이 확인이 중요합니다. 외부 사용자도 closing pattern을 포함한 머지 리퀘스트와 커밋을 모두 생성할 수 있기 때문입니다. 머지를 수행하는 사용자는 그 머지가 프로젝트의 코드와 이슈 양쪽에 미치는 영향을 인식하고 있어야 합니다.

closing pattern 없이도 이슈를 머지 리퀘스트에 연결할 수 있습니다. GraphQL API 또는 머지 리퀘스트의 Work items 위젯을 사용합니다. 어느 방식으로 연결하든 GitLab은 연결을 생성하는 시점에 권한을 확인하며, 머지 리퀘스트가 머지되는 시점에는 확인하지 않습니다. 이 연결은 유지되므로 이슈가 속한 프로젝트에 대한 액세스 권한을 잃어도 머지 시 이슈는 여전히 닫힙니다. 자세한 내용은 작업 항목 수동 연결을 참고합니다.

머지 리퀘스트에서 자동 머지가 켜져 있으면 자동으로 닫힐 이슈 목록을 더 이상 변경할 수 없습니다.

기본 closing pattern#

히스토리

• GitLab 17.3에서 작업 항목(태스크, 목표, 또는 핵심 결과) 참조가 도입되었습니다.

이슈를 자동으로 닫으려면 이슈 참조 앞에 다음 키워드를 사용합니다.

사용 가능한 키워드:

• Close, Closes, Closed, Closing, close, closes, closed, closing
• Fix, Fixes, Fixed, Fixing, fix, fixes, fixed, fixing
• Resolve, Resolves, Resolved, Resolving, resolve, resolves, resolved, resolving
• Implement, Implements, Implemented, Implementing, implement, implements, implemented, implementing

사용 가능한 이슈 참조 형식:

• 로컬 이슈(#123)
• 크로스 프로젝트 이슈(group/project#123)
• 이슈의 전체 URL(https://gitlab.example.com/<project_full_path>/-/issues/123)
• 작업 항목(예: 태스크, 목표, 또는 핵심 결과)의 전체 URL:
  • 프로젝트에서(https://gitlab.example.com/<project_full_path>/-/work_items/123)
  • 그룹에서(https://gitlab.example.com/groups/<group_full_path>/-/work_items/123)

예를 들면 다음과 같습니다.

Awesome commit message

Fix #20, Fixes #21 and Closes group/otherproject#22.
This commit is also related to #17 and fixes #18, #19
and https://gitlab.example.com/group/otherproject/-/issues/23.

위 커밋 메시지는 이 커밋이 push된 프로젝트에서 #18, #19, #20, #21을 닫고 group/otherproject에서 #22와 #23을 닫습니다. #17은 pattern과 일치하지 않으므로 닫히지 않습니다.

closing pattern은 여러 줄로 된 커밋 메시지나 git commit -m으로 커맨드 라인에서 작성한 한 줄짜리 커밋 메시지에서도 사용할 수 있습니다.

기본 이슈 closing pattern 정규식:

\b((?:[Cc]los(?:e[sd]?|ing)|\b[Ff]ix(?:e[sd]|ing)?|\b[Rr]esolv(?:e[sd]?|ing)|\b[Ii]mplement(?:s|ed|ing)?)(:?) +(?:(?:issues? +)?%{issue_ref}(?:(?: *,? +and +| *,? *)?)|([A-Z][A-Z0-9_]+-\d+))+)

자동 이슈 닫기 비활성화#

프로젝트 설정에서 프로젝트 단위로 자동 이슈 닫기 기능을 끌 수 있습니다.

사전 요구 사항:

• 프로젝트에 대한 Maintainer 또는 Owner 권한이 있어야 합니다.

자동 이슈 닫기를 끄려면 다음과 같이 합니다.

1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Settings > Repository를 선택합니다.
3. Branch defaults를 확장합니다.
4. Auto-close referenced issues on default branch 체크박스를 지웁니다.
5. Save changes를 선택합니다.

참조된 이슈는 계속 표시되지만 자동으로 닫히지는 않습니다.

이 설정 변경은 새 머지 리퀘스트 또는 커밋에만 적용됩니다. 이미 닫힌 이슈는 그대로 유지됩니다. 자동 이슈 닫기 끄기는 설정을 끈 프로젝트의 이슈에만 적용됩니다. 이 프로젝트의 머지 리퀘스트와 커밋은 다른 프로젝트의 이슈는 계속 닫을 수 있습니다.

이슈 closing pattern 사용자 지정#

사전 요구 사항:

• GitLab 인스턴스에 대한 관리자 액세스 권한이 있어야 합니다.

설치본의 기본 issue closing pattern을 변경하는 방법을 알아봅니다.

Read more로 설명 잘림 방지#

히스토리

• GitLab 17.10에서 도입되었습니다.

이슈 설명이 길면 GitLab은 일부만 표시합니다. 전체 설명을 보려면 Read more를 선택해야 합니다. 이 잘림 기능을 사용하면 긴 텍스트를 스크롤하지 않고도 페이지의 다른 요소를 더 쉽게 찾을 수 있습니다.

설명 잘림 여부를 변경하려면 다음과 같이 합니다.

1. 이슈에서 오른쪽 상단 모서리의 More actions (⋮)를 선택합니다.
2. 원하는 대로 Truncate descriptions를 토글합니다.

이 설정은 기억되며 모든 이슈, 태스크, 에픽, 목표, 핵심 결과에 영향을 줍니다.

오른쪽 사이드바 숨기기#

히스토리

• GitLab 17.10에서 도입되었습니다.

공간이 충분하면 이슈 속성이 설명 오른쪽의 사이드바에 표시됩니다.

사이드바를 숨기고 설명 영역을 넓히려면 다음과 같이 합니다.

1. 이슈에서 오른쪽 상단 모서리의 More actions (⋮)를 선택합니다.
2. Hide sidebar를 선택합니다.

이 설정은 기억되며 모든 이슈, 태스크, 에픽, 목표, 핵심 결과에 영향을 줍니다.

사이드바를 다시 표시하려면 다음과 같이 합니다.

• 이전 단계를 반복하고 Show sidebar를 선택합니다.

이슈 삭제#

히스토리

• 이슈를 삭제하는 데 필요한 권한이 GitLab 17.7에서 Owner에서 Owner 또는 Planner로 변경되었습니다.

사전 요구 사항:

• 프로젝트에 대한 Planner 또는 Owner 권한이 있어야 합니다.

이슈를 삭제하려면 다음과 같이 합니다.

1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Plan > Work items를 선택한 다음 Type = Issue로 필터링하고 이슈를 선택합니다.
3. 오른쪽 상단 모서리에서 More actions (⋮)를 선택합니다.
4. Delete issue를 선택합니다.

이슈 유형 변경#

히스토리

• 이슈 유형을 변경하는 데 필요한 최소 권한이 GitLab 17.7에서 Reporter에서 Planner로 변경되었습니다.
• 이슈를 핵심 결과, 목표, 태스크로 변경하는 기능이 GitLab 18.7에서 도입되었습니다.

사전 요구 사항:

• 이슈 작성자여야 하거나, 프로젝트에 대한 Planner, Reporter, Developer, Maintainer, Owner 권한이 있거나, 이슈 작성자이거나, 이슈에 할당되어 있어야 합니다.

이슈 유형을 변경하려면 다음과 같이 합니다.

1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.

2. 왼쪽 사이드바에서 Plan > Work items를 선택한 다음 Type = Issue로 필터링하고 이슈를 선택합니다.

3. 오른쪽 상단 모서리에서 More actions (⋮)를 선택합니다.

4. Change type을 선택합니다.

5. Type 드롭다운 목록에서 새 유형을 선택합니다.

   • Key result
   • Objective
   • Task
   • Epic(이슈를 상위 그룹으로 이동) 자세한 내용은 이슈를 에픽으로 승격을 참고합니다.

6. Change type을 선택합니다.

이슈를 인시던트로 승격하려면 이슈를 인시던트로 승격을 참고합니다.

이슈를 에픽으로 승격#

히스토리

• 이슈를 에픽으로 승격하는 데 필요한 최소 권한이 GitLab 17.7에서 Reporter에서 Planner로 변경되었습니다.

이슈를 직속 상위 그룹의 에픽으로 승격할 수 있습니다.

기밀 이슈를 에픽으로 승격하면 기밀 에픽이 생성되며, 기밀성이 유지됩니다.

이슈가 에픽으로 승격되면 다음과 같이 됩니다.

• 이슈가 속한 프로젝트와 같은 그룹에 에픽이 생성됩니다.
• 이슈 구독자에게 에픽이 생성되었다는 알림이 전송됩니다.

다음 이슈 메타데이터가 에픽으로 복사됩니다.

• 제목, 설명, 활동, 댓글 스레드
• 찬성 및 반대 투표
• 참여자
• 이슈가 가지고 있던 그룹 레이블
• 상위 항목

사전 요구 사항:

• 이슈가 속한 프로젝트가 그룹에 있어야 합니다.
• 프로젝트의 직속 상위 그룹에 대한 Planner, Reporter, Developer, Maintainer, Owner 권한이 있어야 합니다.
• 다음 중 하나를 충족해야 합니다.
  • 프로젝트에 대한 Planner, Reporter, Developer, Maintainer, Owner 권한이 있어야 합니다.
  • 이슈 작성자여야 합니다.
  • 이슈에 할당되어 있어야 합니다.

이슈를 에픽으로 승격하려면 다음과 같이 합니다.

1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Plan > Work items를 선택한 다음 Type = Issue로 필터링하고 이슈를 선택합니다.
3. 오른쪽 상단 모서리에서 More actions (⋮)를 선택합니다.
4. Change type을 선택합니다.
5. Type 드롭다운 목록에서 Epic을 선택합니다.
6. Change type을 선택합니다.

또는 /promote_to Epic 빠른 작업을 사용할 수 있습니다.

이슈를 인시던트로 승격#

/promote_to Incident 빠른 작업을 사용하여 이슈를 인시던트로 승격할 수 있습니다.

이슈를 이터레이션에 추가#

이슈를 이터레이션에 추가하려면 다음과 같이 합니다.

1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Plan > Work items를 선택한 다음 Type = Issue로 필터링하고 이슈를 선택합니다.
3. 오른쪽 사이드바의 Iteration 섹션에서 Edit를 선택합니다.
4. 드롭다운 목록에서 이 이슈에 추가할 이터레이션을 선택합니다.
5. 드롭다운 목록 밖의 임의 영역을 선택합니다.

이슈를 이터레이션에 추가하려면 다음도 할 수 있습니다.

• /iteration 빠른 작업 사용
• 보드의 이터레이션 목록으로 이슈 드래그
• Work items 목록에서 이슈 일괄 편집

나에게 할당된 모든 이슈 보기#

나에게 할당된 모든 이슈를 보려면 다음과 같이 합니다.

1. 상단 표시줄에서 Search or go to를 선택합니다.
2. 드롭다운 목록에서 Issues assigned to me를 선택합니다.

또는:

• 키보드 단축키를 사용하려면 Shift+i를 누릅니다.
• 오른쪽 상단 모서리에서 Assigned work items ([work-items])를 선택합니다.

이슈 목록#

이슈 목록은 프로젝트 또는 그룹의 모든 이슈를 표시합니다. 이슈를 보고, 정렬하고, 관리하는 데 사용할 수 있습니다.

이슈 목록을 보려면 다음과 같이 합니다.

1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Plan > Work items를 선택한 다음 Type = Issue로 필터링합니다.

Work items 목록에 표시할 속성을 설정하려면 표시 기본 설정 구성을 참고합니다.

이슈 목록에서 다음을 수행할 수 있습니다.

• 제목, 담당자, 레이블, 마일스톤과 같은 이슈 세부 정보를 봅니다.
• 다양한 기준으로 이슈를 정렬합니다.
• 특정 이슈를 찾기 위해 이슈를 필터링합니다.
• 이슈를 개별적으로 또는 일괄로 편집합니다.
• 새 이슈를 생성합니다.

다음 섹션에서는 이슈 목록을 다루는 방법을 설명합니다.

이슈 목록 필터링#

히스토리

• OR 필터링이 GitLab 17.0에서 일반 공개되었습니다. or_issuable_queries 기능 플래그가 제거되었습니다.
• 사용자 지정 상태 또는 상위 항목으로 이슈 목록을 필터링하는 기능이 GitLab 18.7에서 도입되었습니다.
• 생성일, 종료일, 마감일, 수정일로 필터링하는 기능이 GitLab 19.4에서 일반 공개되었습니다. issue_date_filter 기능 플래그가 제거되었습니다.

이슈 목록을 필터링하려면 다음과 같이 합니다.

1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Plan > Work items를 선택한 다음 Type = Issue로 필터링합니다.
3. 필요에 따라 추가 필터, 연산자, 값을 선택합니다. 다음 필터를 사용할 수 있습니다.
   • Assignee
   • Author
   • Closed date
   • Confidential
   • Contact
   • Created date
   • Due date
   • Health
   • Iteration
   • Label
   • Milestone
   • My reaction
   • Organization
   • Parent
   • Release
   • Search in (titles or descriptions)
   • Status
   • Subscribed
   • Type
   • Updated date
   • Weight
   • Custom fields
4. 속성을 필터링할 연산자를 선택하거나 입력합니다. 다음 연산자를 사용할 수 있습니다.
   • =: Is
   • !=: Is not one of
   • ||: Is one of (Assignee, Author, Label, Type에서 사용) 포괄적 OR처럼 동작합니다. 예를 들어 Assignee is one of Sidney Jones와 Assignee is one of Zhang Wei로 필터링하면 GitLab은 Sidney, Zhang, 또는 둘 다 담당자인 이슈를 표시합니다.
5. 속성을 필터링할 텍스트를 입력합니다. 일부 속성은 None 또는 Any로 필터링할 수 있습니다.
6. 이 과정을 반복하여 여러 속성으로 필터링합니다. 여러 속성은 논리 AND로 결합됩니다.
7. Enter를 누르거나 검색 아이콘 (🔍)을 선택합니다.

제목 또는 설명으로 필터링#

제목 또는 설명의 텍스트로 이슈 목록을 필터링하려면 다음과 같이 합니다.

1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Plan > Work items를 선택한 다음 Type = Issue로 필터링합니다.
3. 필터 바에 검색어를 입력합니다.
4. 나타나는 드롭다운 목록에서 Search for this text를 선택합니다.
5. Enter를 누르거나 검색 아이콘 (🔍)을 선택합니다.

이슈 필터링은 PostgreSQL 전문 검색을 사용하여 쿼리에 응답할 의미 있고 중요한 단어를 일치시킵니다.

예를 들어 I am securing information for M&A를 검색하면 GitLab은 제목 또는 설명에 securing, secured, 또는 information이 포함된 결과를 반환할 수 있습니다. 그러나 GitLab은 문장 전체나 I, am, M&A라는 단어를 정확히 일치시키지는 않습니다. 어휘적으로 의미 있거나 중요하다고 판단되지 않기 때문입니다. 이는 PostgreSQL 전문 검색의 제약입니다.

ID로 이슈 필터링#

1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Plan > Work items를 선택한 다음 Type = Issue로 필터링합니다.
3. 필터 바에 이슈 ID 앞에 #을 붙여 입력합니다. 예를 들어 #362255를 입력하면 이슈 362255만 반환됩니다.
4. Search for this text를 선택합니다.
5. Enter를 누르거나 검색 아이콘 (🔍)을 선택합니다.

패널에서 이슈 열기#

히스토리

• GitLab 17.4에서 issues_list_drawer라는 기능 플래그와 함께 도입되었습니다. 기본적으로 꺼져 있습니다.
• GitLab 18.6에서 일반 공개되었습니다. issues_list_drawer 기능 플래그가 제거되었습니다.

목록이나 이슈 보드에서 이슈를 선택하면 세부 정보 패널이 열립니다.

그러면 목록이나 보드의 컨텍스트를 잃지 않고도 세부 정보를 보고 편집할 수 있습니다.

패널을 사용할 때는 다음과 같습니다.

• 목록에서 이슈를 선택하면 패널에서 열립니다.
• 패널은 화면 오른쪽에 나타납니다.
• 패널에서 직접 이슈를 편집할 수 있습니다.
• 패널을 닫으려면 닫기 아이콘 (✗)을 선택하거나 Escape를 누릅니다.

전체 페이지 보기로 이슈 열기#

이슈를 전체 보기로 열려면 다음과 같이 합니다.

• 이슈를 새 탭에서 엽니다. 이슈 목록에서 다음 중 하나를 수행합니다.
  • 이슈를 마우스 오른쪽 버튼으로 클릭하고 새 브라우저 탭에서 엽니다.
  • Command 또는 Control을 누른 채로 이슈를 선택합니다.
• 이슈를 선택하고 패널에서 다음 중 하나를 수행합니다.
  • 왼쪽 상단 모서리에서 이슈 참조(예: my_project#123)를 선택합니다.
  • 오른쪽 상단 모서리에서 Open in full page ([maximize])를 선택합니다.

이슈를 항상 전체 페이지 보기로 열려면 목록 표시 기본 설정을 구성합니다.

이슈 목록의 RSS 피드 구독#

이슈 목록의 RSS 피드를 구독할 수 있습니다. 이 피드는 목록에 적용된 필터를 반영합니다.

프로젝트의 이슈 목록에 대한 RSS 피드를 구독하려면 다음과 같이 합니다.

1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Plan > Work items를 선택한 다음 Type = Issue로 필터링합니다.
3. 선택 사항: 필터를 적용합니다.
4. 오른쪽 상단 모서리에서 Actions (⋮) > Subscribe to RSS feed를 선택합니다.

그룹의 이슈 목록에 대한 RSS 피드를 구독하려면 같은 단계를 따릅니다. 상단 표시줄에서 Search or go to를 선택하고 프로젝트 대신 그룹을 찾습니다. 나에게 할당된 이슈 목록은 왼쪽 사이드바에서 Your work > Work items를 선택한 다음 같은 Actions > Subscribe to RSS feed를 사용합니다.

피드 URL에는 피드 리더로서 사용자를 인증하는 피드 토큰이 포함되어 있습니다.

이슈 참조 복사#

GitLab 다른 곳에서 이슈를 참조하려면 전체 URL이나 namespace/project-name#123 형식의 짧은 참조를 사용할 수 있습니다. 여기서 namespace는 그룹 또는 사용자 이름입니다.

이슈 참조를 클립보드에 복사하려면 다음과 같이 합니다.

1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Plan > Work items를 선택한 다음 Type = Issue로 필터링하고 이슈를 선택합니다.
3. 오른쪽 상단 모서리에서 More actions (⋮) > Copy Reference를 선택합니다.

이제 이 참조를 다른 설명이나 댓글에 붙여넣을 수 있습니다.

자세한 내용은 GitLab 특정 참조를 참고합니다.

이슈 이메일 주소 복사#

이메일을 보내서 이슈에 댓글을 생성할 수 있습니다. 이 주소로 이메일을 보내면 이메일 본문이 포함된 댓글이 생성됩니다.

이메일을 보내서 댓글을 생성하는 방법과 필요한 구성에 대한 자세한 내용은 이메일로 댓글에 답장하기를 참고합니다.

이슈의 이메일 주소를 복사하려면 다음과 같이 합니다.

1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Plan > Work items를 선택한 다음 Type = Issue로 필터링하고 이슈를 선택합니다.
3. 오른쪽 상단 모서리에서 More actions (⋮) > Copy issue email address를 선택합니다.

담당자#

이슈는 한 명 또는 여러 사용자에게 할당할 수 있습니다.

담당자는 필요할 때마다 자주 변경할 수 있습니다. 담당자는 그 이슈를 책임지는 사람이라는 의미입니다. 이슈가 누군가에게 할당되면 해당 사용자의 Assigned work items 페이지에 나타납니다.

사용자가 프로젝트 멤버가 아니면, 이슈는 사용자가 직접 생성하거나 다른 프로젝트 멤버가 할당하는 경우에만 그 사용자에게 할당될 수 있습니다.

이슈의 담당자 변경#

히스토리

• 담당자를 변경하는 데 필요한 최소 권한이 GitLab 17.7에서 Reporter에서 Planner로 변경되었습니다.

사전 요구 사항:

• 프로젝트에 대한 Planner, Reporter, Developer, Maintainer, Owner 권한이 있어야 합니다.

이슈의 담당자를 변경하려면 다음과 같이 합니다.

1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Plan > Work items를 선택한 다음 Type = Issue로 필터링하고 이슈를 선택합니다.
3. 오른쪽 사이드바의 Assignee 또는 Assignees 섹션에서 Edit를 선택합니다.
4. 드롭다운 목록에서 할당할 사용자를 선택합니다.
5. Apply를 선택하거나 드롭다운 목록 밖의 임의 영역을 선택합니다.

페이지를 새로고침하지 않아도 담당자가 변경됩니다.

유사한 이슈#

같은 주제로 이슈가 중복되는 것을 막기 위해 GitLab은 새 이슈를 생성할 때 유사한 이슈를 검색합니다.

New issue 페이지의 제목 텍스트 상자에 입력하는 동안 GitLab은 현재 프로젝트의 모든 이슈에서 제목과 설명을 검색합니다. 액세스 권한이 있는 이슈만 반환됩니다. 최근에 업데이트된 순으로 최대 5개의 유사한 이슈가 제목 텍스트 상자 아래에 표시됩니다.

헬스 상태#

계획을 지키는 데 따르는 위험을 더 잘 추적하기 위해 각 이슈에 헬스 상태를 할당할 수 있습니다. 헬스 상태를 사용하면 이슈가 계획대로 진행되고 있는지, 아니면 일정을 지키기 위해 주의가 필요한지를 조직의 다른 구성원에게 알릴 수 있습니다.

계획한 작업을 제때 완료하는 데 따르는 위험에 대응하려면 일일 스탠드업, 프로젝트 상태 보고서, 또는 주간 회의에 이슈 헬스 상태 검토를 포함합니다.

이슈의 헬스 상태 변경#

히스토리

• 헬스 상태를 변경하는 데 필요한 최소 권한이 GitLab 17.7에서 Reporter에서 Planner로 변경되었습니다.

사전 요구 사항:

• 프로젝트에 대한 Planner, Reporter, Developer, Maintainer, Owner 권한이 있어야 합니다.

이슈의 헬스 상태를 편집하려면 다음과 같이 합니다.

1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.

2. 왼쪽 사이드바에서 Plan > Work items를 선택한 다음 Type = Issue로 필터링하고 이슈를 선택합니다.

3. 오른쪽 사이드바의 Health status 섹션에서 Edit를 선택합니다.

4. 드롭다운 목록에서 이 이슈에 추가할 상태를 선택합니다.

   • On track
   • Needs attention
   • At risk

이슈의 헬스 상태는 다음에서 확인할 수 있습니다.

• Work items 목록
• 에픽의 Child items 섹션
• 이슈 보드의 이슈 카드

이슈가 닫히면 헬스 상태를 편집할 수 없으며, 이슈가 다시 열릴 때까지 Edit를 사용할 수 없습니다.

/health_status 및 /clear_health_status 빠른 작업을 사용하여 헬스 상태를 설정하고 지울 수도 있습니다.

상태#

히스토리

• GitLab 18.2에서 work_item_status_feature_flag라는 기능 플래그와 함께 도입되었습니다. 기본적으로 켜져 있습니다.
• GitLab 18.4에서 일반 공개되었습니다. work_item_status_feature_flag 기능 플래그가 제거되었습니다.

워크플로를 통한 진행 상황을 추적하기 위해 이슈에 상태를 할당할 수 있습니다. 상태 기능은 기본적인 open/closed 상태보다 더 세분화된 추적을 제공하므로 In progress, Done, Won't do와 같은 특정 단계를 사용할 수 있습니다.

사용자 지정 상태를 구성하는 방법에 대한 자세한 내용은 상태 섹션을 참고합니다.

상태 변경#

사전 요구 사항:

• 프로젝트에 대한 Planner, Reporter, Developer, Maintainer, Owner 권한이 있거나 이슈 작성자이거나 이슈에 할당되어 있어야 합니다.

이슈의 상태를 변경하려면 다음과 같이 합니다.

1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Plan > Work items를 선택한 다음 Type = Issue로 필터링하고 이슈를 선택합니다.
3. 오른쪽 사이드바의 Status 섹션에서 Edit를 선택합니다.
4. 드롭다운 목록에서 상태를 선택합니다.

이슈의 상태는 즉시 업데이트됩니다.

이슈의 상태는 다음에서 확인할 수 있습니다.

• Work items 목록
• 에픽의 Child items 섹션
• 이슈 보드의 카드

/status 빠른 작업을 사용하여 상태를 설정할 수도 있습니다.

참여자#

참여자는 이슈와 상호 작용한 사용자입니다. 참여자 보기에 대한 자세한 내용은 참여자를 참고합니다.

이슈 게시#

상태 페이지 애플리케이션이 프로젝트와 연결되어 있으면 /publish 빠른 작업을 사용하여 이슈를 게시할 수 있습니다.

자세한 내용은 GitLab Status Page를 참고합니다.

이슈 관련 빠른 작업#

빠른 작업을 사용하여 이슈를 관리할 수도 있습니다.

일부 작업에는 아직 해당하는 UI 버튼이 없습니다. 다음 작업은 빠른 작업으로만 수행할 수 있습니다.

• Zoom 미팅 추가 또는 제거 (/zoom 및 /remove_zoom)
• 이슈 게시 (/publish)
• 같은 프로젝트 또는 다른 프로젝트로 이슈 복제(/clone)
• 이슈를 닫고 다른 이슈의 중복으로 표시(/duplicate)
• 프로젝트의 다른 머지 리퀘스트 또는 이슈에서 레이블과 마일스톤 복사(/copy_metadata)

관련 주제#

• 연결된 항목
• 하위 항목