변경 로그 항목

이 안내서에는 변경 로그 항목을 생성하는 시기와 방법에 대한 지침과 변경 로그 프로세스에 대한 정보 및 이력이 포함되어 있습니다.

개요

우리의 CHANGELOG.md 파일의 각 디렉터리 항목 또는 항목은 Git 커밋의 제목 행에서 생성됩니다. 커밋은 Changelog Git 트레일러을 포함할 때 포함됩니다. 변경 로그를 생성할 때 작성자 및 Merge Request 세부 정보가 자동으로 추가됩니다.

Changelog 트레일러는 다음 값을 수용합니다.

added: 새로운 기능
fixed: 버그 수정
changed: 기능 변경
deprecated: 새로운 사용 중단
removed: 기능 제거
security: 보안 수정
performance: 성능 향상
other: 기타

변경 로그에 포함할 Git 커밋의 예는 다음과 같습니다.

git 벤더를 gitlab로 업데이트

이제 우리는 git을 컴파일하기 위해 gitaly를 사용하기 때문에 git 버전은 manifest에서 알 수 없습니다. 대신 gitaly 버전을 얻고 있습니다. cve가 오래된 버전과 일치하는 것을 피하기 위해 벤더 필드를 `gitlab`으로 업데이트합니다.

Changelog: changed

Merge Request에 여러 개의 커밋이 있는 경우, 첫 번째 커밋에 Changelog 항목을 추가해야 합니다. 이렇게 하면 커밋이 스쿼시될 때 올바른 항목이 생성됩니다.

연관 Merge Request 재정의

변경 로그를 생성할 때 GitLab은 Merge Request을 커밋에 자동으로 연결합니다. 연결할 Merge Request을 재정의하려면 MR 트레일러를 사용하여 대체 Merge Request을 지정할 수 있습니다.

git 벤더를 gitlab로 업데이트

이제 우리는 git을 컴파일하기 위해 gitaly를 사용하기 때문에 git 버전은 manifest에서 알 수 없습니다. 대신 gitaly 버전을 얻고 있습니다. cve가 오래된 버전과 일치하는 것을 피하기 위해 벤더 필드를 `gitlab`으로 업데이트합니다.

Changelog: changed
MR: https://gitlab.com/foo/bar/-/merge_requests/123

값은 Merge Request의 전체 URL이어야 합니다.

GitLab 엔터프라이즈 변경 사항

변경 사항이 GitLab 엔터프라이즈 에디션 전용인 경우, 반드시 EE: true 트레일러를 추가해야 합니다.

git 벤더를 gitlab로 업데이트

이제 우리는 git을 컴파일하기 위해 gitaly를 사용하기 때문에 git 버전은 manifest에서 알 수 없습니다. 대신 gitaly 버전을 얻고 있습니다. cve가 오래된 버전과 일치하는 것을 피하기 위해 벤더 필드를 `gitlab`으로 업데이트합니다.

Changelog: changed
MR: https://gitlab.com/foo/bar/-/merge_requests/123
EE: true

CE 및 EE 모두에 적용되는 변경 사항의 경우 트레일러를 추가하지 마세요.

변경 로그 항목이 필요한 경우

일반, 게시 또는 데이터 마이그레이션과 관련된 모든 변경 사항은 비활성화된 피처 플래그 뒤에 숨겨져 있더라도 변경 로그 항목이 반드시 있어야 합니다.
보안 수정 는 Changelog 트레일러를 security로 설정하여 변경 로그 항목이 반드시 있어야 합니다.
사용자가 볼 수 있는 모든 변경 사항은 변경 로그 항목이 반드시 있어야 합니다. 예: “GitLab이 이제 모든 텍스트에 시스템 글꼴을 사용합니다.”
REST 및 GraphQL API에 대한 모든 클라이언트용 변경 사항은 반드시 변경 로그 항목이 있어야 합니다. GraphQL 중단 변경 사항으로 구성되는 완전한 디렉터리을 참조하세요.
고급 검색 마이그레이션 를 도입하는 변경 사항은 반드시 변경 로그 항목이 있어야 합니다.
동일한 릴리스에서 소개된 후 수정된 회귀에 대한 수정(예: 월간 릴리스 후보 기간 중에 도입된 버그 수정)은 변경 로그 항목이 없어야 합니다.
개발자용 변경 사항 (예: 리팩터링, 기술 부채 해소, 또는 테스트 스위트 변경)은 변경 로그 항목이 없어야 합니다. 예: “사이클 분석 모델 사양에서 만들어진 데이터베이스 레코드 감소”.
커뮤니티 구성원의 어떤 기여라도, 작은 것일지라도, 항상 없어도 이 가이드라인과 관계 없이 변경 로그 항목을 가질 수 있습니다.
실험 변경 사항은 변경 로그 항목이 없어야 합니다.
문서 변경만 포함된 MR은 변경 로그 항목이 없어야 합니다.

자세한 내용은 피처 플래그로 변경 로그 항목을 처리하는 방법을 참조하세요.

좋은 변경 로그 항목 작성

좋은 변경 로그 항목은 구체적이고 간결해야 합니다. 변경 사항에 대해 아무런 콘텍스트도 가지지 않은 독자에게 변경 사항을 설명해야 합니다. 간결하면서도 묘사적이기 어려울 때는 묘사적인 쪽으로 편향되어야 합니다.

나쁨: 프로젝트 주문으로 이동합니다.
좋음: 사용자의 별표가 “프로젝트로 이동” 드롭다운 디렉터리 상단에 표시됩니다.

첫 번째 예는 변경이 어디에서 일어났는지, 또는 왜 그러한지, 또는 사용자에게 어떤 이점이 있는지에 대한 어떠한 콘텍스트도 제공하지 않습니다.

나쁨: (일부 텍스트)를 클립보드로 복사합니다.
좋음: “클립보드로 복사” 툴팁을 업데이트하여 복사되는 내용을 표시합니다.

다시 한 번, 첫 번째 예는 너무 모호하며 어떤 콘텍스트도 제공하지 않습니다.

나쁨: 미니 파이프라인 그래프와 빌드 드롭다운 디렉터리의 CSS 및 HTML 문제를 수정 및 개선합니다.
좋음: 미니 파이프라인 그래프와 빌드 드롭다운 디렉터리의 툴팁 및 호버 상태를 수정합니다.

첫 번째 예는 구현 세부 사항에 너무 초점을 맞추고 있습니다. 사용자는 우리가 CSS와 HTML을 변경했는지가 아니라 그 변경 사항들의 최종 결과에 관심이 있습니다.

나쁨: find_commits_by_message_with_elastic에서 반환된 Commit 객체 Array의 nil을 제거합니다.
좋음: Elasticsearch 결과가 가비지 수집된 커밋을 참조하여 발생하는 500 에러를 수정합니다.

첫 번째 예는 어떻게 우리가 무엇을 고쳤는지에 초점을 맞추고 있으며, 그것이 무엇을 고쳤는지에 대해 초점을 맞추고 있지 않습니다. 재작성된 버전은 사용자에게 명확하게 최종 혜택_을 설명하고있으며, _언제 (Elasticsearch를 사용하여 커밋을 검색할 때)를 나타낸다.

여러분의 최선의 판단력을 발휘하고, 편집된 변경 로그를 읽는 사람들의 입장에 서 보세요. 이 항목이 가치를 더하는가요? 변경 사항에 대한 콘텍스트를 제공합니까?

변경 로그 항목 생성 방법

변경 사항을 커밋할 때 Git 트레일러가 추가됩니다. 이는 원하는 텍스트 편집기를 사용하여 수행할 수 있습니다. 기존 커밋에 트레일러를 추가하려면 해당 커밋을 수정(가장 최근 것인 경우)하거나 git rebase -i를 사용하여 대화형 리베이스가 필요합니다.

마지막 커밋을 업데이트하려면 다음을 실행합니다:

git commit --amend

그런 다음 커밋 메시지에 Changelog 트레일러를 추가할 수 있습니다. 이미 이전 커밋을 원격 브랜치에 푸시한 경우, 새로운 커밋을 강제로 푸시해야 합니다:

git push -f origin 브랜치-이름

이전 커밋(또는 여러 개의 커밋)을 수정하려면 git rebase -i HEAD~N을 사용합니다. 여기서 N은 다시베이스할 마지막 N개의 커밋 수를 나타냅니다. 예를 들어 브랜치에 A, B, C 세 개의 커밋이 있다고 가정해보겠습니다. 커밋 B를 업데이트하려면 다음을 실행해야 합니다:

git rebase -i HEAD~2

이 명령은 마지막 두 개의 커밋에 대해 대화형 리베이스 세션이 시작됩니다. 시작하면 Git은 다음과 유사한 내용을 포함하는 텍스트 편집기를 여십니다:

pick B Commit B의 제목
pick C Commit C의 제목

커밋 B를 업데이트하려면 pick를 reword로 변경한 후 편집기를 저장하고 종료합니다. 편집기를 닫으면 Git에서 커밋 B의 커밋 메시지를 편집할 수 있는 새 편집기 창이 표시됩니다. 여기에 트레일러를 추가한 후 편집기를 저장하고 종료합니다. 모든 작업이 원할하게 진행되었다면 커밋 B가 업데이트된 상태가 됩니다.

대화형 리베이스에 대한 자세한 정보는 Git 문서를 참조하십시오.

개발 문서로 돌아가기