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

오픈 소스 Git 프로젝트는 94명 이상의 기여자(그 중 33명은 신규 기여자)의 기능과 버그 수정이 포함된 Git 2.52를 방금 출시했습니다. Git 2.51이 출시되었을 때 최신 소식을 마지막으로 전해드렸습니다.

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

숙련된 Git 사용자라면 특정 파일 경로에서 각 줄을 가장 최근에 수정한 커밋을 알아내는 Git 도구인 git Blame에 대해 잘 알고 있을 것입니다. Git의 비난 기능은 버그가 발생한 시기나 일부 코드가 왜 그런 방식으로 작성되었는지 알아내는 데 유용합니다.

특정 파일 경로의 일부를 마지막으로 수정한 커밋을 알고 싶다면 다음과 같이 하면 됩니다. git log -1 -- path/to/my/file~부터 -1 해당 경로를 수정하는 첫 번째 커밋만 제공합니다. 하지만 그 대신 일부 디렉터리의 모든 파일을 가장 최근에 수정한 커밋이 무엇인지 알고 싶다면 어떻게 해야 할까요? 그 질문에 대답하는 것은 인위적인 것처럼 보일 수도 있지만 그렇지 않습니다. GitHub에서 저장소의 파일 목록을 본 적이 있다면 정보의 중간 열에 커밋 메시지(일부)와 함께 해당 경로를 가장 최근에 수정한 커밋에 대한 링크가 있습니다.

GitHub 저장소 파일의 스크린샷. — *트리 수준 비난 정보를 보여주는 GitHub의 저장소 파일 목록입니다.*

문제는 남아 있습니다. 주어진 디렉토리에서 각 파일을 가장 최근에 수정한 커밋을 어떻게 효율적으로 확인할 수 있습니까? 각 트리 항목을 열거하여 다음 항목에 제공할 수 있다고 상상할 수 있습니다. git log -1 다음과 같이 출력을 수집합니다.

$ git ls-tree -z --name-only HEAD^{tree} | xargs -0 -I{} sh -c '
    git log -1 --format="$1 %h %s" -- $1
  ' -- {}  | column -t -l3 
.cirrus.yml     1e77de10810  ci: update FreeBSD image to 14.3
.clang-format   37215410730  clang-format: exclude control macros from SpaceBeforeParens
.editorconfig   c84209a0529  editorconfig: add .bash extension
.gitattributes  d3b58320923  merge-file doc: set conflict-marker-size attribute
.github         5db9d35a28f  Merge branch 'js/ci-github-actions-update'
[...]

그것은 효과가 있지만 효율적이지는 않습니다. 이유를 알아보려면 파일 사례를 살펴보세요. A, B그리고 C 커밋으로 도입됨 C1, C2그리고 C3각기. 비난하다 A우리는 걸어서 C3 다시 C1 그것을 결정하기 위해 C1 가장 최근에 수정한 커밋입니다. A. 통과한 횡단보도 C2 그리고 C3하지만 우리는 단지 수정 사항만 찾고 있었기 때문에 A우리는 비난하려고 할 때 해당 커밋을 다시 방문하게 될 것입니다 B 그리고 C. 이 예에서는 해당 3개의 커밋을 총 6번 방문합니다. 이는 필요한 기록 순회 횟수의 두 배입니다.

Git 2.52에는 짧은 시간 내에 동일한 정보를 제공하는 새로운 명령이 도입되었습니다. git last-modified. 얼마나 빠른지 파악하려면 last-modified 위의 예보다 몇 가지 초미세 결과는 다음과 같습니다.

Benchmark 1: git ls-tree + log
  Time (mean ± σ):      3.962 s ±  0.011 s    [User: 2.676 s, System: 1.330 s]
  Range (min … max):    3.940 s …  3.984 s    10 runs

Benchmark 2: git last-modified
  Time (mean ± σ):     722.7 ms ±   4.6 ms    [User: 682.4 ms, System: 40.1 ms]
  Range (min … max):   717.3 ms … 731.3 ms    10 runs

Summary
  git last-modified ran
    5.48 ± 0.04 times faster than git ls-tree + log

핵심 기능 git last-modified GitHub에서 수년에 걸쳐 작성되었습니다(원래는 blame-tree GitHub의 Git 포크에서) 이는 2012년부터 트리 수준 비난의 원동력이 되었습니다. 올해 초 우리는 이러한 패치를 GitLab의 엔지니어와 공유했습니다. GitLab은 수년간의 개발을 이번 릴리스에 포함된 검토 가능한 패치 시리즈로 정리했습니다.

이 명령의 GitHub 버전에는 아직 Git 릴리스에 포함되지 않은 일부 기능이 있습니다. 여기에는 이전 실행 결과를 캐시하는 온디스크 형식이 포함됩니다. 그동안 확인해 보세요. git last-modifiedGit 2.52에서 사용 가능합니다.

[source, source, source]

이 시리즈를 다시 읽은 독자들은 우리가 보도한 내용을 기억할 것입니다. git maintenance 명령. 처음으로 읽어보시거나 다시 복습할 수 있는 경우, 저희가 도와드리겠습니다.

git maintenance 일정에 따라 또는 임시로 저장소 관리 작업을 수행할 수 있는 Git 명령입니다. 그만큼 maintenance 명령은 저장소 내용 재압축, 커밋 그래프 업데이트, 오래된 참조 로그 항목 만료 등과 같은 다양한 작업을 수행할 수 있습니다. 함께 모아, maintenance 저장소가 원활하고 효율적으로 계속 작동하도록 보장합니다.

기본적으로(또는 실행할 때 gc 일), git maintenance 의지하다 git gc 내부적으로 리포지토리를 다시 압축하고 연결할 수 없는 개체를 제거합니다. 여기에는 몇 가지 단점이 있습니다. git gc 저장소의 콘텐츠를 통합하기 위해 “일체형” 재압축을 수행합니다. 이는 매우 큰 저장소의 경우 속도가 느릴 수 있습니다. 대안으로, git maintenance 가지고있다 incremental-repack 전략을 사용하지만 도달할 수 없는 객체를 제거하지는 않습니다.

Git 2.52는 새로운 기능을 도입하여 이러한 격차를 해소합니다. geometric 내의 작업 git maintenance 가능하면 올인원 재압축을 피하고 도달할 수 없는 객체를 덜 빈번하게 정리합니다. 이 새로운 작업은 GitHub에서 설계되었으며 수년 동안 GitHub의 자체 저장소 유지 관리를 지원해 온 도구(예: 기하학적 재포장)를 사용합니다. 이러한 도구는 2.33부터 Git에 있었지만 구현이 Git에 묻혀 있었기 때문에 사용하거나 발견하기가 어색했습니다. git repack~ 아니다 git gc.

그만큼 geometric 여기서 작업은 저장소의 내용을 검사하여 일부 팩 파일을 결합하여 개체 수에 따른 기하학적 진행을 형성할 수 있는지 확인하는 방식으로 수행됩니다. 가능한 경우 기하학적 재압축을 수행하여 객체를 잘라내지 않고 저장소의 콘텐츠를 압축합니다. 또는 기하학적 재포장이 저장소 전체를 단일 팩으로 압축하는 경우 전체 git gc 대신 저장소의 콘텐츠를 통합하고 연결할 수 없는 개체를 제거하는 작업이 수행됩니다.

Git 2.52를 사용하면 가장 큰 리포지토리도 원활하게 실행되도록 쉽게 유지할 수 있습니다. 새로운 내용을 확인해보세요 geometric 전략이나 다른 많은 기능 중 하나 git maintenance 2.52에서는 가능합니다.

[source]

이제 더 큰 변경 사항 중 일부를 더 자세히 다루었으므로 이번 릴리스의 다른 새로운 기능과 업데이트에 대해 자세히 살펴보겠습니다.

이번 릴리스에는 몇 가지 새로운 하위 명령이 추가되었습니다. git refs저장소의 참조에 대한 낮은 수준의 액세스를 제공하기 위한 Git의 비교적 새로운 도구입니다. 이번 출시 이전에는 git refs 해당 참조의 내부 표현을 확인하면서 참조 백엔드 간에 마이그레이션할 수 있었습니다(예: 저장소에서 참조 데이터를 참조 가능한 형식으로 저장하도록 함).

git refs 이제 두 개의 새로운 하위 명령이 포함됩니다. git refs list 그리고 git refs exists. 전자는 다음의 별칭입니다. git for-each-ref 동일한 옵션 세트를 지원합니다. 후자는 다음과 같이 작동합니다. git show-ref --exists특정 참조가 존재하는지 여부를 빠르게 확인하는 데 사용할 수 있습니다.

이러한 새로운 하위 명령 중 어느 것도 새로운 기능을 도입하지 않지만 몇 가지 일반적인 참조 관련 작업을 여러 개별 명령이 아닌 단일 Git 명령으로 통합합니다.

[source]
Git에 대해 스크립트를 작성해 본 적이 있다면 Git의 내용에 익숙할 것입니다. rev-parse 명령. 그렇지 않다면 그렇게 생각하는 것은 용서받을 수 있습니다. rev-parse 커밋을 전체 개체 ID로 설명하는 다양한 방법을 해결하도록 설계되었습니다. 실제로는 rev-parse 쉘 인용, 옵션 구문 분석(getopt 대체), 로컬 인쇄 등 개체 ID 확인과 전혀 관련 없는 기능을 수행할 수 있습니다. GIT_ 환경 변수, 내부 경로 확인 $GIT_DIR 그리고 훨씬 더.

Git 2.52는 새로운 기능을 통해 이 기능 중 일부에 새로운 홈을 제공하는 첫 번째 단계를 소개합니다. git repo 명령. 그만큼 git repo 현재 실험용으로 지정된 명령은 저장소에 대한 정보를 검색하기 위한 범용 도구로 설계되었습니다. 예를 들어, 저장소가 얕은 것인지 빈약한 것인지 여부와 함께 저장소가 사용하는 객체 유형 및 참조 형식을 확인할 수 있습니다.
```
$ keys="layout.bare layout.shallow object.format references.format"
$ git repo info $keys
layout.bare=false
layout.shallow=false
object.format=sha1
references.format=files
```
새로운 git repo 명령은 또한 다음을 통해 저장소의 구조와 내용에 대한 몇 가지 일반 통계를 인쇄할 수도 있습니다. git repo structure 하위 명령:
```
$ git repo structure
Counting objects: 497533, done.
| Repository structure | Value  |
| -------------------- | ------ |
| * References         |        |
|   * Count            |   2871 |
|     * Branches       |     58 |
|     * Tags           |   1273 |
|     * Remotes        |   1534 |
|     * Others         |      6 |
|                      |        |
| * Reachable objects  |        |
|   * Count            | 497533 |
|     * Commits        |  91386 |
|     * Trees          | 208050 |
|     * Blobs          | 197103 |
|     * Tags           |    994 |
```
[source, source, source]
2.28에서 Git 프로젝트는 다음을 도입했습니다. init.defaultBranch 다음으로 생성된 모든 저장소에 기본 분기 이름을 제공하는 구성 옵션 git init. 도입 이후 해당 구성 옵션의 기본값은 “마스터”였습니다. init.defaultBranch 대신 “메인”으로 설정하세요.

Git 3.0부터 기본값은 init.defaultBranch “메인”으로 변경됩니다. 이는 다음을 사용하여 Git 3.0 이상에서 생성된 모든 리포지토리를 의미합니다. git init 추가 구성이 필요 없이 “main”이라는 기본 브랜치를 갖게 됩니다.

Git 3.0에 대한 미리보기나 기타 계획된 변경 사항을 알고 싶다면 다음을 사용하여 Git을 로컬로 빌드할 수 있습니다. WITH_BREAKING_CHANGES 오늘 새로운 변경 사항을 시험해 보려면 build-flag를 사용하세요.

[source, source]
기본적으로 Git은 SHA-1을 사용하여 리포지토리에 있는 모든 개체의 콘텐츠 주소 지정이 가능한 해시를 제공합니다. Git 3.0에서 Git은 보다 매력적인 보안 속성을 제공하는 SHA-256을 대신 사용합니다. Git 2.45에 대한 취재에서 우리는 둘 사이의 상호 운용성을 향한 임시 단계로 SHA-1과 SHA-256을 모두 사용하여 새 객체의 별도 복사본을 작성할 수 있는 몇 가지 새로운 변경 사항에 대해 이야기했습니다.

Git 2.52에서는 상호 운용성을 위한 나머지 작업이 시작됩니다. 이번 릴리스에 포함된 변경 사항은 향후 상호 운용성 기능을 위한 기반을 마련하는 데 중점을 두고 있지만, 결국에는 하나의 해시 알고리즘으로 Git 저장소를 사용하고 다른 해시 알고리즘을 사용하여 다른 저장소에서 푸시하고 풀할 수 있기를 바랍니다.

[source]
Git의 다른 최첨단 변경 사항에 대해 말하자면, 이번 릴리스는 Git 내의 일부 내부 기능에 Rust 코드를 (선택적으로) 사용하는 최초의 릴리스입니다. 이 모드는 선택 사항이며 새로운 모드로 보호됩니다. WITH_RUST 플래그를 구축합니다. 이 모드를 활성화하여 빌드하면 Git은 가변 너비 정수를 인코딩하고 디코딩하기 위해 Rust 구현을 사용합니다.

이번 릴리스에는 일부 사소한 유틸리티 기능의 Rust 변형만 도입되었지만 Git의 훨씬 더 흥미로운 부분을 Rust로 다시 작성하기 위한 인프라가 설정되었습니다.

Rust 지원은 아직 필수가 아니므로 Git 2.52는 Rust 컴파일러가 없는 플랫폼에서도 계속해서 잘 실행될 것입니다. 그러나 Git 3.0에는 Rust 지원이 필요하며, 이 시점에서 Git의 더 많은 구성 요소가 Rust 코드에 의존하게 될 것입니다.

[source, source, source]
오랜 독자라면 Git 내에서 2.28부터 경로가 변경된 Bloom 필터에 대해 다룬 내용을 기억하실 것입니다. 그렇지 않은 경우 변경된 경로 Bloom 필터는 첫 번째 상위 항목을 기준으로 커밋에 의해 수정된 파일 경로를 대략적으로 추정할 수 있는 확률적 데이터 구조입니다. Bloom 필터에는 거짓 부정(즉, 커밋이 실제로 일부 경로를 수정했지만 실제로는 수정하지 않았음을 나타냄)이 없기 때문에 Git 전체에서 많은 경로 범위 순회를 가속화하는 데 사용할 수 있습니다(예: last-modified 위에!).

최근에는 여러 관심 경로를 동시에 제공하는 등 Git 내에서 Bloom 필터를 사용하는 새로운 방법을 다루었습니다(예: git log /my/subdir /my/other/subdir) 이전에는 Bloom 필터에서 지원되지 않았습니다. 그 당시 우리는 Git의 더 많은 표현 경로 사양 구문에서 Bloom 필터를 지원하는 것에 대한 논의가 진행 중이라고 썼습니다.

이번 릴리스는 이러한 논의의 결과를 제공하며 이제 훨씬 더 많은 시나리오에서 Bloom 필터를 사용하여 얻을 수 있는 성능상의 이점을 지원합니다. 여기서 한 가지 예는 pathspec의 구성 요소 전체가 아닌 일부에 와일드카드를 포함하는 경우입니다. foo/bar/*/baz여기서 Git은 이제 경로의 와일드카드가 아닌 구성 요소에 대해 Bloom 필터를 사용합니다. 이제 Bloom 필터를 활용할 수 있는 더 많은 시나리오를 읽어보려면 아래 링크를 확인하세요.

[source]
또한 이번 릴리스에서는 프로젝트의 여러 영역에서 성능이 크게 향상되었습니다. git describe 우선순위 큐를 사용하여 성능을 30% 향상시키는 방법을 배웠습니다. git remote 참조 이름 바꾸기를 최적화하기 위해 몇 가지 새로운 트릭을 선택했습니다. rename 하위 명령. git ls-files 이전에는 불가능했던 경우에도 인덱스를 희소하게 유지할 수 있습니다. git log -L 병합 커밋을 처리할 때 불필요한 트리 수준 차이점을 피함으로써 훨씬 더 빨라졌습니다. 마지막으로, xdiff (Git의 파일 수준 비교 및 병합 엔진을 구동하는 라이브러리)은 이번 릴리스의 두 가지 최적화(여기 및 여기)와 향후 릴리스에 포함될 가능성이 있는 더 많은 최적화의 이점을 얻었습니다.

[source, source, source, source]
마지막으로 Git에 대한 몇 가지 업데이트가 있습니다. sparse-checkout 새로운 “clean” 하위 명령을 학습한 기능입니다. git sparse-checkout clean 체크아웃한 저장소 부분을 변경할 때 스파스 체크아웃 정의 외부에 일부 파일이 남아 있는 까다로운 경우를 복구하는 데 도움이 됩니다.

어떻게 이런 상황에 빠지게 되었는지, 그리고 2.52 이전 도구만으로 이 상황에서 복구하는 것이 왜 그토록 어려운지에 대한 세부 사항은 놀라울 정도로 기술적입니다. 모든 잔혹한 세부 사항에 관심이 있다면 이 커밋에 이 변경 사항에 대한 모든 정보가 있습니다.

그동안 사용하시면 sparse-checkout 그리고 컴퓨터를 바꿀 때 청소하는 데 어려움을 겪은 적이 있습니다. sparse-checkout 정의하다, 주다 git sparse-checkout clean Git 2.52의 소용돌이.

[source]