到着 de Git 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 の主な追加機能の 1 つは、 Git履歴は、対話型リベースを使うのが過剰な場合に対応することを目的とした、まだ実験段階のコマンドです。これまで、ローカル履歴を変更するための定番ツールは git rebase -i非常に柔軟性がある反面、より複雑で、ユーザーが矛盾した状態に陥りやすく、手動で解決する必要が生じる可能性がある。
とともに Git履歴 特定のタスクには、より直接的なアプローチが求められます。たとえば、 誤字を修正する 数回前のコミットのメッセージを変更したり、大きくなりすぎたコミットを2つに分割したりする場合などに便利です。このアイデアは、タスクリストや中間ステップを含む対話型リベースの仕組み全体をセットアップすることなく、履歴を制御された方法で微調整できるようにすることです。
rewordサブコマンド：作業ツリーに手を加えずにコミットメッセージを微調整する
新体制が最初に開始するモードは git history reword <commit>Git が起動すると、ユーザーが設定したエディタが開きます。 指定されたコミットメッセージこれにより、直接編集が可能になります。保存してエディタを閉じると、Git はそのコミットを書き換え、そこから派生したブランチを自動的に更新して新しいバージョンを指すようにします。
インタラクティブなリベースとの主な違いは、 `git history reword` は作業ツリーにもインデックスにも手を加えません履歴のみを更新するため、継続的インテグレーション環境や自動化スクリプトにおいて特に有用です。また、関連する作業ツリーが存在しない企業や機関の内部コードサーバーなど、ベアリポジトリに対しても動作可能です。
splitサブコマンド：コミットを対話的に分割する
2番目のモード、 git history split <commit>これは、単一のコミットに含まれる変更を分離する必要がある場合に設計されています。実行すると、Git はそのコミットに関連付けられたチャンクを表示し、`git extract` と同様に、どのチャンクを新しい親コミットに抽出するかを選択できます。 git add -p インデックスに追加するコードを決定する際に。
フラグメントが選択されると、Git は 元のコミットの親として選ばれたハンクスを含む新しいコミット前のコミットで選択されなかった変更は保持されます。その後、子孫ブランチを書き換えて新しい履歴構造を指すようにします。この操作は、作業ツリーの現在の内容を変更せずに実行されるため、リポジトリが複雑な中間状態になる可能性が低くなります。
制限事項および他のワークフローとの互換性
行動を制御可能にするために、 Gitの履歴機能はマージコミットを含む履歴をサポートしていません。 マージの競合が発生した場合は、処理を続行しません。これは、通常以下のような大規模な書き換えではなく、軽微な調整向けに設計されています。 git rebase -i あるいは、より積極的な履歴消去戦略。
内部的には、コマンドは git replayこれは、作業ツリーに手を加えることなく別のベースでコミットを再現するための実験ツールとして定着しつつあります。この作業の一部は、そのロジックを共通ライブラリに抽出することから成り立っており、両方の git history 将来的に実装される他の機能も、スクリプトやサードパーティツールによる自動化が容易な、よりモジュール化されたインフラストラクチャの恩恵を受けることができる。
設定ベースのフック：自動化の共有と組み合わせ
Git 2.54 のもう 1 つの注目すべき新機能は、 設定ファイル内でフックを直接定義するディレクトリに配置されたスクリプトだけに頼るのではなく .git/hooks または、 core.hooksPathこの変更により、ファイルを手動で複製することなく、異なるリポジトリ間でチェックを共有することがはるかに容易になります。
これまで、例えば複数のプロジェクトにわたってコミットごとにコードフォーマッタやシークレットアナライザーを適用するには、フックスクリプトを各リポジトリにコピーするか、外部のフック管理ツールを使用する必要がありました。新しいアプローチでは、 中央のフック ~/.gitconfig または /etc/gitconfig 企業として、必要に応じてこれらが適用されること。
設定によるフックの定義と、イベントごとの複数コマンド
新しい構文はスタイル設定キーに基づいています hook.<nombre>.command y hook.<nombre>.event最初の部分はどのコマンドが実行されるかを示し、2番目の部分は どのフックイベントがそれをトリガーするか例えば 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 replay作業ツリーを変更せずに新しいベースにコミットを複製するように設計された機能は、引き続き機能を強化しています。このバージョンでは、以下の機能を実行します。 参照をアトミックに更新する デフォルトでは、コマンドをダンプする代わりに update-ref 標準出力で。
さらに、モードを組み込んでいます --revert 許可 複数のコミットからの変更を元に戻す処理中に空になったコミットを破棄することができ、ルートコミットまで履歴を再生することもサポートするようになりました。これらの改善は、 git history同じインフラストラクチャを利用して、より安全な体験を提供します。
新オプション – Gitリベースでのトレーラー
もう一つ興味深い調整は、 --trailer en gitリベースこれは、 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差分メカニズム以前は独自のパスを使用していたため、次のような非常に便利なオプションと互換性がありませんでした。 -S y -G （いわゆる「つるはし」）または異なるパッチ形式。
Git 2.54で導入された変更により、 -L 互換性を持つようになる 高度なコンテンツ検索と異なるフォーマット検索を含む --word-diff o --color-movedこの方法を用いることで、出力を特定の機能に限定できるだけでなく、特定のシンボルを追加または削除するコミットのみをフィルタリングすることも可能になり、コード監査や回帰分析が容易になります。
差分アルゴリズム選択による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 と複数のリモートブランチとの比較
コマンド git status 設定オプションを初公開 status.compareBranchesデフォルトでは、このコマンドは現在のブランチが設定されたアップストリームとどのように比較されるかを示しました。 origin/main新しいオプションを使用すると、プッシュブランチとの比較、または両方との比較を同時に要求できます。
この機能は、 三角形の流れこれはフォークを扱う際によく見られる方法です。公式のリモートからダウンロードして、変更を別のリモートに送信することで、各ブランチ間のコミット数を常に明確に把握でき、リポジトリの同期時に予期せぬ事態が発生するのを減らすことができます。
国際文字を含む別名
これまで、GitのエイリアスはASCII英数字とハイフンに限定されていたため、アクセント記号や異なるアルファベットを含む他言語の名前は使用できませんでした。新しい構文では、改行とNULL文字を除くほぼすべての文字がサポートされます。マッチングは生のバイト列で行われ、大文字と小文字が区別されます。さらに、シェルのオートコンプリートシステムもこれらのエイリアスに対応するように更新され、多言語チームでのGitの使いやすさが向上しました。
Gitバックフィルは部分クローンの方が実用的である
実験コマンド git backfill部分クローンで不足しているブロブをダウンロードするために使用されるコマンドも強化されています。以前は、このコマンドは常に到達可能なブロブを HEAD ツリー全体にわたって、特に大規模なリポジトリでは過剰になる可能性がある。
Git 2.54 では以下のサポートが追加されました 引数とパス指定を確認する埋め戻しを履歴の範囲に制限できるように、 main~100..main）または特定のルートへ（git backfill -- '*.c')、ワイルドカードパターンも含みます。これにより、コードの特定部分の履歴だけを完成させる必要がある大規模な部分クローンを扱うのがはるかに容易になります。
その他の調整と詳細な改善
Git 2.54の変更履歴には、多数の細かな改善点が記載されています。その中には、差分アルゴリズムの修正も含まれています。 ヒストグラムこれにより、圧縮フェーズで変更のグループが選択されたアンカーラインを壊すような方法で移動されることを防ぎ、よりクリーンで冗長性の少ない差分が生成されます。
次のようなツール git config list これは、設定を一覧表示する公式な方法として定着しつつあり、 git merge-file これにより、リポジトリ外でも利用可能な設定が尊重され、関連するユーティリティもいくつか提供されます。 git send-emailこれにより、クライアント証明書のサポートと、ユーザーが選択した文字セットのより慎重な処理が可能になります。
Gitの進化は順調に進んでおり、バージョン2.54では ユーザーにとって目に見える改善新しい秩序のように git history あるいは、システム内部のインフラストラクチャに大幅な変更が必要となる設定可能なフックなどもあります。これらすべては、より堅牢で柔軟なエコシステム、つまり、ますます大規模化するリポジトリや多様化するチームといった課題に、より適切に対応できる体制の構築を示しています。
