쾌속 행동

어서 오세요Tanuki Tuesday. 여기서 제가 제공하는 기능을 보겠습니다.
이번 주에 나는 신속한 행동과 그들이 어떻게 당신의 업무 효율을 높일 수 있는지에 관심을 가질 것이다.문제 설명이나 평론 상자에서 벗어나지 말고 더 짧은 시간 안에 더 많은 일을 완성하세요.
나는 이 문장의 중점을 문제 중의 행동에 두었다.결합 요청 또는 Epics에 사용할 수 있는 몇 가지 빠른 작업

GitLab 무엇이 빠른 행동입니까?

편집기에서 작업을 수행할 수 있도록 함으로써, 질문 요소를 누르기 위해 태그 편집기에서 동작을 멈추는 대신 빠른 동작을 할 수 있습니다.
문제 분배, 라벨 추가, 문제의 중요성 설정, 이정표와 에픽 등은 빠른 행동으로 완성할 수 있다.
그 중 일부는 특정 구독 수준과만 관련이 있다.그러나 만약 당신의 프로젝트에 이 기능이 있다면, 습관이 되면, 나는 당신이 좋아할 것이라고 믿습니다.
뉴턴의 제3운동 법칙에 따르면'모든 동작에 대해 상등하고 상반되는 반작용이 있다'는 것은 이미 빠른 동작을 세운 것 같다.
기본적으로, 만약 당신이 빠른 동작을 통해 문제에 뭔가를 추가할 수 있다면, 그것도 삭제할 수 있다.

신속 행동의 사용

문제에 요소 정보(예를 들어 탭)를 추가할 때, 보통 선택 상자를 누르고 필요한 탭을 검색한 다음 그것을 누르면 완성됩니다.
레이블을 제거하는 절차는 동일합니다.같은 드롭다운 목록을 사용하여 검색한 다음 를 클릭하여 삭제합니다.
많은 탭을 추가하거나 삭제하거나 변경하려면 시간이 많이 걸릴 수 있습니다.

라벨

라벨은 내가 가장 자주 사용하는 빠른 행동을 하는 곳이다.나는 드롭다운 메뉴에서 탭을 선택하는 것을 거의 사용하지 않는다.
위의 그림에 앞서 나는 지난번에 그것을 사용한 것이 언제인지 기억하지 못한다.나는 빠른 행동을 통해 이 점을 할 수 있도록 완전히 훈련했다.
빠른 동작으로 문제에 탭을 추가하는 것은 매우 간단합니다. 편집기 창에서 /label 한 줄만 시작하면 됩니다. 탭을 추가하면 ~ 탭을 검색할 수 있습니다.

선택할 탭 목록을 사용할 수 있을 때 위/아래 화살표를 사용하여 선택하고 enter를 사용하여 자동으로 완성할 수 있습니다.
태그 이름에 공백이 있으면 자동으로 따옴표가 추가됩니다.
추가할 탭마다 새 시작 줄을 추가할 필요가 없습니다. /label그것들을 모두 같은 줄에 추가하기만 하면 된다.

작업흐름의 일부로 사용하고 있다면, 이것들은 모두 사용할 수 있습니다.
해당되는 경우 동일한 범위의 이전 태그를 삭제하고 설명/질문 편집 상자의 태그로 바꿉니다.
구독에 scoped labels가 없지만 문제의 탭을 삭제해야 한다면 /remove_label와/label 같은 방식으로 사용할 수 있습니다./unlabel는 /remove_label의 대체품으로 시간을 절약하려면 같은 일을 하기 때문에 문자가 더 적게 필요합니다.
그러나 모든 사람이 밑줄을 입력하는 것에 익숙한 것은 아니다.

범위 레이블 이정표와 사시

정확한 이정표나 에픽을 찾지 못하면, 이 이정표나 에픽을 빠르게 추가하고 삭제할 수 있습니다.
설명에서 /epic &로 시작하는 줄을 통해 저장한 후 바로 에픽에 문제를 추가할 수 있습니다.
마찬가지로 한 줄의 시작/milestone %은 자동으로 이정표를 검색하고 사용할 수 있도록 합니다.

결안 사항

일반적인 경우, 이것은 문제의 평론 부분에서 진행될 것이다.왜?왜냐하면 문제를 동시에 만들고 닫지 않을 수도 있으니까!
왜 이 문제가 닫혔는지 설명하기 위해 정책 결정의 역사적 기록을 추가할 가능성이 높다.
예, 설명 버튼 바로 아래에 "설명 및 질문 닫기"버튼이 있지만 여기에는 Tab나 마우스가 필요합니다.
어떤 사람들은 (나도 그중의 하나) 키보드 단축키(다음에 자세히 소개)를 사용하여 댓글을 제출한다Ctrl+Return.
평론 상자에 들어간 후 닫는 원인을 추가하고 새 줄을 추가하고 /close를 입력한 다음 제출합니다.끝나다편안한 키보드에서 벗어날 필요가 없다.

템플릿 게시 및 병합

내가 전에 와 그에 따른 이점을 소개한 적이 있다.
더 좋은 방법은 그것들을 빠른 행동과 결합시키는 것이다.
템플릿에 빠른 동작을 추가하면 처음부터 문제에 대한 메타데이터를 정확하게 설정할 수 있습니다.
업무 절차가 있다면, 이미 알고 있는 방식으로 문제를 분류해야 한다. 이것은 관심을 가져야 한다는 것을 의미한다. 그러면 가능한 한 빨리 정확하게 처리하는 것이 중요하다.
예를 들어, Bug의 워크플로우는 Issue Type::Bug, Bug::New, Priority::TBC 및 Severity::TBC 설정issue templates입니다.
이것들은 모두 색깔이 있어서 나는 곧 문제 목록에서 그것들을 볼 수 있지만, 그것들도 맞춤형 문제판에 나타난다.
매번 이런 내용을 추가해야 한다는 것을 명심하도록 요구하면 오류와 누락이 발생할 수 있다.
템플릿에 추가하면 기억할 필요가 없다는 것을 의미한다.그들은 문제를 제출하고 추가하기만 하면 된다.
템플릿에는 문제를 만들 때 추가된 다음 줄이 포함되어 있습니다.

/label ~"Issue Type::Bug" ~"Bug::New" ~"Priority::TBC" ~"Severity::TBC"

다른 문제 템플릿은 시스템의 특정 영역과 관련이 있을 수 있습니다.그것이 전단이든 후단이든 시스템의 모듈(예를 들어 Products Bug처럼 정교하든 상관없다.
이런 문제들은 특정한 사람이나 단체로 분류하기에 더욱 적합할 수 있다.이것이 /assign 템플릿에 포함될 수 있는 위치입니다.
물론 당신은 누가 특정한 팀이나 그룹의 문제를 돌보고 있는지 기억할 수 있습니다. 그러나 그들이 떠나거나 팀을 바꾸거나 다른 사람들이 이 문제를 처리하고 있습니까?
너는 이런 변화를 의식하지 못했을 수도 있다. 누군가가 이 문제들을 처리하기 전에 일은 한쪽으로 내버려 둘 수도 있다.
템플릿/assign에서 설정하면 문제의 방향을 빠르고 쉽게 업데이트할 수 있습니다.
기본 지점에서 템플릿을 변경하면 완성됩니다.새로운 문제는 새로운 사람에게 분배된다.

범위 레이블 요약

빠른 행동은 많은 일을 할 수 있고, 완전한 리스트는 에서 찾을 수 있다.
그 중 일부는 특정 상하문에서만 사용할 수 있다. 예를 들어 /wip는 합병 요청에서만 사용할 수 있지만 일부는 문제, 합병 요청과 에픽에서만 유용하다.
나는 이것이 좋은 학습 곡선이라고 믿지 않는다. 그러나 적어도 나에게 있어서, 그들은 전체 화면을 클릭함으로써 많은 시간을 절약했다.
키보드와 마우스 사이를 왔다 갔다 하며 내용을 선택하고 메타데이터를 기록에 추가할 필요가 없습니다.
이러한 문제를 문제 템플릿에 포함시키면 더 많은 시간을 절약할 수 있습니다.
문제를 분류하거나 기본적으로 어떤 탭을 지정해야 하는지 기억할 필요가 없다.
인지 부하 감소;스트레스를 줄이다.
다음에 GitLab에서 작업할 때 메타 정보를 추가할 필요가 있으면 빠른 조작을 시도해 보십시오.