Git 2.54의 주요 하이라이트 - GitHub 블로그

콘텐츠로 건너뛰기사이드바로 건너뛰기

/블로그

• 변경 로그
• 문서
• 고객 사례

GitHub Copilot 사용해 보기새로운 소식 보기

• AI & ML

  • AI & ML GitHub 생태계와 더 넓은 업계 전반에서 인공지능과 머신 러닝을 알아보세요.

    • Generative AI 생성형 AI로 빌드하는 방법을 알아보세요.

    • GitHub Copilot GitHub Copilot으로 일하는 방식을 바꿔보세요.

    • LLMs 개발자가 LLM에 대해 알아야 할 모든 것.

    • Machine learning 머신 러닝 팁, 요령, 그리고 모범 사례.

  • AI 코드 생성의 작동 방식 AI 코드 생성의 기능과 이점을 살펴보고 이것이 개발자 경험을 어떻게 향상시킬 수 있는지 알아보세요.

자세히 알아보기

• 개발자 역량

  • 개발자 역량 개발자가 기술과 경력을 성장시키는 데 도움이 되는 리소스입니다.

    • 애플리케이션 개발 앱을 구축하기 위한 인사이트와 모범 사례.

    • 경력 성장 전문 개발자로 성장하기 위한 팁과 요령.

    • GitHub 직장에서 GitHub를 사용하는 방식을 개선해 보세요.

    • GitHub Education 첫 번째 전문 직무로 나아가는 방법을 알아보세요.

    • 프로그래밍 언어 및 프레임워크 새로운 것들, 혹은 다시 새로워진 것들을 놓치지 마세요.

  • GitHub 문서 시작하기 GitHub로 소프트웨어를 빌드하고, 배포하고, 유지 관리하는 방법을 알아보세요.

자세히 알아보기

• 엔지니어링

  • 엔지니어링 모든 개발자를 위한 터전을 어떻게 만들고 있는지 내부 이야기를 확인해 보세요.

    • 아키텍처 및 최적화 GitHub 플랫폼 전반에서 고성능이면서도 높은 가용성을 갖춘 경험을 제공하는 방법을 알아보세요.

    • 엔지니어링 원칙 원격 중심 팀으로 대규모 소프트웨어를 구축하기 위한 모범 사례를 살펴보세요.

    • 인프라 세계 최고의 AI 기반 개발자 플랫폼을 뒷받침하는 기술을 엿보세요.

    • 플랫폼 보안 개발자 라이프사이클 전반에서 우리가 하는 모든 일에 보안을 어떻게 내재화하는지 알아보세요.

    • 사용자 경험 GitHub를 모든 개발자의 터전으로 만드는 데 무엇이 들어가는지 확인해 보세요.

  • 생산성, 협업, 보안을 높이기 위해 GitHub를 사용하는 방법 우리의 엔지니어링 팀과 보안 팀은 놀라운 일을 하고 있습니다. GitHub를 사용해 생산성을 높이고, 협업으로 빌드하며, 보안을 더 이른 단계로 이동시키는 방법을 함께 살펴보세요.

자세히 알아보기

• 엔터프라이즈 소프트웨어

  • 엔터프라이즈 소프트웨어 엔터프라이즈 소프트웨어를 대규모로 작성, 빌드, 배포하는 방법을 알아보세요.

    • 자동화 더 빠르고 더 안전한 출시를 위한 자동화.

    • CI/CD 지속적 통합과 전달에 대한 가이드.

    • 협업 개발자 협업을 개선하기 위한 팁, 도구, 요령.

    • DevOps 엔터프라이즈 엔지니어링 팀을 위한 DevOps 리소스.

    • DevSecOps SDLC에 보안을 통합하는 방법.

    • 거버넌스 및 규정 준수 빌드가 깔끔하게 유지되도록 보장하세요.

  • GitHub, AI 코드 어시스턴트 부문 Gartner® Magic Quadrant™에서 리더로 선정 Gartner가 GitHub를 2년 연속 리더로 선정한 이유를 알아보세요.

자세히 알아보기

• 뉴스 및 인사이트

  • 뉴스 및 인사이트 GitHub 내부의 새롭고 주목할 만한 소식을 확인하세요.

    • 회사 소식 GitHub의 뉴스와 제품 업데이트에 대한 내부 이야기.

    • 제품 GitHub 플랫폼, 제품, 도구의 최신 소식.

    • Octoverse GitHub 오픈 소스 현황에 대한 인사이트.

    • 정책 소프트웨어 분야의 최신 정책 및 규제 변화.

    • 연구 개발자 생태계를 둘러싼 데이터 기반 인사이트.

    • The library GitHub의 이전 뉴스와 업데이트.

  • RAG로 비정형 데이터의 힘 끌어내기 검색 증강 생성(RAG)을 사용해 더 많은 인사이트를 얻는 방법을 알아보세요.

자세히 알아보기

• Open Source

  • Open Source GitHub의 모든 오픈 소스를 만나보세요.

    • Git 최신 Git 업데이트.

    • Maintainers 오픈 소스 메인터레이너 조명.

    • Social impact 오픈 소스가 긍정적인 변화를 이끄는 방법.

    • Gaming GitHub의 오픈 소스 게임을 살펴보세요.

  • innersource 소개 전 세계 조직들은 자체 소프트웨어를 빌드하고 배포하는 방식에 오픈 소스 방법론을 도입하고 있습니다.

자세히 알아보기

• 보안

  • 보안 보안의 모든 것을 최신 상태로 유지하세요.

    • 애플리케이션 보안 애플리케이션 보안, 쉽게 설명합니다.

    • 공급망 보안 공급망 보안을 쉽게 이해해 보세요.

    • 취약점 연구 GitHub Security Lab의 업데이트.

    • 웹 애플리케이션 보안 웹 애플리케이션 보안을 위한 유용한 팁.

  • AI 기반 DevSecOps를 위한 엔터프라이즈 가이드 DevSecOps의 핵심 과제와 AI 및 자동화로 이를 해결하기 시작하는 방법을 알아보세요.

자세히 알아보기

검색

카테고리

• AI & ML

  • BackAI & ML GitHub 생태계와 더 넓은 업계 전반에서 인공지능과 머신 러닝을 알아보세요.

    • Generative AI 생성형 AI로 빌드하는 방법을 알아보세요.

    • GitHub Copilot GitHub Copilot으로 일하는 방식을 바꿔보세요.

    • LLMs 개발자가 LLM에 대해 알아야 할 모든 것.

    • Machine learning 머신 러닝 팁, 요령, 그리고 모범 사례.

  • AI 코드 생성의 작동 방식 AI 코드 생성의 기능과 이점을 살펴보고 이것이 개발자 경험을 어떻게 향상시킬 수 있는지 알아보세요.

자세히 알아보기

• 개발자 역량

  • Back개발자 역량 개발자가 기술과 경력을 성장시키는 데 도움이 되는 리소스입니다.

    • 애플리케이션 개발 앱을 구축하기 위한 인사이트와 모범 사례.

    • 경력 성장 전문 개발자로 성장하기 위한 팁과 요령.

    • GitHub 직장에서 GitHub를 사용하는 방식을 개선해 보세요.

    • GitHub Education 첫 번째 전문 직무로 나아가는 방법을 알아보세요.

    • 프로그래밍 언어 및 프레임워크 새로운 것들, 혹은 다시 새로워진 것들을 놓치지 마세요.

  • GitHub 문서 시작하기 GitHub로 소프트웨어를 빌드하고, 배포하고, 유지 관리하는 방법을 알아보세요.

자세히 알아보기

• 엔지니어링

  • Back엔지니어링 모든 개발자를 위한 터전을 어떻게 만들고 있는지 내부 이야기를 확인해 보세요.

    • 아키텍처 및 최적화 GitHub 플랫폼 전반에서 고성능이면서도 높은 가용성을 갖춘 경험을 제공하는 방법을 알아보세요.

    • 엔지니어링 원칙 원격 중심 팀으로 대규모 소프트웨어를 구축하기 위한 모범 사례를 살펴보세요.

    • 인프라 세계 최고의 AI 기반 개발자 플랫폼을 뒷받침하는 기술을 엿보세요.

    • 플랫폼 보안 개발자 라이프사이클 전반에서 우리가 하는 모든 일에 보안을 어떻게 내재화하는지 알아보세요.

    • 사용자 경험 GitHub를 모든 개발자의 터전으로 만드는 데 무엇이 들어가는지 확인해 보세요.

  • 생산성, 협업, 보안을 높이기 위해 GitHub를 사용하는 방법 우리의 엔지니어링 팀과 보안 팀은 놀라운 일을 하고 있습니다. GitHub를 사용해 생산성을 높이고, 협업으로 빌드하며, 보안을 더 이른 단계로 이동시키는 방법을 함께 살펴보세요.

자세히 알아보기

• 엔터프라이즈 소프트웨어

  • Back엔터프라이즈 소프트웨어 엔터프라이즈 소프트웨어를 대규모로 작성, 빌드, 배포하는 방법을 알아보세요.

    • 자동화 더 빠르고 더 안전한 출시를 위한 자동화.

    • CI/CD 지속적 통합과 전달에 대한 가이드.

    • 협업 개발자 협업을 개선하기 위한 팁, 도구, 요령.

    • DevOps 엔터프라이즈 엔지니어링 팀을 위한 DevOps 리소스.

    • DevSecOps SDLC에 보안을 통합하는 방법.

    • 거버넌스 및 규정 준수 빌드가 깔끔하게 유지되도록 보장하세요.

  • GitHub, AI 코드 어시스턴트 부문 Gartner® Magic Quadrant™에서 리더로 선정 Gartner가 GitHub를 2년 연속 리더로 선정한 이유를 알아보세요.

자세히 알아보기

• 뉴스 및 인사이트

  • Back뉴스 및 인사이트 GitHub 내부의 새롭고 주목할 만한 소식을 확인하세요.

    • 회사 소식 GitHub의 뉴스와 제품 업데이트에 대한 내부 이야기.

    • 제품 GitHub 플랫폼, 제품, 도구의 최신 소식.

    • Octoverse GitHub 오픈 소스 현황에 대한 인사이트.

    • 정책 소프트웨어 분야의 최신 정책 및 규제 변화.

    • 연구 개발자 생태계를 둘러싼 데이터 기반 인사이트.

    • The library GitHub의 이전 뉴스와 업데이트.

  • RAG로 비정형 데이터의 힘 끌어내기 검색 증강 생성(RAG)을 사용해 더 많은 인사이트를 얻는 방법을 알아보세요.

자세히 알아보기

• Open Source

  • BackOpen Source GitHub의 모든 오픈 소스를 만나보세요.

    • Git 최신 Git 업데이트.

    • Maintainers 오픈 소스 메인터레이너 조명.

    • Social impact 오픈 소스가 긍정적인 변화를 이끄는 방법.

    • Gaming GitHub의 오픈 소스 게임을 살펴보세요.

  • innersource 소개 전 세계 조직들은 자체 소프트웨어를 빌드하고 배포하는 방식에 오픈 소스 방법론을 도입하고 있습니다.

자세히 알아보기

• 보안

  • Back보안 보안의 모든 것을 최신 상태로 유지하세요.

    • 애플리케이션 보안 애플리케이션 보안, 쉽게 설명합니다.

    • 공급망 보안 공급망 보안을 쉽게 이해해 보세요.

    • 취약점 연구 GitHub Security Lab의 업데이트.

    • 웹 애플리케이션 보안 웹 애플리케이션 보안을 위한 유용한 팁.

  • AI 기반 DevSecOps를 위한 엔터프라이즈 가이드 DevSecOps의 핵심 과제와 AI 및 자동화로 이를 해결하기 시작하는 방법을 알아보세요.

자세히 알아보기

• 변경 로그
• 문서
• 고객 사례

새로운 소식 보기GitHub Copilot 사용해 보기

홈/Open Source/Git

Git 2.54의 주요 하이라이트

오픈 소스 Git 프로젝트가 방금 Git 2.54를 릴리스했습니다. 지난번 이후 도입된 가장 흥미로운 기능과 변경 사항 몇 가지를 GitHub의 시선으로 살펴보겠습니다.

Taylor Blau·@ttaylorr

2026년 4월 20일

| 10분

• 공유:

오픈 소스 Git 프로젝트는 137명이 넘는 기여자들의 기능과 버그 수정이 포함된 Git 2.54를 릴리스했습니다. 그중 66명은 새로운 기여자입니다. Git의 최신 소식을 마지막으로 전해드린 것은 2.52가 릴리스되었을 때였습니다.

이번 최신 릴리스를 기념하며, 지난번 이후 도입된 가장 흥미로운 기능과 변경 사항 몇 가지를 GitHub의 관점에서 살펴보겠습니다.

💡 우리가 마지막으로 다뤘던 Git 릴리스가 Git 2.52였기 때문에, 이 블로그 게시물은 2.53 및 2.54 릴리스의 하이라이트를 모두 다룹니다.

git history로 히스토리 다시 쓰기

Git 프로젝트는 저장소의 히스토리를 다시 쓸 수 있는 도구를 오랫동안 제공해 왔습니다. 그중 가장 잘 알려진 것은 git rebase –i이며, 놀라울 만큼 유연합니다. 커밋의 순서를 바꾸고, 합치고, 편집하고, 삭제할 수 있습니다. 하지만 그 유연성에는 복잡성이 따릅니다. 대화형 rebase는 커밋 범위를 대상으로 동작하고, 진행하면서 working tree와 index를 갱신하며, 계속 진행하기 전에 해결해야 하는 충돌 상태를 남길 수도 있습니다.

더 단순한 경우에는 이런 모든 장치가 과하다고 느껴질 수 있습니다. 세 커밋 전의 커밋 메시지 오타를 고치거나, 하나의 커밋을 둘로 나누고 싶을 뿐이라면, 대화형 rebase로 가능하긴 하지만 할 일 목록을 준비하고, 적절한 커밋을 편집 대상으로 표시한 뒤, rebase가 완료될 때까지 과정을 직접 진행해야 합니다.

Git 2.54는 바로 이런 단순한 경우를 위해 설계된 새로운 실험적 명령어 git history를 도입합니다. 현재 history 명령은 두 가지 작업을 지원합니다. reword와 split입니다.

git history reword <commit>는 지정한 커밋의 메시지로 편집기를 열고, 그 자리에서 메시지를 다시 씁니다. 그리고 해당 커밋에서 갈라져 나온 모든 브랜치를 갱신합니다. git rebase와 달리 working tree나 index를 건드리지 않으며, bare repository에서도 동작할 수 있습니다.

git history split <commit>는 어떤 hunk를 새로운 부모 커밋으로 떼어낼지 선택하여, 커밋 하나를 대화형으로 둘로 나눌 수 있게 해줍니다. 인터페이스는 git add –p를 통한 대화형 모드의 add를 사용해 본 적이 있다면 익숙하게 느껴질 것입니다.

$ git history split HEAD
diff --git a/bar b/bar
new file mode 100644
index 0000000..50810a5
--- /dev/null
+++ b/bar
@@ -0,0 +1 @@
+bar
(1/1) Stage addition [y,n,q,a,d,p,?]? y

hunk를 선택하고 나면 Git은 그 변경 사항으로 새 커밋을 만들고, 그것을 원래 커밋의 부모로 둡니다. 원래 커밋에는 선택하지 않은 hunk가 남습니다. 그리고 후손 브랜치들을 다시 써서 갱신된 히스토리를 가리키게 합니다.

의도적인 제한 사항도 몇 가지 있습니다. history 명령은 merge commit을 포함하는 히스토리는 지원하지 않으며, merge conflict가 발생하게 되는 작업은 수행을 거부합니다. 설계상 git history는 목표가 명확한 비대화형 재작성용이지, 일반적으로 git rebase –i에 맡겨지는 종류의 개방형 히스토리 재작성을 위한 것은 아닙니다.

history 명령은 git replay의 핵심 메커니즘 위에 구축되어 있으며, 그 메커니즘 자체도 이 작업의 일환으로 라이브러리로 분리되었습니다. 이런 기반 덕분에 git history는 working tree를 건드리지 않고 동작하는 replay의 능력을 그대로 활용하며, 대화형 사용뿐 아니라 스크립팅과 자동화에도 자연스럽게 어울립니다.

이 명령은 아직 실험적 표시가 붙어 있으므로 인터페이스가 계속 발전할 수 있습니다. Git 2.54에서 사용할 수 있는 git history reword와 git history split를 직접 사용해 보세요.

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

구성 기반 훅

여러 저장소에서 Git hook을 공유하고 싶었던 적이 있다면, 아마도 서드파티 훅 관리자에 의존하거나 각 저장소의 $GIT_DIR/hooks 디렉터리에 스크립트를 수동으로 심볼릭 링크해야 했을 것입니다. 역사적으로 Git 훅은 오직 한 곳, 즉 .git 디렉터리의 hooks 하위 디렉터리(또는 core.hooksPath가 가리키는 곳)에 있는 실행 가능한 스크립트로만 정의할 수 있었기 때문입니다.

즉, 모든 저장소에서 매 커밋 전에 linter를 실행하고 싶다면, 각 저장소에 스크립트를 복사해야 했고, 이것은 번거롭고 실수하기 쉬웠습니다. 또는 core.hooksPath를 공유 디렉터리로 설정할 수도 있지만, 그러면 모든 저장소가 정확히 같은 훅 집합을 공유하게 되어 저장소별로 조합을 달리할 방법이 없습니다.

Git 2.54는 훅을 정의하는 새로운 방법을 도입합니다. 바로 구성 파일 안에서 정의하는 것입니다. .git/hooks/pre-commit에 스크립트를 두는 대신, 이제 다음처럼 쓸 수 있습니다.

[hook "linter"]
   event = pre-commit
   command = ~/bin/linter --cpp20

hook.<name>.command 키는 실행할 명령을 지정하고, hook.<name>.event는 어떤 훅 이벤트가 그것을 트리거할지 지정합니다. 이것은 단지 구성일 뿐이므로 사용자별 ~/.gitconfig, 시스템 전역 /etc/gitconfig, 또는 저장소의 로컬 구성에 둘 수 있습니다. 따라서 훅 집합을 중앙에서 정의하고 이를 모든 곳에 적용하기가 쉬워집니다.

더 좋은 점은 이제 같은 이벤트에 대해 여러 개의 훅을 실행할 수 있다는 것입니다. 예를 들어 매 커밋 전에 linter와 secrets scanner를 모두 실행하고 싶다면, 각각을 독립적으로 구성할 수 있습니다.

[hook "linter"]
   event = pre-commit
   command = ~/bin/linter --cpp20

[hook "no-leaks"]
   event = pre-commit
   command = ~/bin/leak-detector

Git은 구성에서 발견한 순서대로 이 훅들을 실행합니다. $GIT_DIR/hooks에 있는 전통적인 훅 스크립트도 여전히 작동하며, 마지막에 실행되므로 기존 훅은 영향을 받지 않습니다. 어떤 훅이 구성되어 있는지, 그리고 그것이 어디서 왔는지는 git hook list로 확인할 수 있습니다.

$ git hook list pre-commit
global    linter  ~/bin/linter --cpp20
local    no-leaks    ~/bin/leak-detector

hook.<name>.enabled = false를 설정하면 구성을 제거하지 않고도 개별 훅을 비활성화할 수 있습니다. 이는 시스템 수준 구성에 훅이 정의되어 있지만 특정 저장소에서는 그것을 제외해야 할 때 특히 유용합니다.

이 과정에서 Git 내부의 훅 처리 방식도 현대화되었습니다. 이전에는 임시적인 코드 경로를 통해 호출되던 많은 내장 훅들(pre-push, post-rewrite, 그리고 여러 receive-pack 훅 등)이 새 훅 API를 사용하도록 이전되었고, 그 결과 이들 모두가 새로운 구성 기반 훅 메커니즘의 이점을 누리게 되었습니다.

[source, source, source]]

유지 관리 중 기하학적 repack이 기본값으로

이 시리즈를 계속 읽어오신 분들은 Git 2.52에서 도입된 git maintenance의 새로운 geometric 전략에 대한 이전 소개를 기억하실 수도 있습니다. 이 전략은 저장소의 내용을 검사해, 여러 packfile을 객체 수 기준 등비수열로 결합할 수 있는지를 판단하는 방식으로 동작합니다. 가능하다면 Git은 전체 가비지 컬렉션을 수행하지 않고도 저장소 내용을 압축하는 기하학적 repack을 수행합니다.

2.52에서는 geometric 전략이 maintenance.strategy 구성으로 선택하는 옵트인 방식이었습니다. 2.54에서는 수동 유지 관리의 기본 전략이 됩니다. 즉, 전략을 지정하지 않고 git maintenance run을 실행하면 Git은 이제 전통적인 gc 작업 대신 기하학적 접근 방식을 사용합니다.

실제로는 저장소가 기본 설정만으로도 더 효율적으로 유지 관리된다는 뜻입니다. 기하학적 전략은 gc가 수행하는 비용이 큰 전체 단일 pack 재구성을 피하고, 가능한 경우 pack들을 점진적으로 결합합니다. 그리고 전체 저장소를 단일 pack으로 통합하게 되는 경우에만 완전한 gc로 되돌아갑니다. 그 과정에서 commit-graph, reflog, 그리고 기타 보조 데이터 구조도 최신 상태로 유지합니다.

이미 구성에서 maintenance.strategy = geometric를 사용하고 있었다면 바뀌는 것은 없습니다. 전략을 설정하지 않았거나 예전의 기본값 gc에 의존하고 있었다면, 이제 기하학적 repack의 이점을 자동으로 누리게 됩니다. 원한다면 gc 전략은 여전히 사용할 수 있으며 maintenance.strategy = gc로 선택할 수 있습니다.

[source]]

빙산의 일각…

이제 좀 더 큰 변화들을 자세히 살펴봤으니, 이번 릴리스의 다른 새 기능과 업데이트 몇 가지도 더 가까이 들여다보겠습니다.

• git add –p 명령은 개별 hunk를 대화형으로 스테이징하는 Git의 도구인데, 이번 릴리스에서 사용성 개선이 몇 가지 이루어졌습니다. J와 K 키로 hunk 사이를 이동할 때 Git이 이제 각 hunk를 이전에 수락했는지 건너뛰었는지를 보여주므로, 앞서 내린 결정을 기억하고 있을 필요가 없습니다.

별도로, 새로운 --no-auto-advance 플래그는 git add –p가 파일 간 전환을 처리하는 방식을 바꿉니다. 보통은 한 파일의 모든 hunk에 대해 결정을 마치면 세션이 자동으로 다음 파일로 넘어갑니다. --no-auto-advance를 사용하면 마지막 hunk에 대한 결정을 내린 뒤에도 세션이 그 자리에 머물러, <와 >를 사용해 원하는 속도로 파일 사이를 이동할 수 있습니다. 이는 결정을 확정 하기 전에 전체적으로 검토하고 싶을 때 유용할 수 있습니다.

[source,source]]

• working tree를 건드리지 않고 커밋을 새 베이스 위로 재적용하는 실험적 명령 git replay도 계속 성숙해지고 있습니다. 이번 릴리스에는 여러 개선 사항이 포함되었습니다. replay는 이제 기본적으로 원자적 참조 갱신을 수행하며(더 이상 update-ref 명령을 stdout에 출력하는 대신), 주어진 커밋 범위의 변경을 되돌리는 새 --revert 모드를 익혔고, 재적용 과정에서 비게 되는 커밋을 삭제할 수 있으며, 루트 커밋까지 끝까지 재적용하는 것도 지원합니다.

[source,source,source,source]]

• Git의 HTTP 전송은 이제 HTTP 429 “Too Many Requests” 응답을 처리합니다. 이전에는 서버의 429 응답이 치명적 오류로 처리되었습니다. 이제 Git은 요청을 재시도할 수 있으며, 서버가 Retry-After 헤더를 제공하면 이를 따르고, 없으면 새로운 http.retryAfter 설정을 통한 구성 가능한 지연으로 대체합니다. 새로운 http.maxRetries와 http.maxRetryTime 구성 옵션은 각각 몇 번 재시도할지와 얼마나 오래 기다릴지를 제어합니다.

[source]]

• 파일 내 특정 줄 범위의 히스토리를 추적하는 git log –L은 역사적으로 Git의 표준 diff 메커니즘 상당 부분을 우회하는 자체 출력 경로를 사용해 왔습니다. 그 결과 내용 변경으로 검색하는 -S 및 -G “pickaxe” 옵션을 비롯한 여러 유용한 옵션과 호환되지 않았습니다.

이번 릴리스에서는 git log –L이 표준 diff 파이프라인을 통해 출력을 내보내도록 다시 작업되어, 처음으로 패치 포맷팅 옵션 및 pickaxe 검색과 호환되게 되었습니다.

예를 들어 strbuf.c 안의 strbuf_addstr() 히스토리를 추적하되, 그 함수 안에서 len이 추가되거나 제거된 커밋만 보고 싶다고 해보겠습니다.

$ git log -L :strbuf_addstr:strbuf.c -S len --oneline -1
a70f8f19ad2 strbuf: introduce strbuf_addstrings() to repeatedly add a string

diff --git a/strbuf.c b/strbuf.c
--- a/strbuf.c
+++ b/strbuf.c
@@ -316,0 +316,9 @@
+void strbuf_addstrings(struct strbuf *sb, const char *s, size_t n)
+{
+      size_t len = strlen(s);
+
+      strbuf_grow(sb, st_mult(len, n));
+      for (size_t i = 0; i < n; i++)
+              strbuf_add(sb, s, len);
+}

이번 릴리스 이전에는 -L과 함께 사용할 때 -S(그리고 -G, --word-diff, --color-moved) 같은 옵션들이 조용히 무시되었습니다. 이제는 이들이 자연스럽게 함께 동작합니다. -L은 관심 있는 함수로 출력을 한정하고, -S는 그 안에서 찾고 있는 심볼을 건드린 커밋만으로 다시 좁혀 줍니다.

[source]]

• 우리가 Git 2.47에 대한 논의에서 처음 다루고 Git 2.50에서 후속으로 살펴본 증분 multi-pack index도 이번 릴리스에서 추가 작업이 이루어졌습니다. 이제 MIDX 메커니즘은 compaction 을 지원하는데, 이는 더 작은 MIDX 계층들을 서로 병합하고(연관된 reachability bitmap도 함께) 체인 안의 계층 수가 관리 가능한 수준에 머물도록 해줍니다. 이는 시간이 지나며 많은 계층이 쌓이는 장수 저장소에서 증분 MIDX를 실용적으로 만드는 중요한 단계입니다.

[source]]

• git status는 새로운 status.compareBranches 구성 옵션을 배웠습니다. 기본적으로 git status는 현재 브랜치가 구성된 업스트림과 어떻게 비교되는지 보여줍니다(예: “Your branch is ahead of ‘origin/main’ by 3 commits”). status.compareBranches를 사용하면 푸시 리모트와도 비교하게 하거나, 둘 다와 비교하게 할 수 있습니다.

[status]
   compareBranches = @{upstream} @{push}

이는 업스트림과 푸시 대상이 다른 경우, 예를 들어 한 리모트에서 가져오고 다른 리모트로 푸시하는 삼각형 워크플로(포크 등)에서 특히 유용합니다.

[source]]

• 일련의 커밋이 있고, 그 각각에 trailer를 추가하고 싶다고 해봅시다. 수동으로 할 수도 있고, git rebase -x ‘git commit --amend --no-edit --trailer=”Reviewed-by: A U Thor <a href="mailto:<author@example.com>”’ 같은 방식으로 자동화할 수도 있지만, 이것은 꽤 장황합니다.

Git 2.54에서 git rebase는 새로운 --trailer 옵션을 배웠습니다. 이 옵션은 interpret-trailers 메커니즘을 통해 리베이스되는 모든 커밋에 trailer를 추가합니다. 위와 같은 괴물 같은 명령 대신, 이제 git rebase --trailer "Reviewed-by: A <a href="mailto:<a@example.com>"처럼 써서 같은 효과를 얻을 수 있습니다.

[source]]

• 커밋에 서명할 때, signature는 그 서명에 사용된 GPG 키가 이후 만료되었더라도 여전히 유효합니다. 이전에는 Git이 이런 서명을 위협적으로 보이는 빨간색으로 표시했는데, 이는 오해를 불러일으켜 서명 자체가 무효하다고 해석하게 만들 수 있었습니다. 이제 Git은 이후 만료된 키로 만들어졌더라도 유효한 서명을 올바르게 좋은 서명으로 취급합니다.

[source]]

• git blame는 새로운 --diff-algorithm 옵션을 배웠고, 이를 통해 blame 계산에 어떤 diff algorithm(예: histogram, patience, minimal)을 사용할지 선택할 수 있습니다. 이는 저장소 히스토리의 변경 특성에 따라 때때로 의미 있게 다른, 그리고 더 유용한 blame 출력을 만들어낼 수 있습니다.

[source]]

• 내부적으로는 Git의 object database(ODB) 내부 구조를 재구성하는 데 상당한 작업이 들어갔습니다. ODB 소스 API는 플러그형 백엔드 설계를 사용하도록 리팩터링되었고, read_object(), write_object(), for_each_object() 같은 개별 함수가 이제 소스별 함수 포인터를 통해 디스패치됩니다. 오늘날 이것이 사용자에게 직접 보이진 않지만, 대체 저장 백엔드나 더 유연한 객체 데이터베이스 구성 같은 미래 기능의 기반을 마련합니다.

[source,source,source,source]]

• partial clone에서 누락된 blob을 다운로드하는 실험적 명령 git backfill은 revision 및 pathspec 인수를 받을 수 있게 되었습니다. 이전에는 backfill이 항상 전체 트리에 걸쳐 HEAD에서 도달 가능한 blob을 다운로드했습니다. 이제는 특정 히스토리 범위(예: git backfill main~100..main)나 경로의 하위 집합(예: git backfill -- '*.c')으로 범위를 제한할 수 있으며, 와일드카드가 있는 pathspec도 포함됩니다.

이제 large partial clone에서 저장소의 특정 영역에 대한 과거 blob만 필요할 때 backfill이 훨씬 더 실용적이 되었습니다.

[source]]

• Git의 alias 구성은 역사적으로 ASCII 영숫자와 하이픈만 허용되었습니다. 그래서 “hämta”(스웨덴어로 “fetch”)나 “状態”(일본어로 “status”) 같은 alias 이름은 사용할 수 없었습니다. Git 2.54는 새로운 subsection 기반 문법으로 이 제한을 없앴습니다.

[alias "hämta"]
    command = fetch

기존의 [alias] co = checkout 문법은 ASCII 이름에 대해 계속 작동합니다. 새로운 subsection 형식은 어떤 문자든(줄바꿈과 NUL 바이트 제외) 지원하며, 원시 바이트 기준 대소문자를 구분해 일치시키고, alias 정의에는 command 키를 사용합니다. 셸 완성 기능도 이러한 alias를 처리할 수 있도록 갱신되었습니다.

[source, source]]

• histogram diff algorithm은 미묘한 출력 품질 문제에 대한 수정도 받았습니다. 어떤 diff algorithm이든 실행된 뒤 Git은 더 깔끔한 출력을 만들기 위해 변경 그룹을 이동하고 병합하는 “compaction” 단계를 수행합니다. 어떤 경우에는 이런 이동 때문에 histogram 알고리즘이 선택한 앵커 줄을 가로질러 변경 그룹이 움직일 수 있었고, 그 결과 기술적으로는 맞지만 시각적으로는 중복된 diff가 생성되곤 했습니다. 이제 Git은 이런 상황을 감지하고 영향받은 영역을 다시 diff하여, 기대에 더 잘 맞는 더 간결한 출력을 만들어냅니다.

[source]]

…빙산의 나머지

이것은 최신 릴리스의 변경 사항 중 일부에 불과합니다. 더 자세한 내용은 2.53 및 2.54의 릴리스 노트, 또는 Git 저장소의 이전 버전 전체를 확인해 보세요.

---

태그:

• Git

작성자

Taylor Blau

@ttaylorr

Taylor Blau는 GitHub의 Principal Software Engineer로 Git을 담당하고 있습니다.

• Git

목차

• git history로 히스토리 다시 쓰기
• 구성 기반 훅
• 유지 관리 중 기하학적 repack이 기본값으로
• 빙산의 일각…
• …빙산의 나머지

Git에 대한 더 많은 글

Git 2.52의 주요 하이라이트

오픈 소스 Git 프로젝트가 방금 Git 2.52를 릴리스했습니다. 지난번 이후 도입된 가장 흥미로운 기능과 변경 사항 몇 가지를 GitHub의 시선으로 살펴보겠습니다.

Taylor Blau

Git 20주년, GitHub 본사에서의 2일: Git Merge 2025 하이라이트 🎉

Git Merge 2025는 Git의 20주년을 기념하며 발표, 협업, 커뮤니티를 함께했습니다. 하이라이트와 녹화를 확인해 보세요.

Lee Reilly

관련 게시물

Maintainers

AI 시대의 오픈 소스 멘토십 다시 생각하기

기여량이 늘어나면서 멘토십 신호는 읽기 더 어려워졌습니다. 3 Cs 프레임워크는 메인터레이너가 더 전략적으로 멘토링하면서도 번아웃을 피하도록 도와줍니다.

Abigail Cabunoc Mayes

Maintainers

오픈 소스를 만들어 가는 사람들에 투자하고 함께 미래를 안전하게 지키기

GitHub가 메인터레이너를 지원하는 오픈 소스 보안 자금에 투자하고, Alpha-Omega와 협력하며, 부담을 줄이고 소프트웨어 공급망을 강화하기 위한 지원 접근성을 확대하는 방법을 확인해 보세요.

Kevin Crosby

AI & ML

GitHub Security Lab의 오픈 소스 AI 기반 프레임워크로 취약점을 스캔하는 방법

GitHub Security Lab Taskflow Agent는 Auth Bypasses, IDOR, Token Leaks 및 기타 영향도가 큰 취약점을 찾아내는 데 매우 효과적입니다.

Man Yue Mo&Peter Stöckli

GitHub에서 더 둘러보기

문서

GitHub를 마스터하는 데 필요한 모든 것이 한곳에 있습니다.

문서로 이동

GitHub

GitHub는 어디서든 누구나 무엇이든 만들 수 있는 곳입니다. GitHub에서 다음 것을 만들어 보세요.

빌드 시작하기

고객 사례

GitHub로 빌드하는 기업과 엔지니어링 팀을 만나보세요.

자세히 알아보기

The GitHub Podcast

GitHub 팟캐스트를 따라잡아 보세요. GitHub의 오픈 소스 개발자 커뮤니티 안팎의 주제, 트렌드, 이야기, 문화를 다루는 쇼입니다.

지금 듣기

뉴스레터도 있습니다

개발자만을 위한 격주 뉴스레터에서 팁, 기술 가이드, 모범 사례를 받아보세요.

이메일 주소

*이메일 주소

구독

• 예, GitHub와 계열사가 개인 맞춤형 커뮤니케이션, 타기팅 광고 및 캠페인 효과 측정을 위해 제 정보를 사용하는 데 동의합니다. 자세한 내용은 GitHub Privacy Statement를 참조하세요.

구독

사이트 전체 링크

제품

• 기능
• 보안
• 엔터프라이즈
• 고객 사례
• 가격
• 리소스

플랫폼

• 개발자 API
• 파트너
• Atom
• Electron
• GitHub Desktop

지원

• 문서
• 커뮤니티 포럼
• 교육
• 상태
• 문의하기

회사

• 소개

• 블로그

• 채용

• 보도자료

• 상점

• © 2026 GitHub, Inc.

• 이용 약관

• 개인정보 처리방침

• 쿠키 관리

• 내 개인 정보를 공유하지 않기

• GitHub on LinkedIn

• GitHub on Instagram

• GitHub on YouTube

• GitHub on X

• GitHub on TikTok

• GitHub on Twitch

• GitHub’s organization on GitHub