InfoGrab DocsInfoGrab Docs

변경 로그 항목

요약

CHANGELOG.md 파일의 각 목록 항목, 즉 엔트리는 Git 커밋의 제목 줄에서 생성됩니다. Git 트레일러는 변경 사항을 커밋할 때 추가하며, 원하는 텍스트 편집기에서 작업할 수 있습니다. 사용 사례에 맞는 트레일러를 선택 합니다.

CHANGELOG.md 파일의 각 목록 항목, 즉 엔트리는 Git 커밋의 제목 줄에서 생성됩니다. 커밋에 Changelog Git 트레일러가 포함되어 있으면 해당 커밋이 변경 로그에 포함됩니다. 변경 로그를 생성할 때 작성자와 머지 리퀘스트 정보는 자동으로 추가됩니다.

변경 로그 항목 생성 방법#

Git 트레일러는 변경 사항을 커밋할 때 추가하며, 원하는 텍스트 편집기에서 작업할 수 있습니다. 변경 로그를 추가하려면 다음 단계를 수행합니다:

  1. 사용 사례에 맞는 트레일러를 선택 합니다.

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

    Update git vendor to GitLab

Now that we are using Gitaly to compile Git, the Git version isn't known
from the manifest. Instead, we are getting the Gitaly version. Update our
vendor field to be `gitlab` to avoid CVE matching old versions.

Changelog: changed

  2. 변경 사항을 푸시합니다.

머지 리퀘스트에 커밋이 여러 개라면 첫 번째 커밋에 Changelog 항목을 추가해야 합니다. 이렇게 하면 커밋이 스쿼시될 때 올바른 항목이 생성됩니다.

기존 커밋에 트레일러를 추가하려면 해당 커밋을 amend 하거나(가장 최근 커밋인 경우), git rebase -i로 대화형 리베이스를 수행해야 합니다.

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

    git commit --amend

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

    git push -f origin your-branch-name

  • 더 이전 커밋이나 여러 커밋을 수정하려면 git rebase -i HEAD~N을 사용합니다. 여기서 N은 리베이스할 최근 커밋 수입니다. 예를 들어 브랜치에 커밋이 세 개 있고 두 번째 커밋만 업데이트하려면 다음을 실행합니다:

    git rebase -i HEAD~2

    그러면 최근 두 커밋에 대한 대화형 리베이스 세션이 시작됩니다. 세션이 시작되면 Git이 다음과 같은 내용이 담긴 텍스트 편집기를 띄웁니다:

    pick B Subject of commit B
pick C Subject of commit C

    커밋 B를 업데이트하려면 pick을 reword로 바꾼 뒤 저장하고 편집기를 닫습니다. 편집기를 닫으면 Git이 커밋 B의 커밋 메시지를 편집할 새 텍스트 편집기 인스턴스를 띄웁니다. 트레일러를 추가한 뒤 저장하고 편집기를 닫습니다. 문제가 없으면 커밋 B가 업데이트됩니다.

    원격 브랜치에 이미 존재하는 커밋을 변경했으므로, 원격 브랜치에 푸시할 때는 --force-with-lease 플래그를 사용해야 합니다:

    git push origin your-branch-name --force-with-lease

대화형 리베이스에 관한 자세한 내용은 Git 문서를 참고합니다.

연결된 머지 리퀘스트 재정의#

GitLab은 변경 로그를 생성할 때 머지 리퀘스트를 커밋에 자동으로 연결합니다. 연결할 머지 리퀘스트를 재정의하려면 MR 트레일러로 다른 머지 리퀘스트를 지정할 수 있습니다:

Update git vendor to gitlab

Now that we are using gitaly to compile git, the git version isn't known
from the manifest, instead we are getting the gitaly version. Update our
vendor field to be `gitlab` to avoid cve matching old versions.

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

값은 머지 리퀘스트의 전체 URL이어야 합니다.

GitLab Enterprise 변경 사항#

GitLab Enterprise Edition에만 해당하는 변경이라면 EE: true 트레일러를 추가해야 합니다:

Update git vendor to gitlab

Now that we are using gitaly to compile git, the git version isn't known
from the manifest, instead we are getting the gitaly version. Update our
vendor field to be `gitlab` to avoid cve matching old versions.

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

EE와 CE 모두에 적용되는 변경에는 이 트레일러를 추가하지 않습니다.

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

  • 일반 마이그레이션, post 마이그레이션, 데이터 마이그레이션 중 무엇이든 데이터베이스 마이그레이션을 추가하는 변경에는, 비활성화된 기능 플래그 뒤에 있더라도 변경 로그 항목이 있어야 합니다.
  • 보안 수정에는 Changelog 트레일러를 security로 설정한 변경 로그 항목이 있어야 합니다.
  • 사용자에게 보이는 변경에는 변경 로그 항목이 있어야 합니다. 예: "GitLab now uses system fonts for all text."
  • REST 및 GraphQL API에 대한 클라이언트 대상 변경에는 변경 로그 항목이 있어야 합니다. GraphQL 호환성 파괴 변경의 전체 목록을 참고합니다.
  • 고급 검색 마이그레이션을 추가하는 변경에는 변경 로그 항목이 있어야 합니다.
  • 같은 릴리스에서 발생했다가 같은 릴리스에서 수정된 회귀에 대한 수정(예: 월간 릴리스 후보 기간에 발생한 버그 수정)에는 변경 로그 항목을 두지 않습니다.
  • 리팩터링, 기술 부채 해소, 테스트 스위트 변경처럼 개발자에게만 영향을 주는 변경에는 변경 로그 항목을 두지 않습니다. 예: "Reduce database records created during Cycle Analytics model spec."
  • 커뮤니티 구성원의 기여는 아무리 작더라도, 기여자가 원한다면 이 가이드라인과 무관하게 변경 로그 항목을 둘 수 있습니다.
  • 실험 변경에는 변경 로그 항목을 두지 않습니다.
  • 문서 변경만 포함하는 MR에는 변경 로그 항목을 두지 않습니다.

자세한 내용은 기능 플래그가 있는 변경 로그 항목 처리 방법을 참고합니다.

좋은 변경 로그 항목 작성법#

좋은 변경 로그 항목은 설명이 충분하면서도 간결합니다. 해당 변경에 관한 사전 정보가 전혀 없는 독자에게도 변경 내용을 설명해야 합니다. 간결함과 설명력을 모두 갖추기 어렵다면 설명이 충분한 쪽을 택합니다.

  • 나쁜 예: 프로젝트 순서로 이동.
  • 좋은 예: "프로젝트로 이동" 드롭다운 목록의 상단에 사용자가 즐겨찾기한 프로젝트를 표시.

첫 번째 예는 변경이 어디에서 이루어졌는지, 왜 이루어졌는지, 사용자에게 어떤 도움이 되는지에 관한 컨텍스트를 전혀 제공하지 않습니다.

  • 나쁜 예: (일부 텍스트를) 클립보드에 복사.
  • 좋은 예: "클립보드에 복사" 툴팁을 업데이트하여 무엇이 복사되는지 표시.

여기서도 첫 번째 예는 지나치게 모호하고 컨텍스트를 제공하지 않습니다.

  • 나쁜 예: 미니 파이프라인 그래프와 빌드 드롭다운 목록의 CSS 및 HTML 문제를 수정하고 개선.
  • 좋은 예: 미니 파이프라인 그래프와 빌드 드롭다운 목록의 툴팁 및 호버 상태를 수정.

첫 번째 예는 구현 세부 사항에 지나치게 치우쳐 있습니다. 사용자는 CSS와 HTML을 바꿨다는 사실이 아니라 그 변경의 최종 결과 에 관심이 있습니다.

  • 나쁜 예: find_commits_by_message_with_elastic에서 반환된 커밋 객체 배열에서 nil을 제거
  • 좋은 예: Elasticsearch 결과가 가비지 컬렉션된 커밋을 참조하여 발생하는 500 오류를 수정

첫 번째 예는 무엇을 고쳤는지가 아니라 어떻게 고쳤는지에 초점을 맞추고 있습니다. 다시 쓴 항목은 사용자가 얻는 최종 이점 (500 오류 감소)과 그 상황(Elasticsearch로 커밋을 검색할 때)을 분명하게 설명합니다.

가장 적절한 판단을 내리되, 완성된 변경 로그를 읽는 사람의 입장에서 생각합니다. 이 항목이 가치를 더하는지, 변경이 이루어진 위치 와 이유 에 관한 컨텍스트를 제공하는지 확인합니다.

개발 문서로 돌아가기

변경 로그 항목

GitLab v19.4
원문 보기

요약

CHANGELOG.md 파일의 각 목록 항목, 즉 엔트리는 Git 커밋의 제목 줄에서 생성됩니다. Git 트레일러는 변경 사항을 커밋할 때 추가하며, 원하는 텍스트 편집기에서 작업할 수 있습니다. 사용 사례에 맞는 트레일러를 선택 합니다.

CHANGELOG.md 파일의 각 목록 항목, 즉 엔트리는 Git 커밋의 제목 줄에서 생성됩니다. 커밋에 Changelog Git 트레일러가 포함되어 있으면 해당 커밋이 변경 로그에 포함됩니다. 변경 로그를 생성할 때 작성자와 머지 리퀘스트 정보는 자동으로 추가됩니다.

변경 로그 항목 생성 방법#

Git 트레일러는 변경 사항을 커밋할 때 추가하며, 원하는 텍스트 편집기에서 작업할 수 있습니다. 변경 로그를 추가하려면 다음 단계를 수행합니다:

  1. 사용 사례에 맞는 트레일러를 선택 합니다.

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

    Update git vendor to GitLab

Now that we are using Gitaly to compile Git, the Git version isn't known
from the manifest. Instead, we are getting the Gitaly version. Update our
vendor field to be `gitlab` to avoid CVE matching old versions.

Changelog: changed

  2. 변경 사항을 푸시합니다.

머지 리퀘스트에 커밋이 여러 개라면 첫 번째 커밋에 Changelog 항목을 추가해야 합니다. 이렇게 하면 커밋이 스쿼시될 때 올바른 항목이 생성됩니다.

기존 커밋에 트레일러를 추가하려면 해당 커밋을 amend 하거나(가장 최근 커밋인 경우), git rebase -i로 대화형 리베이스를 수행해야 합니다.

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

    git commit --amend

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

    git push -f origin your-branch-name

  • 더 이전 커밋이나 여러 커밋을 수정하려면 git rebase -i HEAD~N을 사용합니다. 여기서 N은 리베이스할 최근 커밋 수입니다. 예를 들어 브랜치에 커밋이 세 개 있고 두 번째 커밋만 업데이트하려면 다음을 실행합니다:

    git rebase -i HEAD~2

    그러면 최근 두 커밋에 대한 대화형 리베이스 세션이 시작됩니다. 세션이 시작되면 Git이 다음과 같은 내용이 담긴 텍스트 편집기를 띄웁니다:

    pick B Subject of commit B
pick C Subject of commit C

    커밋 B를 업데이트하려면 pick을 reword로 바꾼 뒤 저장하고 편집기를 닫습니다. 편집기를 닫으면 Git이 커밋 B의 커밋 메시지를 편집할 새 텍스트 편집기 인스턴스를 띄웁니다. 트레일러를 추가한 뒤 저장하고 편집기를 닫습니다. 문제가 없으면 커밋 B가 업데이트됩니다.

    원격 브랜치에 이미 존재하는 커밋을 변경했으므로, 원격 브랜치에 푸시할 때는 --force-with-lease 플래그를 사용해야 합니다:

    git push origin your-branch-name --force-with-lease

대화형 리베이스에 관한 자세한 내용은 Git 문서를 참고합니다.

연결된 머지 리퀘스트 재정의#

GitLab은 변경 로그를 생성할 때 머지 리퀘스트를 커밋에 자동으로 연결합니다. 연결할 머지 리퀘스트를 재정의하려면 MR 트레일러로 다른 머지 리퀘스트를 지정할 수 있습니다:

Update git vendor to gitlab

Now that we are using gitaly to compile git, the git version isn't known
from the manifest, instead we are getting the gitaly version. Update our
vendor field to be `gitlab` to avoid cve matching old versions.

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

값은 머지 리퀘스트의 전체 URL이어야 합니다.

GitLab Enterprise 변경 사항#

GitLab Enterprise Edition에만 해당하는 변경이라면 EE: true 트레일러를 추가해야 합니다:

Update git vendor to gitlab

Now that we are using gitaly to compile git, the git version isn't known
from the manifest, instead we are getting the gitaly version. Update our
vendor field to be `gitlab` to avoid cve matching old versions.

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

EE와 CE 모두에 적용되는 변경에는 이 트레일러를 추가하지 않습니다.

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

  • 일반 마이그레이션, post 마이그레이션, 데이터 마이그레이션 중 무엇이든 데이터베이스 마이그레이션을 추가하는 변경에는, 비활성화된 기능 플래그 뒤에 있더라도 변경 로그 항목이 있어야 합니다.
  • 보안 수정에는 Changelog 트레일러를 security로 설정한 변경 로그 항목이 있어야 합니다.
  • 사용자에게 보이는 변경에는 변경 로그 항목이 있어야 합니다. 예: "GitLab now uses system fonts for all text."
  • REST 및 GraphQL API에 대한 클라이언트 대상 변경에는 변경 로그 항목이 있어야 합니다. GraphQL 호환성 파괴 변경의 전체 목록을 참고합니다.
  • 고급 검색 마이그레이션을 추가하는 변경에는 변경 로그 항목이 있어야 합니다.
  • 같은 릴리스에서 발생했다가 같은 릴리스에서 수정된 회귀에 대한 수정(예: 월간 릴리스 후보 기간에 발생한 버그 수정)에는 변경 로그 항목을 두지 않습니다.
  • 리팩터링, 기술 부채 해소, 테스트 스위트 변경처럼 개발자에게만 영향을 주는 변경에는 변경 로그 항목을 두지 않습니다. 예: "Reduce database records created during Cycle Analytics model spec."
  • 커뮤니티 구성원의 기여는 아무리 작더라도, 기여자가 원한다면 이 가이드라인과 무관하게 변경 로그 항목을 둘 수 있습니다.
  • 실험 변경에는 변경 로그 항목을 두지 않습니다.
  • 문서 변경만 포함하는 MR에는 변경 로그 항목을 두지 않습니다.

자세한 내용은 기능 플래그가 있는 변경 로그 항목 처리 방법을 참고합니다.

좋은 변경 로그 항목 작성법#

좋은 변경 로그 항목은 설명이 충분하면서도 간결합니다. 해당 변경에 관한 사전 정보가 전혀 없는 독자에게도 변경 내용을 설명해야 합니다. 간결함과 설명력을 모두 갖추기 어렵다면 설명이 충분한 쪽을 택합니다.

  • 나쁜 예: 프로젝트 순서로 이동.
  • 좋은 예: "프로젝트로 이동" 드롭다운 목록의 상단에 사용자가 즐겨찾기한 프로젝트를 표시.

첫 번째 예는 변경이 어디에서 이루어졌는지, 왜 이루어졌는지, 사용자에게 어떤 도움이 되는지에 관한 컨텍스트를 전혀 제공하지 않습니다.

  • 나쁜 예: (일부 텍스트를) 클립보드에 복사.
  • 좋은 예: "클립보드에 복사" 툴팁을 업데이트하여 무엇이 복사되는지 표시.

여기서도 첫 번째 예는 지나치게 모호하고 컨텍스트를 제공하지 않습니다.

  • 나쁜 예: 미니 파이프라인 그래프와 빌드 드롭다운 목록의 CSS 및 HTML 문제를 수정하고 개선.
  • 좋은 예: 미니 파이프라인 그래프와 빌드 드롭다운 목록의 툴팁 및 호버 상태를 수정.

첫 번째 예는 구현 세부 사항에 지나치게 치우쳐 있습니다. 사용자는 CSS와 HTML을 바꿨다는 사실이 아니라 그 변경의 최종 결과 에 관심이 있습니다.

  • 나쁜 예: find_commits_by_message_with_elastic에서 반환된 커밋 객체 배열에서 nil을 제거
  • 좋은 예: Elasticsearch 결과가 가비지 컬렉션된 커밋을 참조하여 발생하는 500 오류를 수정

첫 번째 예는 무엇을 고쳤는지가 아니라 어떻게 고쳤는지에 초점을 맞추고 있습니다. 다시 쓴 항목은 사용자가 얻는 최종 이점 (500 오류 감소)과 그 상황(Elasticsearch로 커밋을 검색할 때)을 분명하게 설명합니다.

가장 적절한 판단을 내리되, 완성된 변경 로그를 읽는 사람의 입장에서 생각합니다. 이 항목이 가치를 더하는지, 변경이 이루어진 위치 와 이유 에 관한 컨텍스트를 제공하는지 확인합니다.

개발 문서로 돌아가기