개요
- 관련 Merge Request 재정의
- GitLab Enterprise 변경 사항
변경 로그 항목을 정당화하는 기준
좋은 변경 로그 항목 작성하기
변경 로그 항목 생성 방법

변경 로그 항목

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

개요

우리의 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 항목을 추가해야 합니다. 이렇게 하면 커밋이 스쿼시될 때 올바른 항목이 생성됩니다.

GitLab Enterprise 변경 사항

변경 사항이 GitLab Enterprise Edition 전용이라면 반드시 EE: true 트레일러를 추가해야 합니다:

Git 벤더를 gitlab으로 업데이트

이제 우리는 git을 컴파일하기 위해 gitaly를 사용하고 있으므로 git 버전은 manifest에서 알 수 없습니다. 대신 gitaly 버전을 가져오고 있습니다. CVE가 옛날 버전에 맞는지 확인하지 않도록 공급 업체 필드를 `gitlab`으로 업데이트합니다.

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

양쪽 EE와 CE에 적용되는 변경 사항에는 트레일러를 추가하지 마십시오.

변경 로그 항목을 정당화하는 기준

기본, 추가, 또는 데이터 마이그레이션을 소개하는 모든 변경 사항은 비활성화된 피처 플래그 뒤에 숨겨져 있더라도 변경 로그 항목을 가져야 합니다.
보안 수정은 보안 엔지니어 문서에 따라 Changelog 트레일러가 security로 설정된 변경 로그 항목을 가져야 합니다.
사용자를 대상으로 하는 모든 변경 사항은 변경 로그 항목을 가져야 합니다. 예: “GitLab이 이제 모든 텍스트에 시스템 글꼴을 사용합니다.”
우리의 REST 및 GraphQL API를 대상으로 하는 모든 클라이언트를 대상으로 하는 변경 사항은 변경 로그 항목을 가져야 합니다. GraphQL 중단 변경 사항의 완전한 디렉터리을 참조.
고급 검색 마이그레이션을 소개하는 모든 변경 사항은 변경 로그 항목을 가져야 합니다.
동일한 릴리스에서 소개되고 소식되었다가 다시 알려진 재귀적인 수정(예: 매월 릴리스 후보자 중에 소개된 버그를 수정하는 경우)은 변경 로그 항목을 가져서는 안됩니다.
개발자를 대상으로 하는 변경 사항(예: 리팩터링, 기술적 부채 해결, 또는 테스트 수트 변경)은 변경 로그 항목을 가져서는 안됩니다. 예: “Cycle Analytics 모델 사양에서 생성된 데이터베이스 레코드 줄이기.”
커뮤니티 구성원의 어떤 기여라도(구매 크기와는 무관) 변경 로그 항목을 가져야 하지만, 이 가이드라인을 준수하든 말든 그렇습니다.
실험 변경 사항은 변경 로그 항목을 가져서는 안됩니다.
문서 변경만 포함된 MR은 변경 로그 항목을 가져서는 안됩니다.

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

좋은 변경 로그 항목 작성하기

좋은 변경 로그 항목은 기술적이고 간결해야 합니다. 변화에 대한 제로 컨텍스트를 가진 독자에게 변화를 설명해야 합니다. 간결하고 기술적이면서도 설명적이기 어렵다면 설명적인 쪽으로 치우치세요.

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

첫 번째 예는 변경이 어디에서 일어났는지, 또는 왜, 또는 사용자에게 어떻게 이점을 가져다 주는지를 전혀 설명하지 않습니다.

나쁨: (일부 텍스트)를 클립보드에 복사합니다.
좋음: “클립보드에 복사” 툴팁이 복사되는 항목을 나타내도록 업데이트합니다.

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

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

첫 번째 예는 너무 구현 세부 사항에 집중합니다. 사용자는 우리가 CSS와 HTML을 변경했다는 점에 관심이 없습니다. 그들은 이러한 변경의 결과에 관심이 있습니다.

나쁨: find_commits_by_message_with_elastic에서 반환된 커밋 객체의 배열에서 nil을 제거합니다.
좋음: ElasticSearch 결과가 쓰레기로 처리된 커밋을 참조하는 500 오류를 수정합니다.

첫 번째 예는 무엇_을 고쳤는지가 아니라 _어떻게 우리가 무언가를 고쳤는지에 중점을 두고 있습니다. 다시 작성된 버전은 사용자에게 명확한 이점(더 적은 500 오류)을 설명하며 언제(Elasictsearch를 사용하여 커밋 검색) 이게 고쳐졌는지 명확히 설명합니다.

여러분의 최선의 판단력을 발휘하고 컴파일된 변경 로그를 읽고 있는 사람들의 입장에 서서 이 항목이 가치가 있습니까? 변경이 일어난 _어디_와 _왜_에 대한 컨텍스트를 제공하나요?

변경 로그 항목 생성 방법

Git 트레일러는 변경 내용을 커밋할 때 추가됩니다. 이는 사용하는 텍스트 편집기를 사용하여 수행할 수 있습니다. 기존 커밋에 트레일러를 추가하는 경우 가장 최근 커밋을 수정하거나 git rebase -i를 사용하여 상호적인 리베이스를 해야 합니다.

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

git commit --amend

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

git push -f origin your-branch-name

이전 (또는 여러 커밋)을 편집하려면 git rebase -i HEAD~N을 사용합니다. 여러분의 브랜치에 3개의 커밋 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 문서를 참조하세요.

개발 문서로 돌아가기

변경 로그 항목

개요

관련 Merge Request 재정의

GitLab Enterprise 변경 사항

변경 로그 항목을 정당화하는 기준

좋은 변경 로그 항목 작성하기

변경 로그 항목 생성 방법

도움말

기능 사용 가능성과 제품 평가판

도움받기