Git 2.48의 주요 내용 – GitHub 블로그 - 최신 기술 뉴스 정보 모두

오픈 소스 Git 프로젝트는 Git 2.48 출시 93명이 넘는 기여자의 기능과 버그 수정이 포함되어 있으며 그 중 35명은 새로운 기여자입니다. 2.47이 출시되었을 때 Git의 최신 소식을 마지막으로 알려드렸습니다.

최신 릴리스를 기념하기 위해 지난번 이후 소개된 가장 흥미로운 기능과 변경 사항 중 일부를 GitHub에서 살펴보겠습니다.

보안을 손상시키지 않으면서 더 빠른 SHA-1

Git의 2.47 릴리스에 대한 기사를 발표했을 때 우리는 주기의 마지막 부분에 적용된 몇 가지 성능 변경 사항을 언급하지 않았습니다. 이 버전에는 이러한 변경 사항과 관련된 버그 수정이 포함되어 있으므로 지금이 그 어느 때보다 좋은 시기라고 생각했습니다.^{그러한 변화를 논의하기 위해.}

Git이 기본적으로 SHA-1 해시를 사용하여 리포지토리 내의 개체를 식별한다는 사실을 알고 계실 것입니다. (우리 대신 SHA-256을 기본 해시 함수로 사용하는 Git의 기능을 다루었지만 이 짧은 이야기에서는 SHA-1 모드의 Git에 중점을 둘 것입니다. 여러분이 알지 못할 수도 있는 사실은 Git이 내부적으로도 몇 군데에서 SHA-1 해시를 사용한다는 것입니다. 우리의 목적에서 가장 주목할만한 점은 팩 형식 이전 바이트의 체크섬을 저장하는 후행 SHA-1을 포함합니다. Git은 이 데이터를 사용하여 팩의 내용이 광고된 내용과 일치하고 운송 중에 손상되지 않았는지 확인합니다.

기본적으로 Git은 SHA-1의 충돌 감지 구현을 사용하여 다음과 같은 일반적인 SHA-1 공격에 대해 이를 강화합니다. 부서진 그리고 도살장. (GitHub는 충돌 감지 SHA-1 구현도 사용합니다). 충돌 감지 SHA-1 구현은 Git을 충돌 공격으로부터 보호하지만 체크섬 중에 이러한 공격의 숨길 수 없는 징후를 찾기 위해 몇 가지 추가 CPU 주기를 희생합니다.

대부분의 경우 성능에 미치는 영향은 미미하며 이점이 사소한 성능 비용보다 더 큽니다. 그러나 대규모 저장소를 복제할 때와 같이 대규모 팩의 체크섬을 계산할 때는 비용이 추가됩니다. 예를 들어, 우리는 콜그라인드 Git은 시뮬레이션된 복제 중에 체크섬을 계산하는 데 CPU의 약 78%를 소비하는 것으로 측정되었습니다. torvalds/linux.

다행스럽게도 후행 체크섬은 보안이 아닌 데이터 무결성 측정입니다. 우리의 목적에 따라 이는 특히 후행 체크섬을 계산할 때 보안을 손상시키지 않고(다른 곳은 아님) 더 빠르고 충돌을 감지하지 않는 SHA-1 구현을 안전하게 사용할 수 있음을 의미합니다. Git 2.47에는 후행 체크섬을 계산할 때 특별히 사용되는 별도의 해시 함수 구현을 지정하는 새로운 빌드 타임 옵션이 도입되었습니다. GitHub는 이 옵션을 사용했으며 그 결과 모든 리포지토리에서 가져오기/복제를 제공할 때 성능이 10-13% 향상되는 것으로 측정되었습니다.

다음을 사용하여 대체 해시 함수 구현을 선택하는 Git의 기능을 시험해 볼 수 있습니다. make OPENSSL_SHA1_UNSAFE=1또는 기타 _UNSAFE 변형.

[source, source, source]

가져오기 `--remerge-diff` 범위 차이에

이 시리즈를 정기적으로 읽는 독자들은 의심할 여지 없이 우리가 보도한 내용을 기억할 것입니다. Git의 range-diff 명령(Git 2.19에서 다시 도입됨) 및 최신 –remerge-diff 옵션(Git 2.36에서 출시됨). 당신이 처음 독자이거나 둘 다 당신에게 종소리를 울리지 않는 경우에도 걱정하지 마십시오. 여기에 간단한 복습이 있습니다.

힘내 range-diff 명령을 사용하면 두 개를 비교할 수 있습니다 시퀀스 순서 변경, 커밋 메시지 및 실제 콘텐츠 변경 사항을 포함한 커밋의 수입니다. 이는 리베이스된 일련의 커밋(패치 내에서 순서와 변경 사항을 잠재적으로 조정할 수 있음)과 리베이스 이전의 커밋 세트의 모습을 비교할 때 유용할 수 있습니다.

힘내 --remerge-diff 옵션이 알려준다 git show, git log또는 다양한 diff 관련 명령을 사용하여 Git이 병합으로 인해 중지된 위치와 병합에 기록된 내용 간의 차이점을 확인할 수 있습니다. 이는 병합 충돌을 처리할 때 유용할 수 있습니다. --remerge-diff 보기에서는 충돌과 해결 방법의 차이를 보여 주며, 주어진 병합 충돌이 어떻게 처리되었는지 보여줍니다.

Git 2.48에서는 이 두 기능이 처음으로 만났습니다. range-diff 이제 --remerge-diff 옵션을 사용하면 누군가가 다음과 같이 커밋 시퀀스를 리베이스하는 경우 --rebase-merges 잠재적으로 일부 변경이 필요한 경우 병합 커밋의 변경 사항을 범위 비교의 일부로 검토할 수도 있습니다.

이 작업의 부작용으로, --remerge-diff 또한 수정되었으며, 특히 이를 통해 git log –remerge-diff 커밋 순회 순서를 변경하는 옵션(예: --reverse).

[source, source]

Git의 메모리 누수 없는 테스트

시작 Git 2.34부터 Git 프로젝트는 Git 프로젝트를 줄이는 데 중점을 두었습니다. 메모리 누수 궁극적으로 Git 누출을 방지하는 것을 목표로 합니다. Git은 명령줄 도구이기 때문에 각 실행은 일반적으로 짧은 시간 동안만 지속되며, 그 후에 커널은 Git 자체에서 해제하지 않은 Git에 할당된 메모리를 해제합니다. 이로 인해 Git의 메모리 누수는 일상적인 사용에 있어 심각한 실제 문제를 일으키지 않았습니다.

그러나 Git에서 메모리 누수가 발생하면 Git 내부의 대부분을 호출 가능한 라이브러리로 변환하기가 어려워지며, 여기서 메모리 누수는 심각한 문제가 됩니다. 이 문제를 해결하기 위해 Git 코드베이스의 메모리 누수 수를 줄이기 위해 수년 동안 공동의 노력을 기울여 왔으며 궁극적인 목표는 메모리 누수를 완전히 제거하는 것입니다.

이를 위해 많은 노력을 기울인 끝에 Git은 이제 누수 검사를 활성화한 상태에서 테스트 스위트를 성공적으로 실행할 수 있습니다. 만족스러운 최종 결과로 우리가 2.34에서 이야기했던 테스트 인프라의 대부분이 제거되어 테스트 인프라가 더욱 단순해졌습니다. Git 메모리 누수를 방지한다는 것은 Git 내부의 일부를 호출 가능한 라이브러리로 변환할 수 있다는 점에서 상당한 진전을 의미합니다.

[source, source, source, source, source, source, source, source, source, source, source, source]

Git에 Meson 소개

Git 프로젝트는 다음을 사용합니다. GNU 메이크 Git을 컴파일하는 기본 수단입니다. 즉, Git 소스의 복사본을 얻을 수 있다면 다음을 실행하세요. make 작동하는 Git 바이너리를 얻는 데 필요한 전부입니다(필요한 종속성이 있는 경우 등). 몇 가지 예외가 있습니다. 즉, Git은 Autoconf 및 CMake를 일부 지원하지만 Git만큼 최신 상태는 아닙니다. Makefile.

그러나 Git 프로젝트가 올해 말 20주년을 맞이하면서 Makefile 나이가 보이기 시작합니다. 있었습니다 2,000개 이상의 커밋 에 Makefile결과적으로 거의 4,000줄 길이의 빌드 스크립트가 생성됩니다.

이번 릴리스에서 Git 프로젝트는 새로운 빌드 시스템을 지원합니다. 중간자GNU Make를 사용하여 빌드하는 대신 사용할 수 있습니다. Meson에 대한 지원은 아직 Make를 사용한 구축만큼 강력하지는 않지만 Meson은 Make에 비해 몇 가지 이점을 제공합니다. Meson은 Make보다 사용하기 쉽기 때문에 Make를 사용한 경험이 많지 않은 신규 사용자나 기여자가 프로젝트에 더 쉽게 접근할 수 있습니다. Meson은 또한 광범위한 IDE 지원을 제공하며 Git 프로젝트의 중요한 자산인 트리 외부 및 크로스 플랫폼 빌드를 지원합니다.

Git은 가까운 미래에 Meson 외에도 Make 및 CMake에 대한 지원을 유지하고 Autoconf에 대한 지원도 좀 더 오랫동안 유지할 것입니다. 하지만 Git의 최신 빌드 시스템을 실험해보고 싶다면 다음을 실행하세요. meson setup build && ninja -C build Git 2.48 이상의 새 복사본을 사용하세요.

[source]

Git 프로젝트가 수년에 걸쳐 성장함에 따라 처음 도입되었을 때는 합리적이었지만 이후 구식이 되거나 대체되어 이제는 더 이상 사용되지 않는 여러 기능과 모드가 축적되었습니다. Git 2.48에서 Git 프로젝트는 현재 더 이상 사용되지 않는 기능을 다음 위치에 저장된 목록으로 수집하기 시작했습니다. Documentation/BreakingChanges.txt.
이 문서를 통해 Git 프로젝트는 특정 기능의 지원 중단에 대해 논의하고 프로젝트에서 예상되는 지원 중단 사항을 한 곳에서 수집할 수 있습니다. 다른 측면에서는 사용자가 향후 지원 중단으로 인해 영향을 받을 수 있는지 확인하고 특정 기능의 사용 사례를 프로젝트와 공유할 수 있습니다. 목록에서 놓칠 수 있는 내용이 있는지 확인하고 최종 Git 3.0 릴리스가 어떤 모습일지 초기 그림을 얻으려면 확인하세요!

[source]
저장소의 참조를 중심으로 스크립트를 작성해 본 적이 있다면 Git의 내용에 익숙할 것입니다. for-each-ref 명령. 그렇지 않은 경우에는 for-each-ref 저장소의 참조를 나열하고 사용자 정의 형식 지정자를 적용하는 등의 작업을 수행할 수 있는 유연한 도구입니다.

Git 2.44에서 우리는 다음에 대해 이야기했습니다. 일부 성능 개선 그게 허용됐어 git for-each-ref 참조 필터링과 형식 지정을 동일한 코드 경로로 결합하여 특정 조건에서 결과를 저장하고 정렬할 필요가 없어 훨씬 더 빠르게 실행할 수 있습니다.

Git 2.48은 (특정 조건에서) 정렬된 순서로 참조를 출력하라는 요청을 받는 경우에도 동일한 최적화를 활용할 수 있도록 하여 이러한 변경 사항을 확장합니다. 해당 조건만 충족된다면, 적은 수의 레퍼런스도 빠르게 출력할 수 있습니다. --sort=refname 저장소에 실제로 있는 참조 수와는 관계가 없습니다.

[source]
우리가 참조 주제에 관해 이야기하는 동안, 재활용 가능한 하위 시스템 이번 릴리스에서는 좀 더 많은 관심을 받았습니다. Git의 Reftable 구현은 Git의 일부 편의 API에 대한 명시적 종속성을 피하기 위해 업데이트되었으며, 이를 통해 Reftable 코드를 컴파일할 수 있는 기능이 더욱 발전했습니다. libgit.a. 프로세스를 즉시 종료하는 대신 메모리 할당 실패를 적절하게 처리하도록 Reftable 구현도 업데이트되었습니다. 마지막으로, 참조 반복자를 재사용할 수 있도록 참조 가능 코드가 업데이트되어 참조 생성 속도가 빨라지고 참조 가능 코드를 사용할 때 메모리 사용량이 낮아졌습니다.

Reftable에 대한 자세한 내용은 이전 Reftable 기사를 확인하세요.

[source, source, source, source]
원격 저장소에서 복제하면 원격 저장소에서 사용하는 기본 분기가 반영됩니다. refs/remotes/origin/HEAD 장소 상에서^{. 이전 버전의 Git에서는 후속 가져오기 및 가져오기 작업이 이 기호 참조를 업데이트하지 않았습니다. Git 2.48을 사용하면 원격에 기본 분기가 있지만 refs/remotes/origin/HEAD 로컬에서 누락된 경우 가져오기를 통해 업데이트됩니다.}

한 단계 더 나아가고 싶다면 다음과 같이 설정할 수 있습니다. remote.origin.followRemoteHead 구성 warn 또는 always; 그렇게 한다면 언제 refs/remotes/origin/HEAD 이미 존재하지만 원격 측의 기본 분기와 일치하지 않는 경우 실행하면 git fetch 변경 사항에 대해 경고하거나 자동으로 업데이트됩니다. refs/remote/origin/HEAD 사용한 설정에 따라 적절한 값으로 설정합니다.

[source, source]
부분 복제 역시 이번 주기에서 큰 사랑을 받았습니다. 무한 루프를 수정하고 약속자 이후 저장소를 손상시킬 수 있는 비-약속자 참조에 대한 약속자를 피하는 것입니다. git gc.

부분 복제에 익숙하지 않거나 내부에 대해 자세히 알아보고 싶은 경우 “부분 복제 및 얕은 복제로 속도 높이기” 가이드를 읽어보세요.

[source, source, source, source]