Git 2.54リリースのハイライト

Git 2.54 の主な新機能 オープンソースのGitプロジェクトは、137人以上（うち66人が新規）のコントリビューターによる機能追加とバグ修正を含むGit 2.54をリリースしました。前回Gitの最新動向をお伝えしたのは、バージョン2.52が公開された際でした。 今回の最新リリースを記念し、GitHubが前回から導入された主な新機能と変更点を紹介します。  前回記事で取り上げたGitの最新リリースが2.52だったため、本ブログ投稿では2.53および2.54の両方のリリースから主な新機能を取り上げます。 git history で履歴を書き換える Gitプロジェクトは、リポジトリ（repository）の履歴を書き換えるためのツールを提供する長い歴史を持っています。その中でも最もよく知られているのが `git rebase –i` で、非常に柔軟性が高く、コミット（commit）の順序入れ替え、スクイッシュ（squash）、編集、削除が可能です。しかし、その柔軟性には複雑さが伴います。インタラクティブリベース（interactive rebase）はコミットの範囲に対して動作し、進行中に作業ツリー（working tree）とインデックス（index）を更新するため、先に進む前に解決が必要なコンフリクト状態に陥る可能性があります。 より単純なケースでは、これらの仕組みはやりすぎに感じられることがあります。3つ前のコミットメッセージのタイプミスを修正したいだけの場合、あるいは1つのコミットを2つに分割したいだけのケースでは、インタラクティブリベースでも動作しますが、ToDoリストの準備、編集対象のコミットの指定、そしてリベースの完了までの実行という手順が必要になります。 Git 2.54 では、まさにこれらの単純なケース向けに設計された新しい実験的コマンド `git history` が導入されました。この `history` コマンドは現在、2つの操作をサポートしています：reword（メッセージ変更）と split（分割）。 `git history reword` は、指定されたコミットのメッセージをエディターで開き、その場で書き換えます。これにより、そのコミットから分岐するすべてのブランチが更新されます。`git rebase` とは異なり、作業ツリー（working tree）やインデックス（index）に触れることなく、ベアリポジトリ（bare repository）でも動作します。 `git history split` を使用すると、どのハンク（hunks）を新しい親コミットに切り出すかを選択することで、インタラクティブに1つのコミットを2つに分割できます。`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 ハンク（hunks）の選択が完了すると、Git はそれらの変更を含む新しいコミットを作成し、それを元のコミットの親とします（元のコミットには選択されなかったハンクが保持されます）。その後、更新された履歴を指すように、子孫ブランチのすべてを書き換えます。 注意すべき意図的な制限がいくつかあります。`history` コマンドはマージコミット（merge commits）を含む履歴をサポートしておらず、マージコンフリクトが発生する操作は実行しません。設計上、`git history` は特定の対象に対する非インタラクティブな書き換えを目的としており、通常は `git rebase –i` に委ねられるような広範な履歴書き換えには向きません。 同時に、Gitのフック（hooks）内部処理が近代化されました。以前はアドホックなコードパスを介して呼び出されていた多くのビルトインフック（pre-push、post-rewrite、各種receive-packフックなど）が新しいフックAPI（hook API）の使用に移行され、これらすべてが新しい設定ベースのフック機構から恩恵を受けるようになりました。 [source, source, source] 保守作業におけるデフォルトの幾何学的リパック（geometric repacking） 本シリーズの既存読者なら、Git 2.52で導入されたgit maintenance内の新しい幾何学的戦略（geometric strategy）に関する当社の解説を覚えているかもしれません。この戦略はリポジトリの内容を検証し、オブジェクト数によって幾何級数を形成できる数のpackfile（パックファイル）を結合できるかどうかを判定して動作します。可能であれば、Gitは幾何学的リパックを実行し、フルガーベジコレクション（full garbage collection）を実行することなくリポジトリの内容を圧縮します。 2.52では、幾何学的戦略はmaintenance.strategy設定を介してオプトイン（任意選択）として利用可能でした。2.54では、手動保守のデフォルト戦略となります。つまり、戦略を指定せずにgit maintenance runを実行した場合、Gitは従来のgcタスクの代わりに幾何学的アプローチを使用するようになります。 実際、これは初期設定のままリポジトリがより効率的に保守されることを意味します。幾何学的戦略はgcが行う高コストな全リパック（all-into-one repacks）を回避し、可能であればパックを段階的に結合し、リポジトリ全体を単一のパックに統合する場合のみフルgc（full gc）にフォールバックします。その過程で、コミットグラフ（commit-graph）、reflogs、その他の補助データ構造を最新に保ちます。 設定で既にmaintenance.strategy = geometricを使用している場合、変更はありません。戦略を設定していない（または従来のgcデフォルトに依存していた）場合、幾何学的リパックの恩恵が自動的に適用され始めます。gc戦略を好む場合は引き続き利用可能で、maintenance.strategy = gcで選択できます。 [source] 氷山の一角…… 大きな変更のいくつかを詳しくカバーしたところで、今回は今回のリリースにおけるその他の新機能と更新の一部をより詳しく見ていきましょう。 Gitの個別ハunks（hunks）をインタラクティブにステージングするためのツールであるgit add –pコマンドは、今回のリリースでいくつかの使いやすさの向上を受けました。JキーとKキーでハunks間を移動する際、Gitは各ハunkを以前に受け入れたかスキップしたかを示すようになり、以前の決定を覚えておく必要がなくなりました。 別個に、新しい--no-auto-advanceフラグはgit add –pがファイル間の遷移を処理する方法を変更します。通常、ファイル内のすべてのハunksに対する決定を下すと、セッションは自動的に次のものに進みます。--no-auto-advanceを使用すると、最後のハunksに対する決定後もセッションはその場に留まり、独自のペースでファイル間を移動できるようになります。これは、コミットする前に決定を全体的にレビューしたい場合に有用です。 [source, source] git replay（作業ツリーに触れずに新しいベース上にコミットを再生する実験的コマンド）は、引き続き成熟しています。今回のリリースではいくつかの改善がもたらされました：replay はデフォルトで原子参照更新（atomic reference updates）を実行するようになり（stdout に update-ref コマンドを出力する代わりに）、新しい --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 機械装置（diff machinery）の多くをバイパスする独自のカスタム出力パスを使用してきました。その結果、コンテンツ変更による検索用の -S および -G「ピックエックス（pickaxe）」オプションを含む、いくつかの有用なオプションと互換性がありませんでした。 今回のリリースでは、git log -L の出力を標準的な差分パイプライン（diff pipeline）にルーティングするように再構築され、初めてパッチフォーマットオプションやピックエックス検索と互換性を持つようになりました。 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 ”’, but that’s kind of a mouthful. Git 2.54 では、git rebase に新しい --trailer オプションが追加され、interpret-trailers 機構（machinery）を介してすべての再生済みコミットにトレーラーが追加されるようになりました。上記の複雑なコマンドの代わりに、`git rebase --trailer "Reviewed-by: A "` と記述するだけで同じ効果を得られます。 [source] コミットの署名において、GPG キーが期限切れになった場合でも、そのキーで署名された署名は有効なままです。以前は Git はこれらの署名を恐ろしい赤色で表示しており、誤解を招き、署名自体が無効であると解釈させる原因となっていました。Git は現在、期限切れのキーで作成された有効な署名を正しく「良好な（good）」署名として扱います。 [source] git blame に新しい --diff-algorithm オプションが追加され、blame の計算時に使用される差分アルゴリズム（例：ヒストグラム、patience、minimal）を選択できるようになりました。これにより、リポジトリの履歴における変更の性質によっては、意味のある違い（およびより有用な）blame 出力が生成される場合があります。 [source] 裏側では、Gitのオブジェクトデータベース（Object Database、ODB）内部のリストラクチャリングに多大な作業が費やされました。ODBのソースAPIはプラグイン可能なバックエンド設計（pluggable backend design）を採用するようにリファクタリングされ、read_object()、write_object()、for_each_object() といった個々の関数は、ソースごとに機能ポインタ（function pointers）を通じて呼び出されるようになりました。これらは現時点ではユーザーから見える変更ではありませんが、代替ストレージバックエンドやより柔軟なオブジェクトデータベース構成といった将来の機能のための基盤を築くものです。 [source, source, source, source] 部分的なクローン（partial clone）において不足しているblobをダウンロードするための実験的コマンドである `git backfill` が、リビジョン（revision）およびパススペック（pathspec）引数を受け付けるようになりました。以前は、バックフィルはツリー全体からHEADに到達可能なblobを常にダウンロードしていました。現在は、特定の履歴範囲（例：`git backfill main~100..main`）またはパスのサブセット（例：`git backfill -- '*.c'`）、ワイルドカードを含むパススペックにスコープを限定して実行できるようになりました。 これにより、リポジトリの特定の領域のみで履歴用blobが必要となる大規模な部分的なクローンにおいて、バックフィルの实用性が大幅に向上しました。 [source] 歴史的に、Gitのエイリアス設定（alias configuration）はASCII英数字とハイフンのみに制限されていました。つまり、“hämta”（スウェーデン語で“fetch”）や“状態”（日本語で“status”）といったエイリアス名は使用できませんでした。Git 2.54では、新しいサブセクションベースの構文によりこの制限が撤廃されました： [alias "hämta"] command = fetch 従来の `[alias] co = checkout` 構文は、ASCII名に対して引き続き動作します。新しいサブセクション形式は改行とNULLバイトを除くあらゆる文字をサポートし、生バイトとして大文字小文字を区別してマッチングされ、エイリアス定義には `command` キーを使用します。シェル補完（Shell completion）もこれらのエイリアスを処理するように更新されました。 [source, source] ヒストグラム差分アルゴリズム（histogram diff algorithm）に、出力品質に関する微妙な問題の修正が適用されました。任意の差分アルゴリズムの実行後、Gitは「コンパクション（compaction）」フェーズを実行し、変更グループをシフトおよびマージしてよりクリーンな出力を生成します。場合によっては、このシフトによって変更グループがヒストグラムアルゴリズムが選択したアンカーライン（anchor lines）をまたいで移動し、技術的には正しいが視覚的に冗長な差分が生じる可能性があります。Gitは現在このようなケースを検出し、影響を受けた領域を再差分処理することで、期待される結果により一致するコンパクトな出力を生成します。 [source] …残りの氷山 これらは最新リリースの変更の一部に過ぎません。詳細は、Gitリポジトリにある2.53および2.54のリリースノート、またはそれ以前のバージョンのものを参照してください。 「Highlights from Git 2.54」の記事は、最初にThe GitHub Blogで公開されました。

Git 2.54リリースのハイライト

背景や根拠まで確認しますか？

このニュースを、実務の判断につなげる

関連記事

調べる

選ぶ

サイト