GitHub AE release notes

엔터프라이즈 소유자는 엔터프라이즈 계정의 조직 페이지에서 GitHub AE의 조직에 구성원 또는 소유자로 가입할 수 있습니다 . 자세한 내용은 “엔터프라이즈가 소유한 조직에서 역할 관리”를 참조하세요.

사용자 지정 리포지토리 역할은 일반적으로 사용할 수 있습니다. 사용자 지정 리포지토리 역할을 사용하면 조직 소유자는 이제 사용자에게 부여할 수 있는 리포지토리 액세스 권한을 보다 세부적으로 제어할 수 있습니다. 사용자 지정 리포지토리 역할은 REST API에서도 완벽하게 지원됩니다. 자세한 내용은 REST API 설명서의 "조직에 대한 사용자 지정 리포지토리 역할 관리" 및 "조직"을 참조하세요.

엔터프라이즈 소유자는 조직 소유자가 GitHub AE 리포지토리에 협력자를 초대하지 못하도록 방지할 수 있습니다. 자세한 내용은 "리포지토리에 협력자를 초대하는 정책 적용"을 참조하세요.

사용자는 누군가가 조직 또는 리포지토리에 대한 코드 보안 또는 분석 기능을 사용하거나 사용하지 않도록 설정할 때 트리거되는 웹후크 이벤트를 수신하도록 선택할 수 있습니다. 자세한 내용은 다음 설명서를 참조하세요.

• 웹후크 설명서의 "웹후크 이벤트 및 페이로드"
• “조직의 보안 및 분석 설정 관리”
• "리포지토리에 대한 보안 및 분석 기능 관리"

엔터프라이즈 소유자와 사용자는 엔터프라이즈 및 조직 감사 로그 및 REST API를 통해 비밀 검사 경고 및 비밀 검사 푸시 보호 무시를 볼 수 있습니다. 자세한 내용은 다음 설명서를 참조하세요.

• "비밀 검사를 사용하여 푸시 보호"
• "엔터프라이즈에 대한 감사 로그 이벤트"
• “조직의 감사 로그 검토”
• REST API 설명서의 "비밀 검사"

이제 조직 소유자는 사용자 지정 리포지토리 역할을 관리할 때 비밀 검사에 대한 두 가지 새 권한을 구성할 수 있습니다.

• 비밀 검사 결과 보기
• 비밀 검사 결과 해제 또는 다시 열기

자세한 내용은 “조직의 사용자 지정 리포지토리 역할 관리”를 참조하세요.

사용자는 액세스 권한에 따라 엔터프라이즈, 조직 또는 리포지토리 수준에서 사용자 지정 비밀 검사 패턴의 시험 실행을 실행할 수 있습니다. 드라이 런을 사용하면 사용자가 패턴을 게시하고 경고를 생성하기 전에 패턴을 검토하고 연마할 수 있습니다. 패턴을 작성한 다음 저장 및 건조 실행을 사용하여 결과를 검색할 수 있습니다. 검사는 일반적으로 몇 초밖에 걸리지 않지만 GitHub AE는 시험 실행 결과가 준비되면 이메일을 통해 사용자에게 알립니다. 자세한 내용은 "비밀 검사 정보" 및 "비밀 검사를 위한 사용자 지정 패턴 정의"를 참조하세요.

사용자는 UI 또는 API를 사용하여 보관된 리포지토리에 대한 비밀 검사를 사용하도록 설정할 수 있습니다. 자세한 내용은 REST API 설명서의 "비밀 검사 정보", "보관된 리포지토리 정보" 및 "리포지토리"를 참조하세요.

비밀 검사는 웹 편집기에서 비밀이 누출되는 것을 방지합니다. 자세한 내용은 “비밀 검사를 사용하여 푸시 보호”를 참조하세요.

이제 코드 검사는 더 많은 수의 CWU를 검색하고 CodeQL 코드 검사는 다음 언어 릴리스의 표준 언어 기능을 완벽하게 지원합니다.

• C# 10/ .NET 6
• Python 3.10
• Java 17
• TypeScript 4.5

자세한 내용은 GitHub 블로그를 참조하세요.

조직 소유자 및 보안 관리자는 조직의 보안 탭에서 코드 검사 경고를 볼 수 있습니다. 자세한 내용은 "보안 개요 정보"를 참조하세요.

이제 코드 검사 경고 페이지에는 항상 기본 분기에 대한 경고 상태 및 정보가 표시됩니다. 사이드바에는 다른 분기에서 경고의 상태를 볼 수 있는 새로운 "영향을 받는 분기" 패널이 있습니다. 경고가 기본 분기에 없는 경우 경고 페이지에 경고가 마지막으로 표시된 위치에 대한 상태가 "분기 내" 또는 "끌어오기 요청"으로 표시됩니다. 이렇게 개선하면 코드 베이스에 도입된 경고의 상태를 더 쉽게 이해할 수 있습니다. 자세한 내용은 “코드 검사 경고 정보”를 참조하세요. 경고 목록 페이지는 변경되지 않으며 로 필터링 branch할 수 있습니다. 코드 검사 API를 사용하여 경고에 대한 자세한 분기 정보를 검색할 수 있습니다. 자세한 내용은 REST API 설명서의 "코드 검사"를 참조하세요.

이제 코드 검사에서 경고의 분석 원본에 대한 세부 정보를 표시합니다. 경고에 둘 이상의 분석 원본이 있는 경우 "영향을 받는 분기" 사이드바 및 경고 타임라인에 표시됩니다. 사용자는 "영향을 받는 분기" 사이드바의 분석 원본 아이콘을 마우스로 가리키면 각 분석 원본의 경고 상태를 볼 수 있습니다. 경고에 단일 분석 원본만 있는 경우 분석 원본에 대한 정보가 경고 페이지에 표시되지 않습니다. 이러한 향상된 기능으로 경고를 더 쉽게 이해할 수 있습니다. 특히 여러 분석 원본이 있는 사용자를 이해하는 데 도움이 됩니다. 이는 모노 리포지토리와 같은 여러 분석 구성이 있는 설정에 특히 유용합니다. 자세한 내용은 “코드 검사 경고 정보”를 참조하세요.

사용자는 비밀 검사 경고를 검색할 때 REST API에서 및 direction 매개 변수를 사용하고 sort 경고 created 또는 updated 필드를 기준으로 정렬할 수 있습니다. 새 매개 변수는 모든 GitHub AE 배포 또는 개별 조직 또는 리포지토리에 사용할 수 있습니다. 자세한 내용은 다음 설명서를 참조하세요.

• "엔터프라이즈에 대한 비밀 검사 경고 나열"
• "조직에 대한 비밀 검사 경고 나열"
• "리포지토리에 대한 비밀 검사 경고 나열"
• REST API 설명서의 "비밀 검사"

사용자는 새 위치에서 비밀이 검색될 때 트리거되는 웹후크를 받도록 선택할 수 있습니다. 웹후크 이벤트에는 secret_scanning_alert_location 커밋 SHA와 같은 위치 세부 정보 및 검색에 대한 관련 경고가 포함됩니다. 검색된 비밀을 포함하는 모든 새 파일 경로에 대한 위치가 만들어집니다. 자세한 내용은 “웹후크 이벤트 및 페이로드”를 참조하세요.

사용자는 웹 UI 또는 REST API를 통해 코드 검사 경고를 해제할 때 필요에 따라 주석을 추가할 수 있습니다. 해제 주석은 이벤트 타임라인에 표시됩니다. 사용자는 REST API를 통해 해고 주석을 추가하거나 검색할 수도 있습니다. 자세한 내용은 REST API 설명서의 "끌어오기 요청에서 코드 검사 경고 심사" 및 "코드 검사"를 참조하세요.

이제 사용자는 REST API를 사용하여 조직에 대한 코드 검사 경고를 검색할 수 있습니다. 이 새로운 API 엔드포인트는 리포지토리에 대한 기존 엔드포인트를 보완합니다. 자세한 내용은 REST API 설명서의 "코드 검사"를 참조하세요.

리포지토리의 github/codeql-go 콘텐츠는 CodeQL에서 지원하는 다른 모든 프로그래밍 언어에 대한 유사한 라이브러리와 함께 라이브로 리포지토리로 이동 github/codeql 되었습니다. 이제 GitHub의 CodeQL 코드 분석 도구를 사용하여 Go 프로그래밍 언어로 작성된 코드베이스를 분석하기 위한 오픈 소스 CodeQL 쿼리, 라이브러리 및 추출기를 새 위치에서 찾을 수 있습니다. 기존 워크플로 마이그레이션에 대한 지침을 비롯한 자세한 내용은 github/codeql-go#741을 참조하세요.

엔터프라이즈 소유자는 애플리케이션 보안 위험에 대한 리포지토리 중심 보기 및 모든 비밀 검사 및 Dependabot 경고에 대한 경고 중심 보기를 포함하여 GitHub AE 배포에서 Dependabot 경고의 개요를 볼 수 있습니다. 보기는 베타 버전이며 변경될 수 있습니다. 자세한 내용은 "보안 개요 보기"를 참조하세요.

조직 소유자 및 보안 관리자는 조직의 보안 탭에서 Dependabot 경고를 볼 수 있습니다. 자세한 내용은 "보안 개요 정보"를 참조하세요.

사용자는 웹 UI를 사용하여 해제된 Dependabot 경고를 다시 열 수 있습니다. 이는 Dependabot 끌어오기 요청 또는 GraphQL API에 영향을 주지 않습니다. 자세한 내용은 "Dependabot 경고 정보"를 참조하세요.

사용자는 GraphQL API를 사용하여 Dependabot에서 고정된 경고를 볼 수 있습니다. 또한 사용자는 고유 숫자 식별자뿐만 아니라 상태별로 액세스 및 필터링하고 취약성 경고 개체의 상태를 기준으로 필터링할 수도 있습니다. 이제 에 대한 다음 필드가 RepositoryVulnerabilityAlert있습니다.

• number
• fixed_at
• fix_reason
• state

자세한 내용은 GraphQL API 설명서의 "개체"를 참조하세요.

조직 소유자 및 보안 관리자는 조직의 보안 개요를 사용하여 애플리케이션 보안 위험에 대한 리포지토리 중심 보기 또는 조직의 모든 리포지토리에 대한 모든 코드 검사, Dependabot 및 비밀 검사 경고에 대한 경고 중심 보기를 볼 수 있습니다. 자세한 내용은 “보안 개요 정보”를 참조하세요.

GitHub Actions 종속성을 검사하여 사용자의 끌어오기 요청에 대한 종속성 검토를 적용할 수 있으며 관련 보안 취약성에 대해 사용자에게 경고합니다. 이 dependency-review-action 작업은 두 수정 버전 간의 종속성을 분산하는 새 API 엔드포인트에서 지원됩니다. 자세한 내용은 “종속성 검토 정보”를 참조하세요.

종속성 그래프는 GitHub Actions 워크플로에 대한 YAML 파일을 검색합니다. GitHub AE는 Insights 탭의 종속성 그래프 섹션 내에 워크플로 파일을 표시합니다. 작업을 게시하는 리포지토리는 리포지토리 홈페이지의 "사용된 사용자" 컨트롤에서 해당 작업에 의존하는 리포지토리 수를 볼 수도 있습니다. 자세한 내용은 “종속성 그래프 정보”를 참조하세요.

종속성 그래프는 Rust에 대한 및 Cargo.lock 파일을 검색합니다Cargo.toml. 이러한 파일은 인사이트 탭의 종속성 그래프 섹션에 표시됩니다. 사용자는 Rust 종속성과 관련된 취약성에 대한 Dependabot 경고 및 업데이트를 받게 됩니다. 리포지토리에 패키지 매핑을 포함하여 패키지 메타데이터는 나중에 추가됩니다. 자세한 내용은 “종속성 그래프 정보”를 참조하세요.

GitHub AE에 대해 GitHub Connect를 사용하도록 설정한 경우 사용자는 GitHub 권고 데이터베이스의 보안 공지 개선에 기여할 수 있습니다. 기여하려면 권고의 세부 정보를 보면서 이 취약성에 대한 개선 제안 을 클릭합니다. 자세한 내용은 다음 문서를 참조하세요.

• "GitHub Connect 관리"
• GitHub Enterprise Cloud 설명서의 "GitHub 권고 데이터베이스에서 보안 취약성 검색"
• GitHub Enterprise Cloud 설명서의 "리포지토리에 대한 GitHub 보안 권고 정보"
• GitHub Enterprise Cloud 설명서의 "GitHub 권고 데이터베이스에서 보안 권고 편집"

자체 호스팅 실행기를 유지 관리하는 사람 이제 실행기가 소프트웨어 업데이트를 수행하는 시기를 더 많이 제어할 수 있습니다. 실행기에 --disableupdate 플래그를 지정하면 실행기 소프트웨어의 최신 버전을 사용할 수 있는 경우 실행기가 자동 소프트웨어 업데이트를 수행하지 않습니다. 이렇게 하면 사용자 지정 일정에 따라 자체 호스팅 실행기를 업데이트할 수 있으며, 자체 호스팅 실행기가 컨테이너에 있는 경우 특히 편리합니다. GitHub Actions 서비스와의 호환성을 위해 실행기 소프트웨어는 새 실행기 버전을 사용할 수 있는 후 30일 이내에 업데이트해야 합니다. 최신 실행기 버전의 설치에 대한 자세한 내용은 의 최신 릴리스actions/runner에 대한 설치 지침을 참조하세요.

GitHub Actions 사용하는 경우 다른 사람이 검토하지 않은 변경 사항을 보호된 분기에 병합할 위험을 줄이기 위해 엔터프라이즈 소유자 및 리포지토리 관리자는 작업에서 끌어오기 요청을 만들지 못하게 할 수 있습니다. 조직 소유자는 이전에 이 제한을 사용하도록 설정할 수 있습니다. 자세한 내용은 다음 문서를 참조하세요.

• "엔터프라이즈에서 GitHub Actions 정책 적용"
• "조직에 대한 GitHub Actions 사용 안 함 또는 제한"
• "리포지토리에 대한 GitHub Actions 설정 관리"

조직 소유자는 실행기 그룹에 액세스할 수 있는 워크플로를 선택하여 자체 호스팅 실행기에서 CI/CD 워크플로의 보안을 강화할 수 있습니다. 이전에는 이슈 레이블러와 같은 리포지토리의 모든 워크플로가 조직에서 사용할 수 있는 자체 호스팅 실행기에 액세스할 수 있습니다. 자세한 내용은 "그룹을 사용하여 자체 호스팅 실행기에 대한 액세스 관리" 및 GitHub 블로그를 참조하세요.

조직 소유자는 GitHub Actions 끌어오기 요청을 승인할 수 있는지 여부를 제어할 수 있습니다. 이 기능은 GitHub Actions 사용하여 "필수 승인" 분기 보호 요구 사항을 충족하고 다른 사용자가 검토하지 않은 변경 사항을 병합하는 사용자로부터 보호합니다. 기존 워크플로를 중단하지 않도록 하려면 기본적으로 GitHub Actions 검토가 필요한 승인으로 계산되도록 허용을 사용하도록 설정됩니다. 조직 소유자는 조직의 GitHub Actions 설정에서 기능을 사용하지 않도록 설정할 수 있습니다. 자세한 내용은 "조직에 대한 GitHub Actions 사용 안 함 또는 제한"을 참조하세요.

사용자는 및 workflow_call에 의해 workflow_dispatch 트리거되는 단일 워크플로를 작성하고 컨텍스트를 inputs 사용하여 입력 값에 액세스할 수 있습니다. workflow_dispatch 이전에는 입력이 이벤트 페이로드에 있었기 때문에 재사용 가능하고 수동으로 트리거된 하나의 워크플로를 작성하려는 워크플로 작성자의 어려움이 증가했습니다. 에 의해 workflow_dispatch트리거되는 워크플로의 경우 호환성을 유지하기 위해 컨텍스트에서 입력을 github.event.inputs 계속 사용할 수 있습니다. 자세한 내용은 “컨텍스트”를 참조하세요.

이제 사용자는 실패한 작업만 다시 실행하거나 GitHub Actions 워크플로 실행에서 개별 작업을 다시 실행할 수 있습니다. 자세한 내용은 “워크플로 및 작업 다시 실행”을 참조하세요.

작업 결과를 요약하기 위해 사용자는 Markdown을 생성하고 내용을 작업 요약으로 게시할 수 있습니다. 예를 들어 GitHub Actions 사용하여 테스트를 실행한 후 요약은 통과, 실패 또는 건너뛴 테스트에 대한 개요를 제공하여 잠재적으로 전체 로그 출력을 검토할 필요성을 줄일 수 있습니다. 자세한 내용은 "GitHub Actions 워크플로 명령"을 참조하세요.

워크플로를 다시 실행하는 동안 작업 실행 오류를 보다 쉽게 진단하기 위해 사용자는 디버그 로깅을 사용하도록 설정하여 작업의 실행 및 환경에 대한 정보를 출력할 수 있습니다. 자세한 내용은 "워크플로 및 작업 다시 실행" 및 "워크플로 실행 로그 사용"을 참조하세요.

GitHub Actions 대한 자체 호스팅 실행기를 관리하는 경우 실행할 스크립트를 정의하여 워크플로 실행 전후에 실행기 자체에서 일관된 상태를 보장할 수 있습니다. 스크립트를 사용하면 사용자가 이러한 단계를 워크플로에 수동으로 통합할 필요가 없습니다. 사전 및 사후 작업 스크립트는 베타 상태이며 변경될 수 있습니다. 자세한 내용은 "작업 전후 스크립트 실행"을 참조하세요.

엔터프라이즈 소유자는 사용자의 사용자 이름 또는 전체 이름이 내부 리포지토리 내에 표시되는지 여부를 제어하는 정책을 구성할 수 있습니다. 자세한 내용은 “엔터프라이즈에서 리포지토리 관리 정책 적용”을 참조하세요.

조직 소유자는 새 Pin 리포지토리 드롭다운을 통해 리포지토리에서 직접 조직의 프로필에 리포지토리를 고정 할 수 있습니다.

포크를 만드는 동안 사용자는 포크의 이름을 사용자 지정할 수 있습니다. 자세한 내용은 리포지토리 포크를 참조하세요.

사용자는 열린 끌어오기 요청과 연결된 분기를 삭제할 수 있습니다. 자세한 내용은 “리포지토리 내에서 분기 만들기 및 삭제”를 참조하세요.

CODEOWNERS는 다음과 같은 개선 사항을 받았습니다.

• 이제 웹 UI에서 CODEOWNERS 파일을 볼 때 구문 오류가 표시됩니다. 이전에는 CODEOWNERS 파일의 줄에 구문 오류가 있는 경우 오류가 무시되거나 경우에 따라 전체 CODEOWNERS 파일이 로드되지 않습니다. GitHub 앱 및 작업은 새 REST 및 GraphQL API를 사용하여 동일한 오류 목록에 액세스할 수 있습니다. 자세한 내용은 REST API 설명서의 "리포지토리" 또는 GraphQL API 설명서의 "개체"를 참조하세요.
• 누군가가 새 끌어오기 요청을 만들거나 초안 끌어오기 요청에 새 변경 내용을 푸시하면 검토를 요청할 코드 소유자가 이제 "검토자"의 끌어오기 요청에 나열됩니다. 이 기능을 사용하면 끌어오기 요청이 검토 준비가 된 것으로 표시되면 누가 검토하도록 요청될지 조기에 확인할 수 있습니다.
• CODEOWNERS 파일의 주석은 이제 전용 줄뿐만 아니라 줄의 끝에 나타날 수 있습니다.

자세한 내용은 “코드 사용자 정보”를 참조하세요.

사용자가 파일의 이름을 바꾸거나 새 디렉터리로 이동할 때 파일 내용의 절반 이상이 동일한 경우 커밋 기록은 파일의 이름이 과 비슷하게 git log --follow변경되었음을 나타냅니다. 자세한 내용은 GitHub 블로그를 참조하세요.

사용자는 분기와 연결된 끌어오기 요청을 병합하기 전에 분기를 성공적으로 배포해야 할 수 있습니다. 자세한 내용은 "보호된 분기 정보" 및 "분기 보호 규칙 관리"를 참조하세요.

이제 리포지토리 관리자는 리포지토리의 태그를 보호하도록 태그 보호 규칙을 구성할 수 있습니다. 태그 보호 규칙으로 보호되면 지정된 이름 패턴과 일치하는 태그는 리포지토리에 대한 유지 관리 또는 관리자 액세스 권한이 있는 사용자만 만들고 삭제할 수 있습니다. 자세한 내용은 "태그 보호 규칙 구성"을 참조하세요.

사용자는 리포지토리의 루트에 파일을 만들어 .git-blame-ignore-revs 비난 보기에서 수정 버전을 무시할 수 있습니다. 자세한 내용은 "파일 보기"를 참조하세요.

사용자는 예외를 지원하는 모든 분기 보호 규칙에 대해 GitHub 앱에 예외를 부여할 수 있습니다. 자세한 내용은 "앱 정보" 및 "분기 보호 규칙 관리"를 참조하세요.

만료되거나 해지된 공용 GPG 서명 키의 경우 GitHub AE는 Git 커밋 서명을 확인하고 키가 유효한 동안 사용자가 커밋을 했는지 확인한 대로 커밋을 표시합니다. 사용자는 만료되거나 해지된 GPG 키를 업로드할 수도 있습니다. 자세한 내용은 “커밋 서명 확인 정보”를 참조하세요.

커밋이 리포지토리를 관리하는 규칙 및 라이선스를 준수한다는 것을 확인하려면 조직 소유자 및 리포지토리 관리자는 이제 개발자가 웹 인터페이스를 통해 이루어진 커밋에 로그오프하도록 요구할 수 있습니다. 자세한 내용은 "조직에 대한 커밋 로그오프 정책 관리" 및 "리포지토리에 대한 커밋 로그오프 정책 관리"를 참조하세요.

사용자는 끌어오기 요청의 변경된 파일 탭에 있는 파일 트리를 사용하여 수정된 파일을 탐색하고 변경 내용의 크기와 범위를 이해하고 포커스 검토를 수행할 수 있습니다. 끌어오기 요청이 두 개 이상의 파일을 수정하고 브라우저 창이 충분히 넓으면 파일 트리가 나타납니다. 자세한 내용은 "끌어오기 요청에서 제안된 변경 내용 검토" 및 "끌어오기 요청에서 파일 필터링"을 참조하세요.

사용자는 기본적으로 끌어오기 요청 제목을 모든 Squash 병합에 대한 커밋 메시지로 사용할 수 있습니다. 자세한 내용은 “끌어오기 요청에 대한 커밋 Squash 구성”을 참조하세요.

끌어오기 요청 페이지의 분기 업데이트 단추를 사용하면 사용자가 기본 분기의 최신 변경 내용으로 끌어오기 요청의 분기를 업데이트할 수 있습니다. 이는 병합하기 전에 끌어오기 요청의 변경 내용이 현재 버전의 기본 분기와 호환되는지 확인하는 데 유용합니다. 두 가지 향상된 기능은 분기를 최신 상태로 유지하는 더 많은 방법을 제공합니다.

• 끌어오기 요청의 토픽 분기가 기본 분기와 함께 만료된 경우 사용자는 최신 버전의 기본 분기를 다시 지정하여 분기를 업데이트할 수 있습니다. 재지정은 토픽 분기의 변경 내용을 기본 분기의 최신 버전에 적용하므로 병합 커밋이 만들어지지 않으므로 선형 기록이 있는 분기가 생성됩니다. 다시 지정하여 업데이트하려면 분기 업데이트 단추 옆에 있는 드롭다운 메뉴를 클릭하고 다시 표시를 사용하여 업데이트를 클릭한 다음 분기 다시 지정을 클릭합니다. 이전에는 업데이트 분기 가 항상 끌어오기 요청 분기에서 병합 커밋을 초래하는 기존 병합을 수행했습니다. 이 옵션은 계속 사용할 수 있지만 이제 사용자가 선택할 수 있습니다. 자세한 내용은 “끌어오기 요청을 기본 분기와 동기화된 상태로 유지”를 참조하세요.
• 새 리포지토리 설정을 사용하면 끌어오기 요청의 토픽 분기가 기본 분기와 최신 상태가 아닌 경우 분기 업데이트 단추를 항상 사용할 수 있습니다. 이전에는 분기 보호 병합을 사용하도록 설정 하기 전에 분기를 최신 상태로 설정해야 하는 경우에만 이 단추를 사용할 수 있었습니다. 관리자 또는 유지 관리자 액세스 권한이 있는 사람 리포지토리 설정의 끌어오기 요청 섹션에서 항상 끌어오기 요청 분기 업데이트 제안 설정을 관리할 수 있습니다.**** 자세한 내용은 "끌어오기 요청 분기를 업데이트하기 위한 제안 관리"를 참조하세요.

특정 릴리스에 대한 세부 정보를 볼 때 사용자는 각 릴리스 자산의 생성 날짜를 볼 수 있습니다. 자세한 내용은 “리포지토리의 릴리스 및 태그 보기”를 참조하세요.

자동으로 생성된 릴리스 정보를 사용하여 릴리스를 만드는 동안 사용자는 이전 릴리스로 식별된 태그를 확인한 다음 다른 태그를 선택하여 이전 릴리스로 지정할 수 있습니다. 자세한 내용은 "자동으로 생성된 릴리스 정보"를 참조하세요.

이제 Gists는 처음 표시될 때 30개의 가장 최근의 의견만 표시합니다. 사용자는 이전 주석 로드... 를 클릭하여 자세히 볼 수 있습니다. 이렇게 하면 많은 주석이 있는 gists가 더 빨리 나타날 수 있습니다. 자세한 내용은 "gists와 콘텐츠 편집 및 공유"를 참조하세요.

웹 인터페이스에서 Markdown 편집이 개선되었습니다.

• 사용자가 텍스트를 선택하고 URL을 붙여넣으면 선택한 텍스트는 붙여넣은 URL에 대한 Markdown 링크가 됩니다.
• 사용자가 스프레드시트 셀 또는 HTML 테이블을 붙여넣으면 결과 텍스트가 테이블로 렌더링됩니다.
• 사용자가 링크가 포함된 텍스트를 복사하면 붙여넣은 텍스트에 링크가 Markdown 링크로 포함됩니다.

자세한 내용은 “기본 쓰기 및 서식 지정 구문”을 참조하세요.

웹 인터페이스에서 Markdown 파일을 편집할 때 미리 보기 탭을 클릭하면 편집 중인 미리 보기 위치로 자동으로 스크롤됩니다. 스크롤 위치는 미리 보기 탭을 클릭하기 전에 커서의 위치를 기반으로 합니다.

전경 요소와 배경 요소 간의 대비가 더 높은 밝은 고대비 테마를 사용할 수 있습니다. 자세한 내용은 “테마 설정 관리”를 참조하세요.

이제 사용자 또는 조직이 소유한 리포지토리 목록에 추가 필터 옵션인 "템플릿"이 있으므로 템플릿 리포지토리를 더 쉽게 찾을 수 있습니다.

GitHub AE는 PNG, JPG, GIF, PSD 및 SVG를 비롯한 몇 가지 일반적인 이미지 형식을 표시할 수 있으며 버전 간의 차이점을 비교하는 여러 가지 방법을 제공합니다. 끌어오기 요청에서 추가되거나 변경된 이미지를 검토할 때 해당 이미지의 미리 보기가 기본적으로 표시됩니다. 이전에는 사용자에게 이진 파일을 표시할 수 없다는 메시지가 표시되고 "서식 있는 diff 표시" 옵션을 전환해야 했습니다. 자세한 내용은 "코드가 아닌 파일 작업"을 참조하세요.

사용자, 조직, 리포지토리 및 팀의 설정 페이지가 다시 디자인되어 유사한 설정 페이지를 향상된 정보 아키텍처 및 검색 가능성을 위한 섹션으로 그룹화했습니다. 자세한 내용은 GitHub Changelog를 참조하세요.

링크 및 단추와 같은 웹 인터페이스의 대화형 요소는 사용자가 페이지에서 현재 위치를 찾을 수 있도록 키보드로 포커스가 있을 때 표시되는 윤곽선을 표시합니다. 또한 포커스가 있을 때 양식 필드에는 더 높은 대비 윤곽선이 있습니다.

이제 레이블에 포커스를 두거나 마우스로 가리키면 레이블의 설명이 포함된 도구 설명이 표시됩니다.

사용자가 새 문제 또는 끌어오기 요청을 만드는 동안 페이지를 새로 고치면 담당자, 검토자, 레이블 및 프로젝트가 모두 유지됩니다.

OAuth 및 GitHub 앱에 디바이스 권한 부여 흐름을 사용하려면 앱 작성자가 이 기능을 수동으로 사용하도록 설정해야 합니다. 이러한 변경으로 인해 통합업체가 위험을 인식하고 이러한 형식의 인증을 지원하기 위해 의식적으로 선택하도록 하여 GitHub AE 사용자에 대한 피싱 공격에 앱이 사용될 가능성을 줄입니다. OAuth 앱 또는 GitHub 앱을 소유하거나 관리하고 디바이스 흐름을 사용하려는 사용자는 앱의 설정 페이지를 통해 앱에 사용하도록 설정할 수 있습니다. 디바이스 흐름 API 엔드포인트는 이 기능을 사용하도록 설정하지 않은 앱에 상태 코드 400 로 응답합니다. 자세한 내용은 “OAuth 앱 권한 부여”를 참조하세요.

리포지토리에 대한 관리자 액세스 권한이 있는 사용자는 리포지토리에 대한 액세스 권한이 있는 사용자를 더 잘 이해하고, 각 사용자에게 있는 액세스 수준을 확인하고, 리포지토리에 대한 액세스를 보다 쉽게 관리할 수 있습니다. 예를 들어 사용자는 다음 작업을 수행할 수 있습니다.

• 리포지토리에 액세스할 수 있는 모든 멤버, 팀 및 협력자를 검색합니다.
• 구성원이 개별로 직접 또는 팀을 통해 간접적으로 부여된 혼합 역할 할당이 있는 경우를 확인합니다. 새 "혼합 역할" 경고는 액세스 권한이 할당된 역할보다 높은 경우 사용자에게 부여되는 가장 높은 수준의 역할을 표시합니다.

자세한 내용은 “리포지토리에 액세스할 수 있는 팀 및 사용자 관리”를 참조하세요.

이제 엔터프라이즈 소유자는 사용자 지정 바닥글에서 엔터프라이즈 멤버 및 협력자에 대한 추가 링크를 표시할 수 있습니다. 자세한 내용은 "사용자 지정 바닥글 구성"을 참조하세요.

사용자는 단일 구성 줄로 워크플로를 다시 사용할 수 있습니다. 재사용 가능한 워크플로는 리포지토리 간에 워크플로 정의를 복사하고 붙여넣을 필요가 없도록 하여 시간과 유지 관리를 절약합니다. 재사용 가능한 워크플로는 베타 버전이며 변경될 수 있습니다. 자세한 내용은 “워크플로 다시 사용”을 참조하세요.

자체 호스팅 실행기에 대한 업데이트된 관리 환경은 실행기 그룹의 관리를 간소화하고 실행기에 대한 향상된 개요를 제공합니다. 자세한 내용은 "자체 호스팅 실행기 정보" 및 "그룹을 사용하여 자체 호스팅 실행기에 대한 액세스 관리"를 참조하세요.

Dependabot은 이제 Dependabot이 워크플로 실행을 트리거할 때 GitHub Actions 비밀을 공유하므로 사용자는 이제 Dependabot의 비밀을 사용하여 CI 파이프라인 내의 프라이빗 패키지 레지스트리에서 가져올 수 있습니다. 자세한 내용은 “Dependabot에 대한 암호화된 비밀 관리”를 참조하세요.

조건을 충족하지 않는 한 사용자는 조건을 사용하여 if 복합 작업의 특정 단계가 실행되지 않도록 할 수 있습니다. 워크플로에 정의된 단계와 마찬가지로 지원되는 컨텍스트 및 식을 사용하여 조건을 만들 수 있습니다. 복합 작업에 대한 자세한 내용은 "복합 작업 만들기"를 참조하세요.

사용자는 수동으로 트리거된 워크플로에 대한 입력 유형을 지정하여 워크플로 사용자에게 더 나은 환경을 제공할 수 있습니다. 워크플로는 이제 , 및 environment를 boolean지원choice합니다. 자세한 내용은 “GitHub Actions의 워크플로 구문”을 참조하세요.

리포지토리, 조직 또는 엔터프라이즈 수준에서 사용 가능한 첫 번째 일치 실행기는 모든 경우에 각 작업을 실행합니다. 즉, 특히 자체 호스팅 실행기가 많은 조직 및 기업에 대해 작업이 훨씬 더 빠르게 자체 호스팅 실행기로 전송됩니다. 이전에는 자체 호스팅 실행기가 필요한 작업을 실행할 때 GitHub Actions 해당 순서대로 리포지토리, 조직 및 엔터프라이즈에서 자체 호스팅 실행기를 찾습니다. 자세한 내용은 "워크플로에서 자체 호스팅 실행기 사용"을 참조하세요.

사용자는 를 로 지정하여 javaScript 작업이 Node.js 16에서 실행되도록 지정할 수 있습니다 runs.using node16. Node.js 16 지원은 Node.js 12에 대한 기존 지원을 보완합니다. 실행기에는 GitHub Actions Runner 버전 2.285.0 이상이 설치되어 있어야 합니다. 자세한 내용은 "GitHub Actions 대한 메타데이터 구문" 및 리포지토리를actions/runner 참조하세요.

사용자는 REST API를 사용하여 자체 호스팅 실행기에 대한 레이블을 추가, 나열 및 제거할 수 있습니다. 자세한 내용은 REST API 설명서의 "자체 호스팅 실행기"를 참조하세요.

사용자는 CodeQL 코드 검사를 사용하여 Ruby로 만든 서비스 및 도구의 보안을 향상시킬 수 있습니다. 3.02를 포함하여 모든 일반적인 Ruby 버전의 경우 CodeQL은 SQL 삽입, ReDoS, OS 명령 및 인수 삽입, XML 엔터티 확장, 반영된 XSS(사이트 간 스크립팅), 저장된 XSS, 안전하지 않은 역직렬화 및 하드 코딩된 자격 증명과 같은 일반적인 문제를 검색할 수 있습니다. Ruby 분석을 사용하도록 설정하려면 사용자가 기존 CodeQL 코드 검사 워크플로 파일을 업데이트해야 합니다. CodeQL에 대한 Ruby 지원은 베타 버전이며 변경될 수 있습니다. 자세한 내용은 "코드 검사 구성" 및 CodeQL 설명서를 참조하세요. CodeQL을 사용하여 코드 검사에 대한 자세한 내용은 "CodeQL을 사용하여 코드 검사 정보"를 참조하세요.

CodeQL의 Python 분석은 추가 프레임워크를 지원하며 신뢰할 수 없는 사용자 데이터의 더 많은 잠재적 원본, 해당 데이터가 흐르는 단계 및 이 데이터가 종료될 수 있는 잠재적으로 위험한 싱크를 검색할 수 있습니다. 자세한 내용은 CodeQL 설명서의 "지원되는 언어 및 프레임워크"를 참조하세요.

사용자는 REST API를 사용하여 프라이빗 리포지토리 검사에서 검색된 비밀의 커밋 세부 정보를 검색할 수 있습니다. 새 엔드포인트는 비밀의 위치 및 커밋 SHA를 포함하여 파일 내에서 비밀의 첫 번째 검색에 대한 세부 정보를 표시합니다. 자세한 내용은 REST API 설명서의 "비밀 검사 정보" 및 "비밀 검사"를 참조하세요.

코드 검사 API에는 다음과 같은 향상된 기능이 포함되어 있습니다.

• 경고에는 분석에서 경고가 처음으로 검색되지 않은 타임스탬프가 포함 fixed_at 됩니다. 사용자는 이 데이터를 사용하여 코드 검사 경고가 수정되는 시기를 더 잘 이해할 수 있습니다.
• 사용자는 , updated또는 number에서 및 direction 를 사용하여 sort 가장 중요한 경고 결과를 정렬할 created수 있습니다. 자세한 내용은 REST API 설명서의 코드 검사를 참조하세요.
• 경고 및 경고 엔드포인트 응답에는 헤더가 Last-Modified 포함됩니다. 자세한 내용은 Mozilla 설명서를 참조 Last-Modified 하세요.
• 코드 검사 분석에 대한 SARIF 응답에는 경고의 기본 위치가 아닌 위치가 포함될 수 있는 가 포함 relatedLocations됩니다. 예제는 SARIF 사양을 참조하세요. 자세한 내용은 REST API 설명서의 코드 검사를 참조하세요.
• 웹후크 응답 경고 규칙 개체에는 및 tags 데이터가 포함됩니다help. 자세한 내용은 “웹후크 이벤트 및 페이로드”를 참조하세요.

조직 소유자 및 보안 관리자는 REST API를 사용하여 엔터프라이즈 수준에서 프라이빗 리포지토리의 비밀 검사 결과를 검색할 수 있습니다. 자세한 내용은 REST API 설명서의 "비밀 검사 정보" 및 "비밀 검사"를 참조하세요.

사용자는 GraphQL API를 통해 Dependabot 경고를 해제할 수 있습니다. 자세한 내용은 GraphQL API 설명서의 "변형"을 참조하세요.

종속성 그래프는 시 패키지 관리자를 사용하는 리포지토리에서 Python 종속성을 검색합니다. 및 매니페스트 파일 모두에서 pyproject.toml poetry.lock 종속성이 검색됩니다. 자세한 내용은 “종속성 그래프 정보”를 참조하세요.

개발자와 보안 연구원은 CodeQL을 사용하여 데이터베이스를 빌드하고 M1과 같은 Apple 실리콘 칩으로 구동되는 컴퓨터에서 코드를 분석할 수 있습니다. CodeQL CLI 및 VS Code 확장은 모두 Apple 실리콘을 지원합니다. Apple 실리콘에서 CodeQL CLI 또는 VS Code 확장을 사용하려면 사용자가 Xcode 명령줄 개발자 도구 및 Rosetta 2를 설치해야 합니다. Apple 실리콘에 대한 CodeQL 지원은 베타 버전이며 변경될 수 있습니다.

• 지원되는 플랫폼에서 CodeQL CLI의 구성에 대한 자세한 내용은 CodeQL 설명서의 "CodeQL CLI 사용"을 참조하세요.
• CodeQL에 대한 자세한 내용은 CodeQL 설명서의 "CodeQL 정보" 및 "코드 검사 정보"를 참조하세요.

CodeQL CLI 버전 2.7.1 이상 사용자는 SARIF 파일에 쿼리 도움말을 Markdown으로 포함할 수 있으며 도움말 텍스트는 GitHub AE의 코드 검사 UI에 표시됩니다. 사용자는 해당 쿼리 파일과 이름이 같은 Markdown 파일로 쿼리 도움말을 포함할 수 있습니다. 예를 들어 쿼리 파일이 인 MyCustomQuery.ql경우 쿼리 도움말 파일의 이름은 입니다 MyCustomQuery.md. 사용자 지정 CodeQL 쿼리에 대한 쿼리 도움말 작성에 대한 자세한 내용은 쿼리 도움말 스타일 가이드를 참조하세요.

• CI/CD 및 코드 검사에 GitHub Actions 사용하지 않는 사용자는 플래그를 포함하여 명령을 실행할 codeql database analyze 때 쿼리 도움말 추가를 --sarif-add-query-help 지정해야 합니다. 자세한 내용은 CodeQL 설명서의 "CodeQL CLI를 사용하여 데이터베이스 분석"을 참조하세요.

사용자는 지정된 사용자 또는 조직이 소유한 모든 리포지토리에서 구독을 취소할 수 있습니다. 자세한 내용은 “구독 관리”를 참조하세요.

조직 소유자는 조직에 속한 리포지토리에 새 배포 키가 추가되면 이메일 알림에서 구독을 취소할 수 있습니다. 자세한 내용은 “알림 구성”을 참조하세요.

문제 및 끌어오기 요청에 대한 전자 메일 알림의 제목 줄에는 사용자가 두 알림 유형을 쉽게 구분할 수 있도록 "(문제 #NUMBER)" 또는 "(PR #NUMBER)"가 포함됩니다.

전자 메일 알림 아래쪽 의 GitHub에서 보기 링크는 Gmail에서 기본적으로 더 이상 숨겨지지 않습니다.

이제 조직 구성원이 엔터프라이즈 소유자 목록을 볼 수 있습니다. 조직 구성원이 엔터프라이즈 소유자에게 문의하라는 메시지가 표시될 때마다 링크가 사용자를 목록으로 안내합니다. 엔드포인트에서 enterpriseOwners GraphQL API의 Organization 개체를 사용하여 목록에 액세스할 수도 있습니다. 자세한 내용은 “조직의 사용자 역할 보기”를 참조하세요.

리포지토리에 대한 관리자 액세스 권한이 있는 사용자는 분기 보호 규칙으로 보호되는 분기의 이름을 바꿀 수 있습니다. 자세한 내용은 "분기 이름 바꾸기" 및 "분기 보호 규칙 관리"를 참조하세요.

사용자가 모두 또는 전혀 강제 푸시할 수 없도록 허용하는 대신 리포지토리에 대한 관리자 액세스 권한이 있는 사용자는 리포지토리에 강제 푸시할 수 있는 사용자를 선택할 수 있습니다. 자세한 내용은 "보호된 분기 정보" 및 "분기 보호 규칙 관리"를 참조하세요.

리포지토리에 대한 관리자 액세스 권한이 있는 사용자는 검토 없이 끌어오기 요청을 사용하여 보호된 분기에 대한 모든 변경 내용을 적용하도록 요구할 수 있습니다. 자세한 내용은 "보호된 분기 정보" 및 "분기 보호 규칙 관리"를 참조하세요.

리포지토리에 대한 관리자 액세스 권한이 있는 사용자는 특정 사용자와 팀이 끌어오기 요청 요구 사항을 무시할 수 있습니다. 자세한 내용은 “분기 보호 규칙 관리”를 참조하세요.

사용자는 사용자 지정 자동 링크에 단일 문자 접두사를 사용할 수 있습니다. 자동 링크 접두사는 영숫자뿐만 아니라 , -, =``_``:``+, /, 문자 # 도 허용.합니다. 자세한 내용은 “외부 리소스를 참조하도록 자동 링크 구성”을 참조하세요.

사용자는 팀의 코드 검토 설정에서 자동 할당 사용과 독립적으로 요청된 팀 구성원에게만 알림을 사용하도록 설정할 수 있으므로 사용자는 항상 팀 전체에 불필요하게 알리지 않고도 팀에 검토를 요구할 수 있습니다. 자세한 내용은 “팀의 코드 검토 설정 관리”를 참조하세요.

릴리스 UI가 개선되어 지정된 릴리스에 포함된 내용에 대한 명확성과 릴리스 참가자에 대한 인식을 제공합니다. 페이지 매김이 개선되고 새로운 검색 기능을 사용할 수 있습니다.

사용자는 지정된 릴리스에 대한 모든 끌어오기 요청의 요약을 포함하는 릴리스 정보를 자동으로 생성할 수 있습니다. 자세한 내용은 "자동으로 생성된 릴리스 정보"를 참조하세요.

사용자는 gists에서 Markdown 파일의 렌더링을 미리 볼 수 있습니다. Markdown 파일 확장자를 .md사용하여 gist 파일을 만들거나 편집할 때 미리 보기 또는 미리 보기 변경 내용 탭에 파일 내용의 Markdown 렌더링이 표시됩니다. Gist에 관한 자세한 내용은 “Gist가 있는 콘텐츠의 편집 및 공유”를 참조하세요.

사용자는 문제 및 끌어오기 요청에 대한 메모와 같은 Markdown 필드에서 고정 너비 글꼴을 사용하도록 선택할 수 있습니다. 자세한 내용은 "GitHub에서 작성 및 서식 지정 정보"를 참조하세요.

사용자는 Markdown에서 이미지가 표시되는 테마를 지정할 수 있습니다. 자세한 내용은 “기본 쓰기 및 서식 지정 구문”을 참조하세요.

사용자는 텍스트를 선택한 다음 URL을 붙여넣어 이슈 또는 끌어오기 요청 주석과 같은 Markdown 사용 필드에서 텍스트를 편집하는 동안 Markdown 링크를 빠르게 만들 수 있습니다.

사용자가 Markdown 필드에 붙여넣는 HTML 링크는 자동으로 Markdown 링크로 변환됩니다. HTML 링크를 일반 텍스트로 붙여넣려면 ⌘/ctrl + shift + v를 누릅니다.

오른쪽에서 왼쪽 언어는 이슈, 끌어오기 요청 및 토론의 Markdown 파일 및 주석에서 기본적으로 지원됩니다.

사용자는 기본 탭 크기를 설정할 수 있습니다. 탭이 있는 GitHub AE의 모든 코드는 기본 탭 크기를 사용하여 렌더링됩니다. 자세한 내용은 "탭 크기 렌더링 기본 설정 관리"를 참조하세요.

사용자는 GitHub AE의 새로운 접근성 설정을 사용하여 바로 가기 키를 관리할 수 있으며, s, g c 및 와 같은 단일 문자만 사용하는 문자 키 바로 가기를 사용하지 않도록 선택할 수 있습니다 . (기간 키). 자세한 내용은 "접근성 설정 관리"를 참조하세요.

모든 변경 내용이 의도한 앱에서 유효성을 검사하도록 하려면 이제 사용자가 필요한 상태 확인이 제공되는 GitHub 앱을 제어할 수 있습니다. 그런 다음 다른 앱 또는 커밋 상태를 통해 사용자가 상태를 제공하는 경우 병합이 방지됩니다. 기존 필수 상태 검사는 모든 앱의 상태를 계속 수락하지만 특정 앱의 상태만 허용하도록 업데이트할 수 있습니다. 새로 추가된 필수 상태 검사는 가장 최근에 상태를 보고한 앱으로 기본 설정되지만 다른 앱을 선택하거나 모든 앱이 상태를 제공하도록 허용할 수 있습니다. 자세한 내용은 "보호된 분기 정보" 및 "분기 보호 규칙 편집"을 참조하세요.

리포지토리에 대한 관리자 액세스 권한이 있는 조직 소유자 및 사용자는 웹후크를 트리거하여 분기 보호 규칙의 변경 내용을 수신 대기할 수 있습니다. 자세한 내용은 “웹후크 이벤트 및 페이로드”를 참조하세요.

이제 코드 검사 및 비밀 검사가 GitHub AE에 일반 공급됩니다. 자세한 내용은 "코드 검사 정보" 및 "AUTOTITLE"을 참조하세요.

이제 비밀 검사에 대한 사용자 지정 패턴이 일반 공급됩니다. 자세한 내용은 "비밀 검사를 위한 사용자 지정 패턴 정의"을 참조하세요.

이제 코드 검사 경고 페이지에서 새 끌어오기 요청 필터를 사용하여 끌어오기 요청과 연결된 모든 코드 검사 경고를 찾을 수 있습니다. 끌어오기 요청 검사 페이지에는 끌어오기 요청에 도입된 경고가 표시되지만 끌어오기 요청 분기의 기존 경고는 표시되지 않습니다. 검사 페이지의 새 "모든 분기 경고 보기" 링크는 특정 끌어오기 요청 필터가 이미 적용된 코드 검사 경고 페이지로 이동하므로 끌어오기 요청과 연결된 모든 경고를 볼 수 있습니다. 이는 많은 경고를 관리하고 개별 경고에 대한 자세한 정보를 확인하는 데 유용할 수 있습니다. 자세한 내용은 “리포지토리에 대한 코드 검사 경고 관리를 참조하세요.

이제 GitHub Advanced Security 코드 검사, Dependabot 및 비밀 검사로 감지된 애플리케이션 보안 위험에 대한 조직 수준 보기를 제공합니다. 보안 개요는 각 리포지토리의 보안 기능 사용 상태와 검색된 경고 수를 보여 줍니다.

또한 보안 개요에는 조직 수준의 모든 비밀 검사 경고가 나열됩니다. Dependabot 및 코드 검사 경고에 대한 유사한 보기는 향후 릴리스에서 제공될 예정입니다. 자세한 내용은 “보안 개요 정보”를 참조하세요.

이제 GitHub AE에서 종속성 그래프를 사용할 수 있습니다. 종속성 그래프를 사용하면 리포지토리에 체크 인된 종속성 매니페스트를 구문 분석하여 사용하는 오픈 소스 소프트웨어를 이해할 수 있습니다. 자세한 내용은 “종속성 그래프 정보”를 참조하세요.

이제 Dependabot 경고는 GitHub AE에 대한 종속성의 취약성을 알릴 수 있습니다. 종속성 그래프를 사용하도록 설정하고, GitHub Connect를 사용하도록 설정하고, GitHub Advisory Database에서 취약성을 동기화하여 Dependabot 경고를 사용하도록 설정할 수 있습니다. 이 기능은 베타 버전이며 변경될 수 있습니다. 자세한 내용은 "Dependabot 경고 정보"를 참조하세요.

Dependabot 경고를 사용하도록 설정하면 해당 종속성에 영향을 주는 새 취약성이 GitHub Advisory Database에 추가되거나 취약한 종속성이 매니페스트에 추가될 때마다 조직의 구성원이 알림을 받게 됩니다. 구성원은 알림 설정을 사용자 지정할 수 있습니다. 자세한 내용은 "%data variables.product.prodname_dependabot_alerts %}에 대한 알림 구성"을 참조하세요.

이제 조직은 모든 리포지토리에서 보안 경고 및 설정을 관리할 수 있는 권한을 팀에 부여할 수 있습니다. "보안 관리자" 역할은 모든 팀에 적용할 수 있으며 팀 구성원에게 다음 권한을 부여합니다.

• 조직의 모든 리포지토리에 대한 읽기 권한
• 조직의 모든 보안 경고에 대한 쓰기 액세스
• 조직 수준 보안 탭에 대한 액세스
• 조직 수준에서 보안 설정에 대한 쓰기 액세스
• 리포지토리 수준에서 보안 설정에 대한 쓰기 액세스

자세한 내용은 "조직의 보안 관리자 관리"를 참조하세요.

이제 GitHub AE는 자동 크기 조정 실행기를 더 쉽게 만들 수 있도록 임시(단일 작업) 자체 호스팅 실행기와 새 workflow_job 웹후크를 지원합니다.

임시 실행기는 각 작업이 깨끗한 이미지에서 실행해야 하는 자체 관리 환경에 적합합니다. 작업이 실행되면 GitHub AE에서 임시 실행기를 자동으로 등록 취소하여 작업 후 관리를 수행할 수 있습니다.

임시 실행기를 새 workflow_job 웹후크와 결합하여 GitHub Actions 작업 요청에 따라 자체 호스팅 실행기를 자동으로 스케일링할 수 있습니다.

자세한 내용은 "자체 호스팅 실행기를 사용하여 자동 크기 조정" 및 "웹후크 이벤트 및 페이로드"를 참조하세요.

컴퍼지션을 사용하여 다른 작업을 참조하여 워크플로에서 중복을 줄일 수 있습니다. 이전에는 YAML로 작성된 작업은 스크립트만 사용할 수 있었습니다. 자세한 내용은 "복합 작업 만들기"를 참조하세요.

엔터프라이즈 수준에서 자체 호스팅 실행기를 관리하려면 더 이상 범위와 함께 admin:enterprise 개인용 액세스 토큰을 사용할 필요가 없습니다. 대신 범위를 사용하여 new manage_runners:enterprise 토큰에 대한 권한을 제한할 수 있습니다. 이 범위의 토큰은 많은 REST API 엔드포인트에 인증하여 엔터프라이즈의 자체 호스팅 실행기를 관리할 수 있습니다.

이제 REST API를 사용하여 감사 로그와 프로그래밍 방식으로 인터페이스할 수 있습니다. 감사 로그 전달은 사용자 고유의 도구 키트를 사용하여 데이터를 보존 및 분석하고 시간이 지남에 따라 패턴을 결정하는 기능을 제공하지만, 새로운 REST API는 최근 기록에서 발생한 메모 이벤트에 대해 제한된 분석을 수행하는 데 도움이 됩니다. 자세한 내용은 “조직의 감사 로그 검토”를 참조하세요.

이제 새 개인용 액세스 토큰과 기존 개인용 액세스 토큰에 대한 만료 날짜를 설정할 수 있습니다. 만료될 토큰을 갱신할 때 GitHub AE에서 전자 메일을 보냅니다. 만료된 토큰을 다시 생성하여 원본과 동일한 속성을 가진 중복 토큰을 제공할 수 있습니다. GitHub AE API와 함께 토큰을 사용하는 경우 토큰의 만료 날짜를 나타내는 새 헤더 GitHub-Authentication-Token-Expiration가 표시됩니다. 예를 들어 스크립트에서 이를 사용하여 만료 날짜가 다가오면 경고 메시지를 기록할 수 있습니다. 자세한 내용은 "개인용 액세스 토큰 만들기" 및 "REST API 시작"을 참조하세요.

이제 조직 소유자는 CSV 형식으로 리포지토리에 액세스할 수 있는 사용자 목록을 내보낼 수 있습니다. 자세한 내용은 "리포지토리에 액세스할 수 있는 사용자 보기"를 참조하세요.

코드 검토 할당 코드 검토 할당을 관리하는 새로운 설정은 팀의 끌어오기 요청 검토를 팀 구성원에 분산하는 데 도움이 되므로 검토는 한두 명의 팀 구성원만을 담당하지 않습니다.

• 자식 팀 구성원: 팀의 직접 구성원으로만 할당을 제한합니다. 이전에는 팀 검토 요청을 팀 구성원 또는 하위 팀 구성원에게 할당할 수 있었습니다.
• 기존 요청 수: 팀의 구성원이 하나 이상 이미 요청된 경우에도 자동 할당을 계속합니다. 이전에는 이미 요청된 팀 구성원이 팀의 자동 검토 요청 중 하나로 계산되었습니다.
• 팀 검토 요청: 하나 이상의 구성원이 새로 할당된 경우에도 검토하도록 팀을 할당된 상태로 유지합니다.

자세한 내용은 “팀의 코드 검토 설정 관리”를 참조하세요.

GitHub AE 웹 UI에는 두 가지 새로운 테마를 사용할 수 있습니다.

• 전경 요소와 배경 요소 간의 대비가 더 큰 어두운 고대비 테마
• 빨강과 녹색과 같은 색을 주황색과 파란색으로 바꾸는 밝은 색맹과 어두운 색맹

자세한 내용은 “테마 설정 관리”를 참조하세요.

이제 모든 Markdown 필드에서 각주 구문을 사용하여 산문의 흐름을 방해하지 않고 관련 정보를 참조할 수 있습니다. 각주가 위 첨자 링크로 표시됩니다. 각주를 클릭하여 문서 아래쪽의 새 섹션에 표시된 참조로 이동합니다. 자세한 내용은 “기본 쓰기 및 서식 지정 구문”을 참조하세요.

이제 단추를 클릭하여 Markdown 파일 맨 위에 있는 "소스 차이 표시"를 클릭하여 웹 UI를 통해 원본 보기와 렌더링된 Markdown 보기 간에 전환할 수 있습니다. 이전에는 책임 보기를 사용하여 Markdown 파일 원본의 특정 줄 번호에 연결해야 했습니다.

이제 GitHub AE는 제목에 따라 Wiki에 대한 목차를 자동으로 생성합니다.

GitHub Actions is a powerful, flexible solution for CI/CD and workflow automation. For more information, see "GitHub Actions 이해."

Please note that when GitHub Actions is enabled during this upgrade, two organizations named "GitHub Actions" (@actions and @github) will appear in 엔터프라이즈. These organizations are required by GitHub Actions. Users named @ghost and @actions appear as the actors for creation of these organizations in the audit log.

GitHub Packages is a package hosting service, natively integrated with GitHub Actions, APIs, and webhooks. Create an end-to-end DevOps workflow that includes your code, continuous integration, and deployment solutions. During this beta, GitHub Packages is offered free of charge to GitHub AE customers.

GitHub Advanced Security is available in beta and includes both code scanning and secret scanning. During this beta, GitHub Advanced Security features are being offered free of charge to GitHub AE customers. Repository and organization administrators can opt-in to use GitHub Advanced Security in the Security and Analysis tab under settings.

Learn more about GitHub Advanced Security code scanning and secret scanning on GitHub AE.

Customers using SCIM (System for Cross-domain Identity Management) can now sync security groups in Azure Active Directory with GitHub teams. Once a team has been linked to a security group, membership will be automatically updated in GitHub AE when a user is added or removed from their assigned security group.

GitHub IP allow lists provide the ability to filter traffic from administrator-specified IP ranges, defined by CIDR notation. The allow list is defined at the enterprise or organization account level in Security > Settings. All traffic that attempts to reach resources within the enterprise account and organizations are filtered by the IP allow lists. This functionality is provided in addition to the ability to request network security group changes that filter traffic to the entirety of the GHAE tenant.

Organization owners can now disable publication of GitHub Pages sites from repositories in the organization. This will not unpublish existing sites.

Repositories that use GitHub Pages can now build and deploy from any branch.

When writing an issue or pull request, the list syntax for bullets, numbers, and tasks will now be autocompleted after you press return or enter.

You can now delete a directory in a repository from the repository page. When navigating to a directory, a new kebab button next to the "Add file" button gives the option to delete the directory.

It's now easier and faster to reference issues or pull requests, with search across multiple words after the "#".

Enterprise owners can now publish a mandatory message. The message is shown to all users and they must acknowledge it. This can be used to display important information, terms of service or policies.

The GitHub App single file path permission can now support up to ten files.

When configuring a GitHub App, the authorization callback URL is a required field. Now we will permit the integrator to specify multiple callback URLs. GitHub AE denies authorization if the callback URL from the request is not listed.

A new API endpoint enables the exchange of a user to server token for a user to server token scoped to specific repositories.

Events are now logged in the audit log on promoting a team member to be a team maintainer and on demoting a team maintainer to be a team member.

The OAuth device authorization flow is now supported. This allows any CLI client or developer tool to authenticate using a secondary system.

A user can no longer delete their account if SCIM provisioning is enabled.

Enterprise and organization owners can now set the default branch name for new repositories. Enterprise owners can also enforce their choice of default branch name across all organizations or allow individual organizations to choose their own.

Existing repositories are unaffected by these settings, and their default branch name will not be changed.

This change is one of many changes GitHub is making to support projects and maintainers that want to rename their default branch. To learn more, see github/renaming.

Users can no longer set a backup email address on their profile. Their email address is set through the IdP only.

You can no longer enable two-factor authentication after configuring authentication through your IdP.

GitHub AE can now connect to Azure Boards.

Version headers were missing from the APIs, and have now been set to "GitHub AE."

Links to documentation have been fixed.

Configuration of audit log forwarding within the enterprise's settings was failing.

Navigating to gists could result in a 500 error.

The Support email or URL was failing to save. It now saves after a period of a few minutes.

Organization level pull request templates were not being applied to all pull requests in the organization.