도착 de 힘내 2.54 이는 세계에서 가장 널리 사용되는 소프트웨어 개발용 버전 관리 시스템의 진화에 있어 새로운 발걸음을 의미합니다. 130명이 넘는 사람들이 참여한 이번 프로젝트 커뮤니티는 Git의 강력한 기능을 유지하면서도 일반적인 작업을 간소화하는 데 집중했습니다.
새로운 기능 중 가장 흥미로운 것은 다음과 같은 새로운 방식일 것입니다. 역사를 다시 쓰다 훨씬 더 직접적인 방식으로, 공통 구성 파일에서 공유 후크를 구성하는 기능과 특히 대규모 또는 기업 프로젝트에서 더 빠르고 유지 관리가 쉬운 저장소를 추구하는 내부 개선 사항이 있습니다.
Git 2.54: 새 릴리스 개요
Git 2.54는 향후 3.0 브랜치로 가는 중간 버전이지만, 많은 개발자의 일상적인 작업에 영향을 미치는 변경 사항을 포함하고 있습니다. 예를 들어, 실험적인 명령어인 git history가 출시되었습니다.간단한 이력 재작성 작업을 위해 설계되었습니다. 또한, 후크 시스템이 확장 및 현대화되어 이제 설정에서 관리할 수 있으며, 기하학적 유지 관리 전략이 기본값으로 설정되었습니다.
또한, 기존에 알려진 명령어에도 개선 사항이 포함되어 있습니다. git add -p, git replay, git status 또는 git rebaseHTTP 전송 방식, GPG 서명 표시 방식, 객체 데이터베이스의 내부 작동 방식 등에도 조정이 이루어졌습니다. 이러한 새로운 기능들은 대부분 고급 기능이지만, 기업, 공공기관, 대규모 저장소를 보유한 오픈 소스 프로젝트의 일반적인 워크플로우에서 상당한 영향을 미칠 것입니다.
새로운 실험적 명령어인 git history: 커밋을 쉽게 다시 작성할 수 있습니다.
Git 2.54의 주요 추가 기능 중 하나는 다음과 같습니다. git 기록이는 대화형 리베이스를 사용하는 것이 과도한 경우를 처리하기 위해 고안된 아직 실험적인 명령어입니다. 지금까지 로컬 히스토리를 수정하는 데 주로 사용되는 도구는 다음과 같습니다. git rebase -i매우 유연하지만 더 복잡하고 사용자가 수동으로 해결해야 하는 충돌 상태에 빠지기 쉽습니다.
와 git 기록 특정 작업에는 보다 직접적인 접근 방식이 필요합니다. 예를 들어, 오타를 수정하세요 몇 번의 변경 전 커밋 메시지에서 수정하거나, 너무 커진 커밋을 두 개로 분할하는 등의 작업을 할 때 유용합니다. 이 아이디어는 작업 목록과 중간 단계를 포함하는 대화형 리베이스의 전체 메커니즘을 설정하지 않고도 히스토리를 제어할 수 있는 방법을 제공하는 것입니다.
reword 하위 명령: 작업 트리를 건드리지 않고 커밋 메시지를 수정합니다.
새로운 질서가 시작하는 첫 번째 모드는 다음과 같습니다. git history reword <commit>Git을 실행하면 사용자가 구성한 편집기가 열립니다. 지정된 커밋 메시지이를 통해 직접 수정할 수 있습니다. 편집기를 저장하고 닫으면 Git은 해당 커밋을 다시 작성하고 해당 커밋에서 파생된 브랜치를 자동으로 업데이트하여 새 버전을 가리키도록 합니다.
인터랙티브 리베이스와 비교했을 때 가장 큰 차이점은 다음과 같습니다. `git history reword`는 작업 트리나 인덱스를 건드리지 않습니다.이 기능은 히스토리만 업데이트합니다. 따라서 지속적 통합 환경이나 자동화 스크립트에서 특히 유용하며, 작업 트리가 연결되지 않은 회사나 기관의 내부 코드 서버에서 흔히 볼 수 있는 베어 리포지토리에서도 작동할 수 있습니다.
split 하위 명령: 커밋을 대화형으로 분할합니다.
두 번째 모드, git history split <commit>이 기능은 하나의 커밋에 분리해야 할 변경 사항이 포함된 상황을 위해 설계되었습니다. 실행하면 Git은 해당 커밋과 연결된 덩어리들을 표시하고, `git extract`와 유사하게 어떤 덩어리를 새로운 상위 커밋으로 추출할지 선택할 수 있도록 합니다. 자식 추가 -p 인덱스에 추가할 코드 조각을 결정할 때.
조각들이 선택되면 Git은 파일을 생성합니다. 선택된 덩어리들을 원래 커밋의 부모로 하는 새로운 커밋이 생성되었습니다.이 작업은 이전 커밋에서 선택되지 않은 변경 사항을 유지합니다. 그런 다음 하위 브랜치를 새로운 히스토리 구조를 가리키도록 다시 작성합니다. 이 작업은 현재 작업 트리의 내용을 변경하지 않고 실행되므로 저장소가 복잡한 중간 상태로 남을 가능성을 줄입니다.
제한 사항 및 다른 워크플로와의 호환성
행동을 통제 가능한 상태로 유지하기 위해, Git 히스토리는 병합 커밋이 포함된 히스토리를 지원하지 않습니다. 병합 충돌이 발생하면 작업을 계속 진행하지 않습니다. 이는 사소한 조정을 위해 설계되었으며, 일반적으로 다른 방법으로 처리되는 대규모 재작성 작업에는 적합하지 않습니다. git rebase -i 또는 보다 적극적인 이력 삭제 전략.
내부적으로 명령은 메커니즘에 의존합니다. git 리플레이이는 작업 트리를 건드리지 않고 다른 베이스에서 커밋을 재현하는 실험적인 도구로 자리 잡고 있습니다. 이 작업의 일부는 해당 로직을 공통 라이브러리로 추출하는 것으로, 이를 통해 두 경우 모두에서 사용할 수 있게 되었습니다. git history 향후 다른 기능들도 스크립트나 타사 도구를 통해 자동화하기 쉬운 모듈식 인프라의 이점을 누릴 수 있을 것입니다.
설정 기반 후크: 자동화 공유 및 결합
Git 2.54의 또 다른 주목할 만한 새로운 기능은 다음과 같습니다. 설정 파일에서 직접 훅을 정의하세요디렉터리에 있는 스크립트에만 의존하는 대신에 .git/hooks 또는 표시된 경로에서 core.hooksPath이번 변경으로 파일을 수동으로 복제하지 않고도 여러 저장소 간에 검사를 공유하는 것이 훨씬 쉬워졌습니다.
지금까지는 예를 들어 여러 프로젝트에 걸쳐 각 커밋 전에 코드 포맷터나 시크릿 분석기를 적용하려면 후크 스크립트를 각 저장소에 복사하거나 외부 후크 관리 도구를 사용해야 했습니다. 새로운 접근 방식을 사용하면 이를 정의할 수 있습니다. 중앙 후크 ~/.gitconfig 또는 /etc/gitconfig 기업의 법인으로서 이러한 원칙들이 필요한 경우에 적용되어야 한다는 것입니다.
설정을 통해 후크를 정의하고 이벤트당 여러 명령을 실행할 수 있습니다.
새로운 구문은 스타일 구성 키를 기반으로 합니다. hook.<nombre>.command y hook.<nombre>.event첫 번째는 실행될 명령어를 나타내고, 두 번째는 구체적인 내용을 지정합니다. 어떤 훅 이벤트가 그것을 트리거하는가?예를 들면 pre-commit 또는 pre-push표준 구성이므로 이러한 설정은 사용자, 시스템 또는 저장소 수준 등 다양한 수준에서 공존할 수 있습니다.
게다가 Git은 이제 다음을 허용합니다. 하나의 이벤트에 여러 개의 후크가 할당됩니다.즉, 예를 들어 각 파일에서 실행할 린터와 자격 증명 스캐너를 정의할 수 있습니다. pre-commit여러 스크립트를 수동으로 조합할 필요 없이 Git은 구성 항목을 순서대로 순회하며 각 명령을 실행하는 동시에 기존 스크립트도 지원합니다. $GIT_DIR/hooks이는 이전 설정을 손상시키지 않도록 마지막까지 계속 실행됩니다.
후크의 관리, 비활성화 및 내부 현대화
어떤 후크가 활성화되어 있는지, 그리고 어디에서 왔는지 확인하기 위해 다음 명령어가 포함됩니다. git hook list각각의 출처를 보여주는데, 이는 관리할 때 유용한 정보입니다. 중앙 집중식 구성 기업 환경에서 특정 저장소가 전역 파일에서 상속받은 후크를 제외해야 하는 경우, 다음과 같이 설정하면 됩니다. hook.<nombre>.enabled = false기존 설정을 삭제하거나 수정할 필요 없이 가능합니다.
Git의 내부 작동 방식은 다음과 같습니다. 내부 연결 방식을 통합하고 현대화했습니다.이전에 임시 경로(예: 후크)를 사용하여 관리되었던 여러 통합 지점 pre-push, post-rewrite 또는 receive-pack이제 새로운 훅 API를 사용하고 있습니다. 이는 일관성을 제공할 뿐만 아니라, 지속적 통합 환경이나 코드 생성 플랫폼이 특정 통합 코드를 다시 작성할 필요 없이 향후 변경 사항에 더 쉽게 적응할 수 있도록 해줍니다.
기하학적 유지 관리를 기본 전략으로 사용
이전 버전에서 Git은 소위 전략이라는 것을 도입했습니다. 기하학적 이내 git maintenance이 전략은 대규모 저장소에서 재패키징 작업 비용을 줄이기 위해 설계되었으며, 기존 팩파일을 분석하고 객체 수에 따라 기하급수적으로 증가하는 조합을 찾아 매번 전체 가비지 컬렉션을 수행할 필요 없이 콘텐츠를 압축합니다.
Git 2.54부터는 이 접근 방식이 다음과 같이 됩니다. 수동 유지 관리의 기본 옵션실행될 때 git maintenance run 전략을 지정하지 않으면, 고전적인 방법을 직접 사용하는 대신 기하학적 접근 방식이 자동으로 선택됩니다. gc 모든 것을 하나의 패키지로 묶으려고 시도합니다.
실제로 이는 다음을 의미합니다. 저장소가 더욱 효율적으로 관리됩니다. 처음부터 이 전략은 특히 오랜 역사를 가진 프로젝트나 대규모 단일 저장소를 관리하는 조직에 매우 유용합니다. 기하학적 전략은 타당할 때 증분 패키지를 결합하고, 필요한 경우에만 단일 패키지를 사용합니다. gc 모든 내용을 하나의 팩파일로 통합하는 작업이 실제로 완료되면 작업이 완료됩니다. 이 과정 동안 커밋 그래프, 리프레시 로그 및 기타 보조 구조는 최신 상태로 유지됩니다.
이미 설정을 완료한 사람들 maintenance.strategy = geometric 그들의 선호가 존중되므로 아무런 변화도 느끼지 못할 것입니다. 그리고 전통적인 방식을 고수하고 싶은 사람들은 다음과 같이 할 수 있습니다. 전략을 강제로 실행하라 gc 구성 maintenance.strategy = gc따라서 보다 보수적인 흐름과의 호환성을 유지합니다.
대화형 및 실험적 명령 개선
주요 신기능 외에도 Git 2.54는 다양한 변경 사항을 포함하고 있으며, 이는 모두 다음과 같은 목표를 지향합니다. 일상적인 사용자 경험을 개선합니다특히 변경 사항을 관리하기 위해 대화형으로 사용되는 명령에서 그렇습니다.
git add -py 새로운 탐색 옵션의 개선 사항
인터랙티브 모드 git add -p 관련 명령에 다양한 사용성 개선 사항이 적용되었습니다. 키를 사용하여 덩어리 사이를 탐색할 때 J y KGit은 이제 조각이 있는지 여부를 보여줍니다. 이전에 승인되었거나 건너뛰어졌습니다.각각의 결정을 수동으로 기억해야 하는 번거로움을 피할 수 있습니다.
해당 옵션도 추가되었습니다. --no-auto-advance이는 파일의 일부를 처리하는 작업을 완료할 때의 동작을 변경합니다. 자동으로 다음 파일로 이동하는 대신 세션이 현재 파일에 유지되므로 계속 사용할 수 있습니다. < y > 파일 간 이동을 더욱 여유롭게 할 수 있습니다. 이러한 작업 방식은 변경 사항을 확정하기 전에 전체 변경 내용을 검토하려는 경우에 유용합니다.
Git 리플레이: 커밋 재실행 기능의 완성도 향상
실험 순서 git 리플레이작업 트리를 수정하지 않고 새로운 베이스에 커밋을 복제하도록 설계된 기능이 계속해서 개선되고 있습니다. 이번 버전에서는 다음과 같은 기능을 수행합니다. 참조를 원자적으로 업데이트합니다 기본적으로 명령어를 덤프하는 대신 update-ref 표준 출력에.
또한, 모드를 포함하고 있습니다. --revert 허용 특정 커밋 범위의 변경 사항을 되돌립니다.이 기능은 처리 과정 중에 내용이 비어 있는 커밋을 폐기할 수 있으며, 이제 루트 커밋까지 히스토리를 되돌려 재생하는 기능을 지원합니다. 이러한 개선 사항은 사용 목적에 잘 부합합니다. git history이는 더 안전한 경험을 제공하기 위해 동일한 인프라를 활용합니다.
새로운 옵션 - git 리베이스의 트레일러
또 다른 흥미로운 조정 사항은 다음과 같은 사항의 추가입니다. --trailer en 자식 rebase이는 논리를 이용하는 것이다. interpret-trailers 파라 오버샷 커밋마다 동일한 트레일러를 추가합니다.긴 명령어를 만드는 대신 -x 그리고 전화 git commit --amend --no-edit --trailer=...오버런을 실행할 때 원하는 트레일러를 직접 지정할 수 있습니다.
이는 활자 입력과 같은 반복적인 작업을 크게 간소화합니다. Reviewed-by: 또는 커밋 시리즈와 유사한 주석을 사용하는데, 이는 분산된 팀에서 사용되는 공식적인 코드 검토 프로세스에서 흔히 볼 수 있는 것입니다.
HTTP 전송 및 서명 관리: 더욱 정교해진 동작
네트워크 통신 측면에서 Git 2.54는 HTTP 응답 처리 방식과 커밋 및 태그와 관련된 암호화 서명 해석 방식에 중요한 변경 사항을 도입했습니다.
HTTP 429 응답 관리 및 재시도 설정 가능
Git의 HTTP 전송 방식은 코드를 올바르게 해석하는 방법을 학습합니다. 429 «너무 많은 요청»지금까지 서버에서 429 오류가 반환되면 치명적인 오류로 간주되어 작업이 실패했습니다. 하지만 이번 버전부터 Git은 헤더 값을 유지하면서 요청을 재시도할 수 있습니다. Retry-After 존재하는 경우 또는 새로운 옵션을 통해 구성 가능한 지연 시간을 사용합니다. http.retryAfter.
조정 사항도 추가됩니다. http.maxRetries y http.maxRetryTime, 허용 최대 재시도 횟수와 재시도에 소요되는 총 시간을 제어합니다.이는 과부하된 서버나 엄격한 요청 제한 정책이 적용되는 서버에 접근해야 하는 기업 환경에서 실용적이며, 운영 효율화에 도움이 됩니다. fetch y push 서버에 부담을 주지 않으면서 복원력을 높입니다.
만료된 키를 사용한 GPG 서명 처리
보안과 관련하여 오해의 소지가 있는 동작이 수정되었습니다. 만료된 GPG 키로 커밋에 서명한 경우 Git이 서명을 표시하는 문제가 있었습니다. 불안감을 주는 붉은색이는 서명이 유효하지 않다는 것을 시사했습니다. 그러나 서명이 당시 유효했다면, 키가 만료되었더라도 그 유효성은 유지되어야 합니다.
Git 2.54는 이러한 논리를 조정하고 다음 사항을 고려합니다. 키가 만료되기 전에 올바르게 생성된 서명은 유효합니다.이렇게 하면 불필요한 알림을 방지할 수 있습니다. 또한 저장소의 이력을 더욱 정확하게 파악할 수 있는데, 이는 기관이나 공공 행정 소프트웨어처럼 수년간 유지 관리되는 장기 프로젝트에 특히 중요합니다.
새로운 검사 기능 및 이력 맞춤 설정
과거 기록을 탐색하도록 설계된 몇 가지 명령이 개선되어 유연성이 향상되고 각 경우에 더욱 맞춤화된 출력을 제공할 수 있게 되었습니다.
`git log -L`은 표준 diff 기능과 통합됩니다.
선택 git log -L특정 파일에서 특정 범위의 행 변화를 추적할 수 있는 기능이 재구현되어 출력 경로가 변경되었습니다. 표준 Git diff 메커니즘이전에는 자체 경로를 사용했기 때문에 다음과 같은 매우 유용한 옵션과 호환되지 않았습니다. -S y -G (소위 "곡괭이") 또는 다양한 패치 형식을 사용합니다.
Git 2.54에서 도입된 변경 사항으로 인해, -L 호환 가능해집니다 고급 콘텐츠 및 다양한 형식 검색포함 --word-diff o --color-moved이러한 방식으로 출력을 특정 기능으로 제한하는 동시에 특정 심볼을 추가하거나 제거하는 커밋만 필터링할 수 있으므로 코드 감사 및 회귀 분석이 용이해집니다.
diff 알고리즘 선택을 사용한 git blame
명령 git blame파일의 각 줄이 어떤 커밋에 추가되었는지 확인하는 데 사용되는 이 기능은 새로운 옵션을 학습합니다. --diff-algorithm이를 통해 라인 기여도를 계산할 때 히스토그램, 페이션스 또는 최소값과 같은 다양한 차이 알고리즘 중에서 선택할 수 있습니다.
파일이 겪은 변경 유형에 따라, 알고리즘을 하나 선택하면 더 명확한 결과를 얻을 수 있습니다.이렇게 하면 코드 변경 이력이 많이 기록되는 곳에서 발생하는 노이즈를 줄일 수 있습니다. 상세한 코드 리뷰가 매우 중요한 환경에서는 특정 코드 블록을 누가 추가했는지 조사할 때 이러한 수준의 제어가 매우 중요할 수 있습니다.
스토리지 최적화 및 객체 데이터베이스
이번 버전의 변경 사항은 사용자 인터페이스에만 국한되지 않습니다. Git의 작동 방식에도 상당한 개선이 이루어졌습니다. 내부적으로 데이터를 구성하고 접근합니다.이는 특히 대규모 저장소에 상당한 영향을 미칩니다.
증분 다중팩 지수 및 압축
전화 멀티팩 증분 인덱스(MIDX)이전 버전에서 이미 개선되었던 기능들이 Git 2.54에 추가되어 레이어 압축 기능을 지원합니다. 이 메커니즘은 더 작은 MIDX 레이어와 해당 레이어에 연결된 도달 가능성 비트맵을 결합하여 레이어 체인의 크기를 적절한 수준으로 유지합니다.
이 단계는 중요합니다. 장기 저장소에서 MIDX의 점진적 사용을 실용화하기대규모 조직이나 오랜 역사를 가진 커뮤니티 프로젝트와 같은 경우에 유용합니다. 계층 구조를 압축하면 검색의 복잡성이 줄어들고 다음과 같은 작업의 성능이 향상됩니다. fetch, clone 부분 검사 또는 이력 검사.
객체 데이터베이스(ODB) 구조 조정
내부적으로는, 객체 데이터베이스 API의 심층적인 리팩토링 (ODB). 현재는 플러그인 방식의 백엔드 설계가 사용되고 있으며, 여기에는 다음과 같은 기능들이 포함됩니다. read_object(), write_object() o for_each_object() 함수 포인터를 사용하여 발신 지점별로 전달됩니다.
이러한 변화는 최종 사용자에게 즉시 눈에 띄지는 않지만, 향후 발전을 위한 토대를 마련합니다. 미래의 대체 스토리지 백엔드 또는 더욱 유연한 객체 데이터베이스 구성을 제공합니다. 특정 규정 준수 요건이 있거나 자체 스토리지 시스템과의 통합이 필요한 기업의 경우, 이러한 모듈화 기능을 통해 더욱 맞춤화된 솔루션을 구현할 수 있습니다.
상태, 별칭, 데이터 보충 및 기타 세부 정보 개선
Git 2.54에는 사소한 변경 사항이지만, 일상적인 사용성을 개선하고 다양한 언어 및 네트워크 환경에 Git을 적용하는 데 도움이 되는 여러 가지 조정 사항이 포함되어 있습니다.
git 상태와 여러 원격 브랜치와의 비교
명령 자식 상태 구성 옵션이 새롭게 추가되었습니다. status.compareBranches기본적으로 이 명령은 현재 브랜치가 설정된 업스트림과 어떻게 비교되는지 보여줍니다. 예를 들어 다음과 같은 일반적인 결과입니다. origin/main새로운 옵션을 사용하면 푸시 브랜치와 비교를 요청하거나 두 브랜치 모두와 동시에 비교를 요청할 수 있습니다.
이 기능은 다음과 같이 설계되었습니다. 삼각형 흐름포크를 사용할 때 흔히 발생하는 문제로, 공식 원격 저장소에서 다운로드하고 다른 저장소로 변경 사항을 보낼 수 있습니다. 이렇게 하면 각 브랜치 간의 커밋 수를 항상 명확하게 파악할 수 있어 저장소 동기화 시 예상치 못한 문제를 줄일 수 있습니다.
국제 문자를 사용한 별칭
지금까지 Git 별칭은 ASCII 영숫자 및 하이픈으로 제한되어 있어 악센트가 있거나 다른 알파벳을 사용하는 언어 이름을 사용할 수 없었습니다. 새로운 구문은 줄 바꿈과 널(NUL)을 제외한 거의 모든 문자를 지원합니다. 일치 여부는 원시 바이트 단위로 처리되며 대소문자를 구분합니다. 또한 셸 자동 완성 시스템이 이러한 별칭을 지원하도록 업데이트되어 다국어 팀에서 Git을 더욱 쉽게 사용할 수 있게 되었습니다.
Git backfill은 부분 복제본에서 더 실용적입니다.
실험 명령 git 백필부분 복제본에서 누락된 블롭을 다운로드하는 데 사용되는 명령도 강화되고 있습니다. 이전에는 이 명령이 항상 접근 가능한 블롭만 가져왔습니다. HEAD 전체 트리 구조에 걸쳐 저장되므로 특히 대규모 저장소에서는 과도할 수 있습니다.
Git 2.54는 다음을 지원합니다. 검토 인수 및 경로 사양되메우기 범위를 특정 이력 범위로 제한할 수 있도록 (예를 들어, main~100..main) 또는 특정 경로로 (git backfill -- '*.c'와일드카드 패턴을 포함한 다양한 기능을 지원합니다. 이를 통해 코드의 특정 부분만 복원하면 되는 대규모 부분 복제본 작업을 훨씬 수월하게 처리할 수 있습니다.
기타 조정 및 세부 개선 사항
Git 2.54 변경 로그에는 여러 가지 사소한 개선 사항이 포함되어 있습니다. 그중 하나는 diff 알고리즘 수정입니다. 막대 그래프이제 압축 단계에서 선택된 기준선을 끊는 방식으로 변화 그룹을 이동시키는 것을 방지하여 더 깨끗하고 중복이 적은 차이를 생성합니다.
다음과 같은 도구 git config list 이는 설정 목록을 표시하는 공식적인 방법으로 자리 잡고 있습니다. git merge-file 그러면 저장소 외부에서도 사용 가능한 구성을 존중하며, 몇 가지 관련 유틸리티가 제공됩니다. git send-email클라이언트 인증서 지원 및 사용자가 선택한 문자 집합에 대한 더욱 세심한 처리 기능이 추가되었습니다.
Git의 발전은 2.54 버전에서 좋은 속도로 계속되고 있으며, 이 버전은 여러 기능을 결합합니다. 사용자에게 눈에 띄는 개선 사항새로운 질서처럼 git history 또는 구성 가능한 후크를 사용하는데, 이는 시스템 내부 인프라에 상당한 작업이 필요합니다. 이 모든 것은 점점 더 커지는 저장소와 더욱 다양해지는 팀의 과제에 더 잘 대비할 수 있는 더욱 견고하고 유연한 생태계를 지향합니다.
