[{"data":1,"prerenderedAt":754},["ShallowReactive",2],{"/ja-jp/blog/whats-new-in-git-2-49-0":3,"navigation-ja-jp":37,"banner-ja-jp":436,"footer-ja-jp":446,"blog-post-authors-ja-jp-Toon Claes":652,"blog-related-posts-ja-jp-whats-new-in-git-2-49-0":666,"assessment-promotions-ja-jp":705,"next-steps-ja-jp":745},{"id":4,"title":5,"authorSlugs":6,"body":8,"categorySlug":9,"config":10,"content":14,"description":8,"extension":26,"isFeatured":12,"meta":27,"navigation":12,"path":28,"publishedDate":20,"seo":29,"stem":34,"tagSlugs":35,"__hash__":36},"blogPosts/ja-jp/blog/whats-new-in-git-2-49-0.yml","Whats New In Git 2 49 0",[7],"toon-claes",null,"open-source",{"slug":11,"featured":12,"template":13},"whats-new-in-git-2-49-0",true,"BlogPost",{"title":15,"description":16,"authors":17,"heroImage":19,"date":20,"body":21,"category":9,"tags":22},"Git 2.49.0の新機能","このリリースでは、zlib-ngによるパフォーマンス向上、新しい名前ハッシュアルゴリズム、そして新しいコマンドgit-backfill(1)の導入などが行われています。",[18],"Toon Claes","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663087/Blog/Hero%20Images/git3-cover.png","2025-03-14","Gitプロジェクトは最近、[Git 2.49.0](https://lore.kernel.org/git/xmqqfrjfilc8.fsf@gitster.g/)をリリースしました。このリリースには、GitLabのGitチームや、より広範なGitコミュニティからのコントリビュートが含まれます。注目すべきハイライトを見てみましょう。\n\nこの記事では以下の変更点についてご紹介します。\n- [git-backfill(1)と新しいpath-walk API](#git-backfill(1)-and-the-new-path-walk-api)\n- [zlib-ngの導入](#introduction-of-zlib-ng)\n- [Mesonの継続的なイテレーション](#continued-iteration-on-meson)\n- [.git/branches/および.git/remotes/の非推奨化](#deprecation-of-.gitbranches%2F-and-.git%2Fremotes%2F)\n- [libgitに対するRustバインディング](#rust-bindings-for-libgit)\n- [新しい名前ハッシュアルゴリズム](#new-name-hashing-algorithm)\n- [プロミサーリモート機能](#promisor-remote-capability)\n- [`--revision`を使用した軽量なクローン](#thin-clone-using---revision)\n\n## git-backfill(1)と新しいpath-walk API\n\n[`git-clone(1)`](https://git-scm.com/docs/git-clone)コマンドでGitリポジトリをクローンする際に、\n[`--filter`](https://git-scm.com/docs/git-clone#Documentation/git-clone.txt-code--filterltfilter-specgtcode)オプションを指定することができます。\nこのオプションを使用すると、部分クローンを作成できます。部分クローンでは、指定されたオブジェクトフィルターに従って、サーバーから到達可能なオブジェクトの一部のみが送信されます。\n例えば、`--filter=blob:none`を指定してクローンを作成すると、サーバーからblob（ファイルの中身）が一切フェッチされず、_ブロブを含まないクローン_が作成されます。\n\nブロブを含まないクローンには、すべての到達可能なコミットとツリーは含まれますが、blobは含まれていません。そのため、[`git-checkout(1)`](https://git-scm.com/docs/git-checkout)のような操作を行うと、\nGitは必要なblobをサーバーからダウンロードして、その操作を完了させます。ただし、[`git-blame(1)`](https://git-scm.com/docs/git-blame)のような一部の操作では、\n必要なオブジェクトが1つずつダウンロードされることになり、この処理が非常に遅くなります。\nこれは、`git-blame(1)`がコミット履歴をたどって必要なblobを特定し、\n不足している各blobを個別にサーバーへリクエストする必要があるためです。\n\nGit 2.49では、新たに`git-backfill(1)`というサブコマンドが導入されました。これは、ブロブを含まない部分クローンに対して、不足しているblobをダウンロードするために使用できます。\n\n内部的には、`git-backfill(1)`は新しいパスウォークAPIを利用しています。これはGitが通常行うコミットのイテレーション処理とは異なります。従来の方法では、コミットを1つずつイテレーションし、それぞれに関連するツリーやblobに再帰的にアクセスしていました。一方、パスウォークAPIはパスごとに処理を行います。各パスについて関連するツリーオブジェクトのリストをスタックに追加し、そのスタックを深さ優先で処理します。つまり、コミット`1`のすべてのオブジェクトを処理してからコミット`2`へ進むのではなく、ファイル`A`のすべてのバージョンを全コミットにわたって処理してからファイル`B`に進む、という方式です。このアプローチは、パスごとにグループ化して処理する必要がある場合に、大幅なパフォーマンス向上をもたらします。\n\n[`gitlab-org/git`](https://gitlab.com/gitlab-org/git)リポジトリのブロブを含まないクローンを作成し、その使い方をお見せします。\n\n```shell\n$ git clone --filter=blob:none --bare --no-tags git@gitlab.com:gitlab-org/git.git\nCloning into bare repository 'git.git'...\nremote: Enumerating objects: 245904, done.\nremote: Counting objects: 100% (1736/1736), done.\nremote: Compressing objects: 100% (276/276), done.\nremote: Total 245904 (delta 1591), reused 1547 (delta 1459), pack-reused 244168 (from 1)\nReceiving objects: 100% (245904/245904), 59.35 MiB | 15.96 MiB/s, done.\nResolving deltas: 100% (161482/161482), done.\n```\n\n上の例では、Gitが初期ブランチをチェックアウトするためにblobをダウンロードする必要がないよう、`--bare`オプションを使用しています。このクローンにblobが含まれていないことは、次のコマンドで確認できます。\n\n```sh\n$ git cat-file --batch-all-objects --batch-check='%(objecttype)' | sort | uniq -c\n  83977 commit\n 161927 tree\n```\n\nもしこのリポジトリ内のファイル内容を確認したい場合、Gitはそのファイルをダウンロードする必要があります。\n\n```sh\n$ git cat-file -p HEAD:README.md\nremote: Enumerating objects: 1, done.\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 1 (from 1)\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\n\n[![Build status](https://github.com/git/git/workflows/CI/badge.svg)](https://github.com/git/git/actions?query=branch%3Amaster+event%3Apush)\n\nGit - fast, scalable, distributed revision control system\n=========================================================\n\nGit is a fast, scalable, distributed revision control system with an\nunusually rich command set that provides both high-level operations\nand full access to internals.\n\n[中略]\n```\n\nご覧のとおり、Gitはまずリモートリポジトリにアクセスし、blobをダウンロードしてから内容を表示しています。\n\nこのファイルに対して`git-blame(1)`を実行したい場合は、さらに多くのデータをダウンロードする必要があります。\n\n```sh\n$ git blame HEAD README.md\nremote: Enumerating objects: 1, done.\nremote: Counting objects: 100% (1/1), done.\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\nremote: Enumerating objects: 1, done.\nremote: Counting objects: 100% (1/1), done.\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\nremote: Enumerating objects: 1, done.\nremote: Counting objects: 100% (1/1), done.\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\nremote: Enumerating objects: 1, done.\n\n[中略]\n\ndf7375d772 README.md (Ævar Arnfjörð Bjarmason 2021-11-23 17:29:09 +0100  1) [![Build status](https://github.com/git/git/workflows/CI/badge.svg)](https://github.com/git/git/actions?query=branch%3Amaster+event%3Apush)\n5f7864663b README.md (Johannes Schindelin \t2019-01-29 06:19:32 -0800  2)\n28513c4f56 README.md (Matthieu Moy        \t2016-02-25 09:37:29 +0100  3) Git - fast, scalable, distributed revision control system\n28513c4f56 README.md (Matthieu Moy        \t2016-02-25 09:37:29 +0100  4) =========================================================\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  5)\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  6) Git is a fast, scalable, distributed revision control system with an\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  7) unusually rich command set that provides both high-level operations\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  8) and full access to internals.\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  9)\n\n[中略]\n```\n\n出力は省略していますが、ご覧のように、Gitはそのファイルの各リビジョンについて個別にサーバーへアクセスしています。これはとても非効率的です。そこで`git-backfill(1)`を使えば、Gitに対してすべてのblobを一括でダウンロードするよう指示できます。\n\n```shell\n$ git backfill\nremote: Enumerating objects: 50711, done.\nremote: Counting objects: 100% (15438/15438), done.\nremote: Compressing objects: 100% (708/708), done.\nremote: Total 50711 (delta 15154), reused 14730 (delta 14730), pack-reused 35273 (from 1)\nReceiving objects: 100% (50711/50711), 11.62 MiB | 12.28 MiB/s, done.\nResolving deltas: 100% (49154/49154), done.\nremote: Enumerating objects: 50017, done.\nremote: Counting objects: 100% (10826/10826), done.\nremote: Compressing objects: 100% (634/634), done.\nremote: Total 50017 (delta 10580), reused 10192 (delta 10192), pack-reused 39191 (from 1)\nReceiving objects: 100% (50017/50017), 12.17 MiB | 12.33 MiB/s, done.\nResolving deltas: 100% (48301/48301), done.\nremote: Enumerating objects: 47303, done.\nremote: Counting objects: 100% (7311/7311), done.\nremote: Compressing objects: 100% (618/618), done.\nremote: Total 47303 (delta 7021), reused 6693 (delta 6693), pack-reused 39992 (from 1)\nReceiving objects: 100% (47303/47303), 40.84 MiB | 15.26 MiB/s, done.\nResolving deltas: 100% (43788/43788), done.\n```\n\nこれにより、すべてのblobが補完され、ブロブを含まないクローンが完全なクローンになります。\n\n```shell\n$ git cat-file --batch-all-objects --batch-check='%(objecttype)' | sort | uniq -c\n 148031 blob\n  83977 commit\n 161927 tree\n```\n\nこの[プロジェクト](https://lore.kernel.org/git/pull.1820.v3.git.1738602667.gitgitgadget@gmail.com/)は[Derrick Stolee](https://stolee.dev/)によって主導され、[e565f37553](https://gitlab.com/gitlab-org/git/-/commit/e565f3755342caf1d21e22359eaf09ec11d8c0ae)でマージされました。\n\n## zlib-ngの導入\n\n`.git/`フォルダ内のすべてのオブジェクトは、Gitによって[`zlib`](https://zlib.net/)を使って圧縮されています。`zlib`は[RFC\n1950](https://datatracker.ietf.org/doc/html/rfc1950)（ZLIB圧縮データフォーマット）のリファレンス実装であり、1995年に作られました。`zlib`は長い歴史を持ち、非常に高い移植性があり、\nインターネット以前の多くのシステムもサポートしています。このように幅広いアーキテクチャやコンパイラをサポートしている一方で、\nzlibには機能面での制限もあります。\n\nその制限に対応するために生まれたのが[`zlib-ng`](https://github.com/zlib-ng/zlib-ng)というフォークです。\n`zlib-ng`は、現代的なシステム向けに最適化されることを目指しており、レガシーシステムのサポートを廃止する代わりに、\nIntel向けの最適化パッチや、Cloudflareによる最適化、その他いくつかの小規模なパッチが取り込まれています。\n\n`zlib-ng`ライブラリ自体は`zlib`との互換レイヤーを提供しており、この互換性により、`zlib-ng`を`zlib`の代替としてそのまま差し替えて使うことが可能です。\nただし、この互換レイヤーはすべてのLinuxディストリビューションで利用できるわけではありません。Git 2.49では以下の変更が加えられました。\n\n- Gitプロジェクトへのzlib-ng互換レイヤーの追加\n- [`Makefile`](https://gitlab.com/gitlab-org/git/-/blob/b9d6f64393275b505937a8621a6cc4875adde8e0/Makefile#L186-187)および[Mesonビルドファイル](https://gitlab.com/gitlab-org/git/-/blob/b9d6f64393275b505937a8621a6cc4875adde8e0/meson.build#L795-811)へのビルドオプションの追加\n\nこれらの追加により、`zlib-ng`によるパフォーマンス向上の恩恵を受けやすくなりました。\n\nローカルでのベンチマークでは、`zlib`ではなく`zlib-ng`を使用することで約25%の高速化が確認されています。現在、これらの変更をGitLab.comにも順次導入中です。\n\n`zlib-ng`によるパフォーマンス向上の恩恵を受けたい場合は、まず`git version --build-options`コマンドを実行して、お使いのマシンでGitがすでに`zlib-ng`を使用しているかどうかを確認してください。\n\n```shell\n$ git version --build-options\ngit version 2.47.1\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nlibcurl: 8.6.0\nOpenSSL: OpenSSL 3.2.2 4 Jun 2024\nzlib: 1.3.1.zlib-ng\n```\n\n出力の一番下の行に`zlib-ng`と表示されていれば、すでにGitは高速な`zlib`のバリアントでビルドされています。表示されていない場合は、以下のいずれかの方法で対応できます。\n\n- お使いのGitパッケージのメンテナーに、`zlib-ng`のサポートを有効にしてもらうよう依頼する\n- Gitをソースコードから自分でビルドする\n\nなお、これらの[変更](https://gitlab.com/gitlab-org/git/-/commit/9d0e81e2ae3bd7f6d8a655be53c2396d7af3d2b0)\nは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)によって[導入](https://lore.kernel.org/git/20250128-b4-pks-compat-drop-uncompress2-v4-0-129bc36ae8f5@pks.im/)されました。\n\n## Mesonの継続的なイテレーション\n\nGit 2.48のリリースについて紹介した記事では、[Mesonビルドシステムの導入](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-48-0/#meson%E3%83%93%E3%83%AB%E3%83%89%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0)について触れました。[Meson](https://ja.wikipedia.org/wiki/Meson_(%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2))は、Gitプロジェクトで使用されるビルド自動化ツールで、将来的には[Autoconf](https://ja.wikipedia.org/wiki/Autoconf),\n[CMake](https://ja.wikipedia.org/wiki/CMake)さらには\n[Make](https://ja.wikipedia.org/wiki/Make_(UNIX))に取って代わる可能性もあります。\n\n今回のリリースサイクルでも、Mesonの利用に関する作業が引き続き進められ、不足していた機能の追加や安定性向上のための以下の修正が行われました。\n\n  - [CIのテストカバレッジ改善](https://lore.kernel.org/git/20250122-b4-pks-meson-additions-v3-0-5a51eb5d3dcd@pks.im/)が、コミット[72f1ddfbc9](https://gitlab.com/gitlab-org/git/-/commit/72f1ddfbc95b47c6011bb423e6947418d1d72709)でマージされました\n- [`contrib/`ディレクトリでMesonを使えるようにする作業の一部](https://lore.kernel.org/git/20250219-b4-pks-meson-contrib-v2-0-1ba5d7fde0b9@pks.im/)が、コミット[2a1530a953](https://gitlab.com/gitlab-org/git/-/commit/2a1530a953cc4d2ae62416db86c545c7ccb73ace)でマージされました\n  - [Mesonベースのビルド手順に関する修正や改善](https://lore.kernel.org/git/20250226-b4-pks-meson-improvements-v3-0-60c77cf673ae@pks.im/)が、コミット[ab09eddf60](https://gitlab.com/gitlab-org/git/-/commit/ab09eddf601501290b5c719574fbe6c02314631f)でマージされました\n  - [git-subtree(1)のビルドにMesonを対応させる変更](https://lore.kernel.org/git/20250117-b4-pks-build-subtree-v1-0-03c2ed6cc42e@pks.im/)が、コミット[3ddeb7f337](https://gitlab.com/gitlab-org/git/-/commit/3ddeb7f3373ae0e309d9df62ada24375afa456c7)でマージされました\n  - [MesonにHTMLドキュメントページの生成を学習させる変更](https://lore.kernel.org/git/20241227-b4-pks-meson-docs-v2-0-f61e63edbfa1@pks.im/)が、コミット[1b4e9a5f8b](https://gitlab.com/gitlab-org/git/-/commit/1b4e9a5f8b5f048972c21fe8acafe0404096f694)でマージされました\n\nこれらの作業はすべて[Patrick Steinhardt](https://gitlab.com/pks-gitlab)によって行われました。\n\n## .git/branches/および.git/remotes/の非推奨化\n\nおそらく、 `.git`ディレクトリやその中身についてはご存じかと思います。\nしかし、 `.git/branches/`や`.git/remotes/`というサブディレクトリの存在についてはどうでしょうか？\nご存じの通り、ブランチへの参照は`.git/refs/heads/`に保存されているため、`.git/branches/`はそのための場所ではありません。そして、`.git/remotes/`の用途は何でしょうか？\n\n2005年、[`.git/branches/`](https://git-scm.com/docs/git-fetch#_named_file_in_git_dirbranches)はリモートの短縮名を保存するために導入されました。そしてその数か月後に、それらは[`.git/remotes/`](https://git-scm.com/docs/git-fetch#_named_file_in_git_dirremotes)に移動されました。\n[2006年](https://lore.kernel.org/git/Pine.LNX.4.63.0604301520460.2646@wbgn013.biozentrum.uni-wuerzburg.de/)には、[`git-config(1)`](https://git-scm.com/docs/git-config)に[リモート](https://git-scm.com/docs/git-config#Documentation/git-config.txt-remoteltnamegturl)設定を保存する機能が追加され、\nこれがリモートを設定する標準的な方法として定着しました。\nその後2011年には、`.git/branches/`と`.git/remotes/`は「レガシー」であることが[文書化](https://gitlab.com/git-scm/git/-/commit/3d3d282146e13f2d7f055ad056956fd8e5d7ed29#e615263aaf131d42be8b0d0888ebd3fec954c6c9_132_124)され、現代のリポジトリでは使用されなくなりました。\n\nそして2024年、Gitの次のメジャーバージョン（v3.0）の破壊的な変更の概要をまとめるドキュメント[破壊的な変更](https://git-scm.com/docs/BreakingChanges)が作成されました。\nこのリリースはすぐに行われる予定はありませんが、このドキュメントにはそのリリースに含まれると予想される変更点について記載されています。\nコミット[8ccc75c245](https://gitlab.com/git-scm/git/-/commit/8ccc75c2452b5814d2445d60d54266293ca48674)では、`.git/branches/`および`.git/remotes/`ディレクトリの使用に関する内容がこのドキュメントに追加され、これにより公式に非推奨とされ、Git 3.0で削除予定であることが明示されました。\n\n[この非推奨化を正式に文書化](https://lore.kernel.org/git/20250122-pks-remote-branches-deprecation-v4-5-5cbf5b28afd5@pks.im/)した[Patrick Steinhardt](https://gitlab.com/pks-gitlab)に感謝します。\n\n## libgitに対するRustバインディング\n\nGitをコンパイルすると、内部ライブラリ`libgit.a`が生成されます。このライブラリには、Gitの中核となる機能の一部が含まれています。\n\nこのライブラリ（およびGitの大部分）はC言語で書かれていますが、Git 2.49では一部の関数をRustから使えるようにするためのバインディングが追加されました。この実現のために、2つの新しいCargoパッケージ、`libgit-sys`と`libgit-rs`が作成されました。これらのパッケージは、GitのSourceTree内の[`contrib/`](https://gitlab.com/gitlab-org/git/-/tree/master/contrib)サブディレクトリに配置されています。\n\n[他言語関数インターフェイス](https://ja.wikipedia.org/wiki/Foreign_function_interface)を使う場合、ライブラリを2つのパッケージに分けるのは[一般的](https://doc.rust-lang.org/cargo/reference/build-scripts.html#-sys-packages)な手法です。\n`libgit-sys`パッケージは、C関数への純粋なインターフェースを提供し、ネイティブの`libgit.a`にリンクします。一方、`libgit-rs`パッケージは、`libgit-sys`の関数をRustらしいスタイルで扱える高レベルなインターフェースを提供します。\n\n現時点では、これらのRustパッケージで使える機能は非常に限定的で、対応しているのは`git-config(1)`とやり取りするためのインターフェースのみです。\n\nこの取り組みは[Josh Steadmon](https://lore.kernel.org/git/8793ff64a7f6c4c04dd03b71162a85849feda944.1738187176.git.steadmon@google.com/)さんによって主導され、コミット[a4af0b6288](https://gitlab.com/gitlab-org/git/-/commit/a4af0b6288e25eb327ae9018cee09def9e43f1cd)でマージされました。\n\n## 新しい名前ハッシュアルゴリズム\n\n`.git/`にあるGitのオブジェクトデータベースは、その大部分のデータを パックファイルに保存しています。また、このパックファイルは、Gitのサーバーとクライアント間でオブジェクトをやり取りする際にも使われます。\n\nパックファイルのフォーマットについては、[`gitformat-pack(5)`](https://git-scm.com/docs/gitformat-pack)に詳しく書かれていますが、その中でも重要なのが差分圧縮です。差分圧縮では、すべてのオブジェクトがそのまま保存されるわけではなく、一部のオブジェクトは他のオブジェクトとの_差分_として保存されます。つまり、オブジェクトの内容全体を保存するのではなく、他のオブジェクトと比較した変更点だけを記録します。\n\n差分の計算や保存方法についてはここでは詳しく触れませんが、\n非常に似ているファイルをグループ化しておくことが重要なのは想像できるかと思います。Git v2.48以前では、Gitは「ファイルパスの最後の16文字」をもとに、blobが似ているかどうかを判断していました。このアルゴリズムはバージョン`1`と呼ばれています。\n\nGit 2.49では、バージョン`2`のアルゴリズムが追加されました。これはバージョン`1`のイテレーションで、親ディレクトリの影響を減らすように調整されたバージョンです。どちらのアルゴリズムを使用するかは、[`git-repack(1)`](https://git-scm.com/docs/git-repack)の`--name-hash-version`オプションで指定できます。\n\n以下は、このプロジェクトを推進した[Derrick Stolee](https://stolee.dev/)さんによる、`git repack -adf --name-hash-version=\u003Cn>`を実行した際のパックファイルサイズの比較です。\n\n| リポジトリ                                          \t| バージョン1のサイズ   | バージョン2のサイズ |\n|---------------------------------------------------|-----------|---------|\n| [fluentui](https://github.com/microsoft/fluentui) | 440 MB \t| 161 MB   |\n| Repo B                                        \t| 6,248 MB   | 856 MB   |\n| Repo C                                        \t| 37,278 MB  | 6,921 MB |\n| Repo D                                        \t| 131,204 MB | 7,463 MB |\n\nこの件に関する詳細は、コミット[aae91a86fb](https://gitlab.com/gitlab-org/git/-/commit/aae91a86fb2a71ff89a71b63ccec3a947b26ca51)にマージされた[パッチセット](https://lore.kernel.org/git/pull.1823.v4.git.1738004554.gitgitgadget@gmail.com/)にて確認できます。\n\n## プロミサーリモート機能\n\nGitが大きなファイルを扱うのに向いていないことは、よく知られています。この問題に対する解決策として、[Git LFS](https://git-lfs.com/)のようなツールがありますが、依然として以下のような欠点が残っています。\n\n- Git LFSでは、どのファイルをLFSに入れるかをユーザーが自分で設定する必要があり、サーバー側ではそれについて制御できず、すべてのファイルを提供する必要があります。\n- リポジトリにファイルがコミットされると、履歴を書き換えない限り、それを取り除く方法がありません。これは特に大きなファイルでは厄介で、一度入れると永遠に残ってしまいます。\n- ユーザーは、Git LFSに入れるファイルを後から変更することはできません。\n- Git LFS のようなツールは、導入・学習・運用すべてにそれなりの労力が必要です。\n\n以前からGitにはプロミサーリモートという概念が存在しており、この機能を大きなファイルに対処するための手段として利用できます。そしてGit 2.49では、この機能がさらに一歩前進しました。\n\n新しい「プロミサーリモート」機能の考え方は比較的シンプルです。Gitサーバーがすべてのオブジェクトを自ら送信する代わりに、「これらのオブジェクトは_XYZ_からダウンロードしてね」とGitクライアントに伝えます。この_XYZ_がプロミサーリモートです。\n\nGit 2.49では、サーバーがプロミサーリモートの情報をクライアントに通知できるようになりました。この変更は、[`gitprotocol-v2`](https://git-scm.com/docs/gitprotocol-v2)の拡張として行われています。サーバーとクライアントがデータを送受信している間に、サーバーは自分が知っているプロミサーリモートの名前やURLをクライアントに送信します。\n\n現時点では、Gitクライアントはクローン時にサーバーから受け取ったプロミサーリモートの情報をまだ利用していません。つまり、今のところは、クローン元のリモートからすべてのオブジェクトを取得しています。しかし今後は、サーバーから受け取ったプロミサーリモート情報を活用できるように開発を進め、より簡単に使える仕組みにしていく予定です。\n\nこの[パッチセット](https://lore.kernel.org/git/20250218113204.2847463-1-christian.couder@gmail.com/)は[Christian Couder](https://gitlab.com/chriscool)さんによって提出され、コミット[2c6fd30198](https://gitlab.com/gitlab-org/git/-/commit/2c6fd30198187c928cbf927802556908c381799c)でマージされました。\n\n## `--revision`を使用した軽量なクローン\n\n[`git-clone(1)`](https://git-scm.com/docs/git-clone)に新しく`--revision`オプションが追加されました。このオプションを使うことで、指定されたリビジョンの履歴のみを含む、軽量なクローンを作成できます。このオプションは`--branch`に似ていますが、`refs/heads/main`、`refs/tags/v1.0`、`refs/merge-requests/123`のような リファレンス名や、16進数のコミットオブジェクトIDを受け取る点が異なります。`--branch`との違いは、このオプションでは追跡ブランチが作られず、`HEAD`がデタッチ状態になる点です。そのため、このクローンを使ってブランチにコントリビュートするといった用途には向いていません。\n\n`--revision`と`--depth`を組み合わせて使うことで、非常にミニマルなクローンを作成できます。おすすめの用途は、自動テストです。たとえば、CIシステムが特定のブランチ（またはリファレンス）をチェックアウトして、ソースコードのテストを行うだけでいい場合、この最小限のクローンで十分です。\n\nこの[変更](https://gitlab.com/gitlab-org/git/-/commit/5785d9143bcb3ef19452a83bc2e870ff3d5ed95a)は[Toon Claes](https://gitlab.com/toon)さんによって[推進](https://lore.kernel.org/git/20250206-toon-clone-refs-v7-0-4622b7392202@iotcl.com/)されました。\n\n# もっと詳しく\n- [Git 2.48.0の新機能](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-48-0/)\n- [Git 2.47.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-47-0/)\n- [Git 2.46.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-46-0/)",[23,24,25],"community","open source","git","yml",{},"/ja-jp/blog/whats-new-in-git-2-49-0",{"title":15,"description":16,"ogTitle":15,"ogDescription":16,"noIndex":30,"ogImage":19,"ogUrl":31,"ogSiteName":32,"ogType":33,"canonicalUrls":31},false,"https://about.gitlab.com/blog/whats-new-in-git-2-49-0","https://about.gitlab.com","article","ja-jp/blog/whats-new-in-git-2-49-0",[23,9,25],"JpLodzWoX-BmOIq6TZ1H-gcktvTZPeEPk4azSSzrHyQ",{"data":38},{"logo":39,"freeTrial":44,"sales":49,"login":54,"items":59,"search":366,"minimal":399,"duo":416,"pricingDeployment":426},{"config":40},{"href":41,"dataGaName":42,"dataGaLocation":43},"/ja-jp/","gitlab logo","header",{"text":45,"config":46},"無料トライアルを開始",{"href":47,"dataGaName":48,"dataGaLocation":43},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":50,"config":51},"お問い合わせ",{"href":52,"dataGaName":53,"dataGaLocation":43},"/ja-jp/sales/","sales",{"text":55,"config":56},"サインイン",{"href":57,"dataGaName":58,"dataGaLocation":43},"https://gitlab.com/users/sign_in/","sign in",[60,87,183,188,288,348],{"text":61,"config":62,"cards":64},"プラットフォーム",{"dataNavLevelOne":63},"platform",[65,71,79],{"title":61,"description":66,"link":67},"DevSecOpsに特化したインテリジェントオーケストレーションプラットフォーム",{"text":68,"config":69},"プラットフォームを詳しく見る",{"href":70,"dataGaName":63,"dataGaLocation":43},"/ja-jp/platform/",{"title":72,"description":73,"link":74},"GitLab Duo Agent Platform","ソフトウェアライフサイクル全体を支えるエージェント型AI",{"text":75,"config":76},"GitLab Duoのご紹介",{"href":77,"dataGaName":78,"dataGaLocation":43},"/ja-jp/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":80,"description":81,"link":82},"GitLabが選ばれる理由","エンタープライズがGitLabを選ぶ主な理由をご覧ください",{"text":83,"config":84},"詳細はこちら",{"href":85,"dataGaName":86,"dataGaLocation":43},"/ja-jp/why-gitlab/","why gitlab",{"text":88,"left":12,"config":89,"link":91,"lists":95,"footer":165},"製品",{"dataNavLevelOne":90},"solutions",{"text":92,"config":93},"すべてのソリューションを表示",{"href":94,"dataGaName":90,"dataGaLocation":43},"/ja-jp/solutions/",[96,121,143],{"title":97,"description":98,"link":99,"items":104},"自動化","CI/CDと自動化でデプロイを加速",{"config":100},{"icon":101,"href":102,"dataGaName":103,"dataGaLocation":43},"AutomatedCodeAlt","/ja-jp/solutions/delivery-automation/","automated software delivery",[105,109,112,117],{"text":106,"config":107},"CI/CD",{"href":108,"dataGaLocation":43,"dataGaName":106},"/ja-jp/solutions/continuous-integration/",{"text":72,"config":110},{"href":77,"dataGaLocation":43,"dataGaName":111},"gitlab duo agent platform - product menu",{"text":113,"config":114},"ソースコード管理",{"href":115,"dataGaLocation":43,"dataGaName":116},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":118,"config":119},"自動化されたソフトウェアデリバリー",{"href":102,"dataGaLocation":43,"dataGaName":120},"Automated software delivery",{"title":122,"description":123,"link":124,"items":129},"セキュリティ","セキュリティを犠牲にすることなくコード作成を高速化",{"config":125},{"href":126,"dataGaName":127,"dataGaLocation":43,"icon":128},"/ja-jp/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[130,134,139],{"text":131,"config":132},"Application Security Testing",{"href":126,"dataGaName":133,"dataGaLocation":43},"Application security testing",{"text":135,"config":136},"ソフトウェアサプライチェーンの安全性",{"href":137,"dataGaLocation":43,"dataGaName":138},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":140,"config":141},"Software Compliance",{"href":142,"dataGaName":140,"dataGaLocation":43},"/ja-jp/solutions/software-compliance/",{"title":144,"link":145,"items":150},"測定",{"config":146},{"icon":147,"href":148,"dataGaName":149,"dataGaLocation":43},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[151,155,160],{"text":152,"config":153},"可視性と測定",{"href":148,"dataGaLocation":43,"dataGaName":154},"Visibility and Measurement",{"text":156,"config":157},"バリューストリーム管理",{"href":158,"dataGaLocation":43,"dataGaName":159},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":161,"config":162},"分析とインサイト",{"href":163,"dataGaLocation":43,"dataGaName":164},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":166,"items":167},"GitLabが活躍する場所",[168,173,178],{"text":169,"config":170},"Enterprise",{"href":171,"dataGaLocation":43,"dataGaName":172},"/ja-jp/enterprise/","enterprise",{"text":174,"config":175},"スモールビジネス",{"href":176,"dataGaLocation":43,"dataGaName":177},"/ja-jp/small-business/","small business",{"text":179,"config":180},"公共機関",{"href":181,"dataGaLocation":43,"dataGaName":182},"/ja-jp/solutions/public-sector/","public sector",{"text":184,"config":185},"価格",{"href":186,"dataGaName":187,"dataGaLocation":43,"dataNavLevelOne":187},"/ja-jp/pricing/","pricing",{"text":189,"config":190,"link":192,"lists":196,"feature":275},"関連リソース",{"dataNavLevelOne":191},"resources",{"text":193,"config":194},"すべてのリソースを表示",{"href":195,"dataGaName":191,"dataGaLocation":43},"/ja-jp/resources/",[197,230,248],{"title":198,"items":199},"はじめに",[200,205,210,215,220,225],{"text":201,"config":202},"インストール",{"href":203,"dataGaName":204,"dataGaLocation":43},"/ja-jp/install/","install",{"text":206,"config":207},"クイックスタートガイド",{"href":208,"dataGaName":209,"dataGaLocation":43},"/ja-jp/get-started/","quick setup checklists",{"text":211,"config":212},"学ぶ",{"href":213,"dataGaLocation":43,"dataGaName":214},"https://university.gitlab.com/","learn",{"text":216,"config":217},"製品ドキュメント",{"href":218,"dataGaName":219,"dataGaLocation":43},"https://docs.gitlab.com/","product documentation",{"text":221,"config":222},"ベストプラクティスビデオ",{"href":223,"dataGaName":224,"dataGaLocation":43},"/ja-jp/getting-started-videos/","best practice videos",{"text":226,"config":227},"インテグレーション",{"href":228,"dataGaName":229,"dataGaLocation":43},"/ja-jp/integrations/","integrations",{"title":231,"items":232},"検索する",[233,238,243],{"text":234,"config":235},"お客様成功事例",{"href":236,"dataGaName":237,"dataGaLocation":43},"/ja-jp/customers/","customer success stories",{"text":239,"config":240},"ブログ",{"href":241,"dataGaName":242,"dataGaLocation":43},"/ja-jp/blog/","blog",{"text":244,"config":245},"リモート",{"href":246,"dataGaName":247,"dataGaLocation":43},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":249,"items":250},"つなげる",[251,256,260,265,270],{"text":252,"config":253},"GitLabサービス",{"href":254,"dataGaName":255,"dataGaLocation":43},"/ja-jp/services/","services",{"text":257,"config":258},"コミュニティ",{"href":259,"dataGaName":23,"dataGaLocation":43},"/community/",{"text":261,"config":262},"フォーラム",{"href":263,"dataGaName":264,"dataGaLocation":43},"https://forum.gitlab.com/","forum",{"text":266,"config":267},"イベント",{"href":268,"dataGaName":269,"dataGaLocation":43},"/events/","events",{"text":271,"config":272},"パートナー",{"href":273,"dataGaName":274,"dataGaLocation":43},"/ja-jp/partners/","partners",{"backgroundColor":276,"textColor":277,"text":278,"image":279,"link":283},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":280,"config":281},"ソースプロモカード",{"src":282},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":284,"config":285},"最新情報を読む",{"href":286,"dataGaName":287,"dataGaLocation":43},"/ja-jp/the-source/","the source",{"text":289,"config":290,"lists":292},"会社情報",{"dataNavLevelOne":291},"company",[293],{"items":294},[295,300,306,308,313,318,323,328,333,338,343],{"text":296,"config":297},"GitLabについて",{"href":298,"dataGaName":299,"dataGaLocation":43},"/ja-jp/company/","about",{"text":301,"config":302,"footerGa":305},"採用情報",{"href":303,"dataGaName":304,"dataGaLocation":43},"/jobs/","jobs",{"dataGaName":304},{"text":266,"config":307},{"href":268,"dataGaName":269,"dataGaLocation":43},{"text":309,"config":310},"経営陣",{"href":311,"dataGaName":312,"dataGaLocation":43},"/company/team/e-group/","leadership",{"text":314,"config":315},"チーム",{"href":316,"dataGaName":317,"dataGaLocation":43},"/company/team/","team",{"text":319,"config":320},"ハンドブック",{"href":321,"dataGaName":322,"dataGaLocation":43},"https://handbook.gitlab.com/","handbook",{"text":324,"config":325},"投資家向け情報",{"href":326,"dataGaName":327,"dataGaLocation":43},"https://ir.gitlab.com/","investor relations",{"text":329,"config":330},"トラストセンター",{"href":331,"dataGaName":332,"dataGaLocation":43},"/ja-jp/security/","trust center",{"text":334,"config":335},"AI Transparency Center",{"href":336,"dataGaName":337,"dataGaLocation":43},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":339,"config":340},"ニュースレター",{"href":341,"dataGaName":342,"dataGaLocation":43},"/company/contact/#contact-forms","newsletter",{"text":344,"config":345},"プレス",{"href":346,"dataGaName":347,"dataGaLocation":43},"/press/","press",{"text":50,"config":349,"lists":350},{"dataNavLevelOne":291},[351],{"items":352},[353,356,361],{"text":50,"config":354},{"href":52,"dataGaName":355,"dataGaLocation":43},"talk to sales",{"text":357,"config":358},"サポートポータル",{"href":359,"dataGaName":360,"dataGaLocation":43},"https://support.gitlab.com","support portal",{"text":362,"config":363},"カスタマーポータル",{"href":364,"dataGaName":365,"dataGaLocation":43},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":367,"login":368,"suggestions":375},"閉じる",{"text":369,"link":370},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":371,"config":372},"GitLab.com",{"href":57,"dataGaName":373,"dataGaLocation":374},"search login","search",{"text":376,"default":377},"提案",[378,380,385,387,391,395],{"text":72,"config":379},{"href":77,"dataGaName":72,"dataGaLocation":374},{"text":381,"config":382},"コード提案（AI）",{"href":383,"dataGaName":384,"dataGaLocation":374},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":106,"config":386},{"href":108,"dataGaName":106,"dataGaLocation":374},{"text":388,"config":389},"GitLab on AWS",{"href":390,"dataGaName":388,"dataGaLocation":374},"/ja-jp/partners/technology-partners/aws/",{"text":392,"config":393},"GitLab on Google Cloud",{"href":394,"dataGaName":392,"dataGaLocation":374},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":396,"config":397},"GitLabを選ぶ理由",{"href":85,"dataGaName":398,"dataGaLocation":374},"Why GitLab?",{"freeTrial":400,"mobileIcon":404,"desktopIcon":409,"secondaryButton":412},{"text":45,"config":401},{"href":402,"dataGaName":48,"dataGaLocation":403},"https://gitlab.com/-/trials/new/","nav",{"altText":405,"config":406},"GitLabアイコン",{"src":407,"dataGaName":408,"dataGaLocation":403},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":405,"config":410},{"src":411,"dataGaName":408,"dataGaLocation":403},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":198,"config":413},{"href":414,"dataGaName":415,"dataGaLocation":403},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/compare/gitlab-vs-github/","get started",{"freeTrial":417,"mobileIcon":422,"desktopIcon":424},{"text":418,"config":419},"GitLab Duoの詳細について",{"href":420,"dataGaName":421,"dataGaLocation":403},"/ja-jp/gitlab-duo/","gitlab duo",{"altText":405,"config":423},{"src":407,"dataGaName":408,"dataGaLocation":403},{"altText":405,"config":425},{"src":411,"dataGaName":408,"dataGaLocation":403},{"freeTrial":427,"mobileIcon":432,"desktopIcon":434},{"text":428,"config":429},"料金ページに戻る",{"href":186,"dataGaName":430,"dataGaLocation":403,"icon":431},"back to pricing","GoBack",{"altText":405,"config":433},{"src":407,"dataGaName":408,"dataGaLocation":403},{"altText":405,"config":435},{"src":411,"dataGaName":408,"dataGaLocation":403},{"title":437,"button":438,"config":443},"エージェント型AIがソフトウェア配信をどのように変革するかをご覧ください",{"text":439,"config":440},"GitLab Transcendを今すぐ視聴",{"href":441,"dataGaName":442,"dataGaLocation":43},"/ja-jp/events/transcend/virtual/","transcend event",{"layout":444,"icon":445},"release","AiStar",{"data":447},{"text":448,"source":449,"edit":455,"contribute":460,"config":465,"items":470,"minimal":644},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":450,"config":451},"ページのソースを表示",{"href":452,"dataGaName":453,"dataGaLocation":454},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":456,"config":457},"このページを編集",{"href":458,"dataGaName":459,"dataGaLocation":454},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":461,"config":462},"ご協力をお願いします",{"href":463,"dataGaName":464,"dataGaLocation":454},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":466,"facebook":467,"youtube":468,"linkedin":469},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[471,494,548,578,613],{"title":61,"links":472,"subMenu":477},[473],{"text":474,"config":475},"DevSecOpsプラットフォーム",{"href":70,"dataGaName":476,"dataGaLocation":454},"devsecops platform",[478],{"title":184,"links":479},[480,484,489],{"text":481,"config":482},"プランの表示",{"href":186,"dataGaName":483,"dataGaLocation":454},"view plans",{"text":485,"config":486},"Premiumを選ぶ理由",{"href":487,"dataGaName":488,"dataGaLocation":454},"/ja-jp/pricing/premium/","why premium",{"text":490,"config":491},"Ultimateを選ぶ理由",{"href":492,"dataGaName":493,"dataGaLocation":454},"/ja-jp/pricing/ultimate/","why ultimate",{"title":495,"links":496},"ソリューション",[497,502,505,507,512,517,521,524,527,532,534,536,538,543],{"text":498,"config":499},"デジタルトランスフォーメーション",{"href":500,"dataGaName":501,"dataGaLocation":454},"/ja-jp/topics/digital-transformation/","digital transformation",{"text":503,"config":504},"セキュリティとコンプライアンス",{"href":126,"dataGaName":133,"dataGaLocation":454},{"text":118,"config":506},{"href":102,"dataGaName":103,"dataGaLocation":454},{"text":508,"config":509},"アジャイル開発",{"href":510,"dataGaName":511,"dataGaLocation":454},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":513,"config":514},"クラウドトランスフォーメーション",{"href":515,"dataGaName":516,"dataGaLocation":454},"/ja-jp/topics/cloud-native/","cloud transformation",{"text":518,"config":519},"SCM",{"href":115,"dataGaName":520,"dataGaLocation":454},"source code management",{"text":106,"config":522},{"href":108,"dataGaName":523,"dataGaLocation":454},"continuous integration & delivery",{"text":156,"config":525},{"href":158,"dataGaName":526,"dataGaLocation":454},"value stream management",{"text":528,"config":529},"GitOps",{"href":530,"dataGaName":531,"dataGaLocation":454},"/ja-jp/solutions/gitops/","gitops",{"text":169,"config":533},{"href":171,"dataGaName":172,"dataGaLocation":454},{"text":174,"config":535},{"href":176,"dataGaName":177,"dataGaLocation":454},{"text":179,"config":537},{"href":181,"dataGaName":182,"dataGaLocation":454},{"text":539,"config":540},"教育",{"href":541,"dataGaName":542,"dataGaLocation":454},"/ja-jp/solutions/education/","education",{"text":544,"config":545},"金融サービス",{"href":546,"dataGaName":547,"dataGaLocation":454},"/ja-jp/solutions/finance/","financial services",{"title":189,"links":549},[550,552,554,556,559,561,564,566,568,570,572,574,576],{"text":201,"config":551},{"href":203,"dataGaName":204,"dataGaLocation":454},{"text":206,"config":553},{"href":208,"dataGaName":209,"dataGaLocation":454},{"text":211,"config":555},{"href":213,"dataGaName":214,"dataGaLocation":454},{"text":216,"config":557},{"href":218,"dataGaName":558,"dataGaLocation":454},"docs",{"text":239,"config":560},{"href":241,"dataGaName":242},{"text":562,"config":563},"お客様の成功事例",{"href":236,"dataGaLocation":454},{"text":234,"config":565},{"href":236,"dataGaName":237,"dataGaLocation":454},{"text":244,"config":567},{"href":246,"dataGaName":247,"dataGaLocation":454},{"text":252,"config":569},{"href":254,"dataGaName":255,"dataGaLocation":454},{"text":257,"config":571},{"href":259,"dataGaName":23,"dataGaLocation":454},{"text":261,"config":573},{"href":263,"dataGaName":264,"dataGaLocation":454},{"text":266,"config":575},{"href":268,"dataGaName":269,"dataGaLocation":454},{"text":271,"config":577},{"href":273,"dataGaName":274,"dataGaLocation":454},{"title":579,"links":580},"Company",[581,583,585,587,589,591,593,597,602,604,606,608],{"text":296,"config":582},{"href":298,"dataGaName":291,"dataGaLocation":454},{"text":301,"config":584},{"href":303,"dataGaName":304,"dataGaLocation":454},{"text":309,"config":586},{"href":311,"dataGaName":312,"dataGaLocation":454},{"text":314,"config":588},{"href":316,"dataGaName":317,"dataGaLocation":454},{"text":319,"config":590},{"href":321,"dataGaName":322,"dataGaLocation":454},{"text":324,"config":592},{"href":326,"dataGaName":327,"dataGaLocation":454},{"text":594,"config":595},"Sustainability",{"href":596,"dataGaName":594,"dataGaLocation":454},"/sustainability/",{"text":598,"config":599},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":600,"dataGaName":601,"dataGaLocation":454},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":329,"config":603},{"href":331,"dataGaName":332,"dataGaLocation":454},{"text":339,"config":605},{"href":341,"dataGaName":342,"dataGaLocation":454},{"text":344,"config":607},{"href":346,"dataGaName":347,"dataGaLocation":454},{"text":609,"config":610},"現代奴隷制の透明性に関する声明",{"href":611,"dataGaName":612,"dataGaLocation":454},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":50,"links":614},[615,617,622,624,629,634,639],{"text":50,"config":616},{"href":52,"dataGaName":53,"dataGaLocation":454},{"text":618,"config":619},"サポートを受ける",{"href":620,"dataGaName":621,"dataGaLocation":454},"/support/","get help",{"text":362,"config":623},{"href":364,"dataGaName":365,"dataGaLocation":454},{"text":625,"config":626},"ステータス",{"href":627,"dataGaName":628,"dataGaLocation":454},"https://status.gitlab.com/","status",{"text":630,"config":631},"利用規約",{"href":632,"dataGaName":633,"dataGaLocation":454},"/terms/","terms of use",{"text":635,"config":636},"プライバシーに関する声明",{"href":637,"dataGaName":638,"dataGaLocation":454},"/ja-jp/privacy/","privacy statement",{"text":640,"config":641},"Cookieの設定",{"dataGaName":642,"dataGaLocation":454,"id":643,"isOneTrustButton":12},"cookie preferences","ot-sdk-btn",{"items":645},[646,648,650],{"text":630,"config":647},{"href":632,"dataGaName":633,"dataGaLocation":454},{"text":635,"config":649},{"href":637,"dataGaName":638,"dataGaLocation":454},{"text":640,"config":651},{"dataGaName":642,"dataGaLocation":454,"id":643,"isOneTrustButton":12},[653],{"id":654,"title":18,"body":8,"config":655,"content":657,"description":8,"extension":26,"meta":661,"navigation":12,"path":662,"seo":663,"stem":664,"__hash__":665},"blogAuthors/en-us/blog/authors/toon-claes.yml",{"template":656},"BlogAuthor",{"name":18,"config":658},{"headshot":659,"ctfId":660},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663082/Blog/Author%20Headshots/toon_claes_headshot.png","toon",{},"/en-us/blog/authors/toon-claes",{},"en-us/blog/authors/toon-claes","guXJXoqO1anz4H932Namk7kqyZsO1xyVQr6stBL4o18",[667,682,694],{"content":668,"config":680},{"date":669,"heroImage":670,"title":671,"authors":672,"category":9,"body":674,"description":675,"tags":676},"2025-08-04","https://res.cloudinary.com/about-gitlab-com/image/upload/v1754287290/averr2ecwl01q2f9lknf.jpg","git mergeコマンドの基本を徹底解説",[673],"GitLab Team","## 目次\n\n1. [git mergeとは？](https://about.gitlab.com/ja-jp/blog/git-merge-command-overview/#git-merge%E3%81%A8%E3%81%AF%EF%BC%9F)\n2. [git mergeコマンドの基本](https://about.gitlab.com/ja-jp/blog/git-merge-command-overview/#git-merge%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%81%AE%E5%9F%BA%E6%9C%AC)\n3. [マージ先のブランチを準備する](https://about.gitlab.com/ja-jp/blog/git-merge-command-overview/#%E3%83%9E%E3%83%BC%E3%82%B8%E5%85%88%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E3%82%92%E6%BA%96%E5%82%99%E3%81%99%E3%82%8B)\n4. [最新のリモートコミットをフェッチする](https://about.gitlab.com/ja-jp/blog/git-merge-command-overview/#%E6%9C%80%E6%96%B0%E3%81%AE%E3%83%AA%E3%83%A2%E3%83%BC%E3%83%88%E3%82%B3%E3%83%9F%E3%83%83%E3%83%88%E3%82%92%E3%83%95%E3%82%A7%E3%83%83%E3%83%81%E3%81%99%E3%82%8B)\n5. [早送りマージと３ウェイマージ](https://about.gitlab.com/ja-jp/blog/git-merge-command-overview/#%E6%97%A9%E9%80%81%E3%82%8A%E3%83%9E%E3%83%BC%E3%82%B8%E3%81%A8%EF%BC%93%E3%82%A6%E3%82%A7%E3%82%A4%E3%83%9E%E3%83%BC%E3%82%B8)\n6. [git mergeによるコンフリクトの解決](https://about.gitlab.com/ja-jp/blog/git-merge-command-overview/#git-merge%E3%81%AB%E3%82%88%E3%82%8B%E3%82%B3%E3%83%B3%E3%83%95%E3%83%AA%E3%82%AF%E3%83%88%E3%81%AE%E8%A7%A3%E6%B1%BA)\n7. [git mergeコマンドのベストプラクティス](https://about.gitlab.com/ja-jp/blog/git-merge-command-overview/#git-merge%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%81%AE%E3%83%99%E3%82%B9%E3%83%88%E3%83%97%E3%83%A9%E3%82%AF%E3%83%86%E3%82%A3%E3%82%B9)\n8. [GitLabでgit mergeを使う](https://about.gitlab.com/ja-jp/blog/git-merge-command-overview/#git-merge%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%81%AE%E3%83%99%E3%82%B9%E3%83%88%E3%83%97%E3%83%A9%E3%82%AF%E3%83%86%E3%82%A3%E3%82%B9)\n9. [git merge のFAQ](https://about.gitlab.com/ja-jp/blog/git-merge-command-overview/#git-merge%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89-%E3%81%AEfaq)\n\n## git mergeとは？\n\ngit mergeとは、分岐したブランチをmerge（マージ、統合すること）するコマンドのことです。別のリポジトリからの変更を組み込む際にも使われ、git pull（git fetchとgit mergeを組み合わせたもの）の一部としても機能します。チームで開発を実施するときなどにmainブランチから作業用ブランチを作り、テストをしてからマージ、プッシュすることも多いでしょう。\n\nたとえば、main ブランチに基づいて作成された新しいブランチ’feature’があるとします。この feature ブランチを main にマージするのに使われるのがgit mergeコマンドです。\n\n## git mergeコマンドの基本\n\ngit mergeの基本的なコードは次のようになります。\n\n```shell\ngit merge BRANCH_NAME\n```\n\nブランチ名は、取り込みたいブランチの名前を入力します。\n\n一見簡単そうですが、マージをスムーズに実行するにはいくつか準備が必要となりますので、次の章で確認しましょう。\n\n## マージ先のブランチを準備する\n\ngit status を実行して、HEAD が取り込む先のブランチであることを確認します。必要に応じて\n\n```shell\ngit checkout BRANCH_NAME\n```\n\nを実行して、マージする先のブランチに切り替えます。\n\n## 最新のリモートコミットをフェッチする\n\nリモートで変更を加えたら、マージ先ブランチとマージ元ブランチに最新の変更内容を反映させます。その際は、[git fetchとgit pull](https://about.gitlab.com/ja-jp/blog/what-is-the-difference-between-git-fetch-and-git-pull/)を使います。その後、リモートで加えた変更内容がmainブランチに反映されていることを確認します。\n\n## 早送りマージと３ウェイマージ\n\n早送りマージは、ブランチが分岐していない場合にのみ使えるコマンドです。早送りマージでは、マージ自体は行われませんが、ブランチの先頭とブランチの末尾の履歴を結合することで、旧ブランチからアクセスできたコミットが、新ブランチからも利用できるようになります。\n\n強制的に早送りマージを実施する場合は以下のコードを使います（分岐がある場合など早送りマージができない場合にはエラーとなりマージはできません）\n\n```shell\ngit merge --ff-only\n```\n\n一方、ブランチが分岐している場合には、早送りマージを適用することはできず、マージする手段は３ウェイマージに限られます。３ウェイマージは、3 つのコミット （2 つのブランチのそれぞれ先端のコミットと履歴を統合するために生成される専用のコミット）を使用してマージコミットを生成することから来ています。\n\n```shell\ngit checkout BRANCH_NAME\n```\n\nを使うと、早送りマージが可能な時は早送りマージを実施し、できない時に３ウェイマージを実施します。\n\n## git mergeによるコンフリクトの解決\n\nマージの基本を理解すると、同じ箇所を同時に更新してしまったらどうなるのか、という疑問を持たれる方もいるのではないでしょうか。この場合、Git側ではどちらを優先すべきか判断ができず、手作業でコンフリクトを解決することを求めます。\n\nエラーメッセージは次のように表示されます。\n\n```shell\ngit merge BRANCH_NAME\nAuto-merging index.html\nCONFLICT (content): Merge conflict in index.html\nAutomatic merge failed; fix conflicts and then commit the result.\n```\n\nコンフリクトを解決するまで、処理は中断されます。どのファイルでコンフリクトが発生してマージできなかったのを確認するにはgit status を実行します。\n\n```shell\ngit status\n```\n\n未解決のコンフリクトについては unmerged として表示されます。標準的なコンフリクトマーカーがファイルに追加されるため、該当ファイルから修正できます。git addを実行して、コンフリクトが解決したことを Git に通知します。続いて通常の git commit を実行してマージ コミットを生成します。\n\n## git mergeコマンドのベストプラクティス\n\ngit mergeコマンドでよく起こる問題として、他のデベロッパーが加えた変更を破棄してしまうことが挙げられます。個々人がこまめにgit mergeを実行することで、変更を破棄してしまう問題は避けることができますが、マージそのもののコストが膨れ上がる可能性があります。複雑なコンフリクトが出ない場合に自動マージしてくれるようなツールの導入は、git mergeを使うチームの大きな手助けになるはずです。\n\n## GitLabでgit mergeを使う\n\ngit mergeのベストプラクティスとしてツールの使用をおすすめしましたが、[GitLab](https://about.gitlab.com/ja-jp/)なら自動マージ機能のほかにもリモートリポジトリのホスティング、インターフェースの提供、変更内容のコードレビュー、プッシュされたコードの自動ビルド、テスト、デプロイまでを一括で管理できます。\n\ngit mergeで起きるコンフリクトを自動で解決できるGitLabの無料トライアルは[こちら](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/&glm_content=default-saas-trial)からお申し込みいただけます。\n\n## git mergeコマンド のFAQ\n\n### git mergeコマンドとは何ですか？\n\ngit mergeとは、分岐したブランチをmerge（マージ、統合すること）するコマンドのことです。\n\n### mainブランチにマージするにはどうしたらいいですか？\n\nまず、\u003Ccode>git checkout BRANCH_NAME\u003C/code>を使ってmainブランチに移動します。\n\n次に\u003Ccode>git merge BRANCH_NAME\u003C/code>を使ってマージしたいブランチを指定します。\n\nマージ先ブランチ名）master\\\nマージするブランチ名）feature1の場合には\n\n```xml\n\u003Ccode>git checkout master\u003C/code>\n\u003Ccode>git merge feature1\u003C/code>\n```\n\n\\\nとなります。\n\n### git mergeとgit rebaseの違いは何ですか？\n\ngit mergeとgit rebaseはどちらもブランチを結合するコマンドです。mergeが新しいコミットを生成してコミット履歴が分散してしまうのに対し、rebaseはコミット履歴をひとつのブランチにまとめます。rebaseはログを整理する目的で使われることが多いですが、別のブランチで他のメンバーが加えた変更の履歴を消してしまう可能性などがあるので、上級者向けのコマンドといえます。\n\n*監修：知念 梨果* *[@rikachinen](https://gitlab.com/rikachinen)（GitLab合同会社 カスタマーサクセス本部 カスタマーサクセスエンジニア）*\n","この記事では、git mergeコマンドについてコマンドの基本的な使い方からリクエストコードまで解説します。",[677,25,678,679],"collaboration","tutorial","workflow",{"featured":12,"template":13,"slug":681},"git-merge-command-overview",{"content":683,"config":692},{"title":684,"description":685,"authors":686,"heroImage":687,"date":688,"body":689,"category":9,"tags":690},"オープンソースソフトウェア（OSS）とは？詳しく解説​","オープンソースの意味や、メリットとデメリットについて、分かりやすく解説します。",[673],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752720740/g9x8oi988xuhioglpczi.jpg","2025-07-17","## オープンソースとは？\n\nオープンソースとは、ソフトウェアのコードが公開され、誰もが利用、改良、再配布できるという仕組みのことを指します。「オープンソースソフトウェア」と同義で使用されることが多いです。\n\n## オープンソースソフトウェア（OSS）とは？\n\nオープンソースソフトウェアはOSSとも記述され、Open Source Softwareの略称です。一般的な商用ソフトウェアとは異なり、誰でも利用、改良、再配布ができるようソースコードが公開されています。これにより個人や企業のデベロッパーは、各々の環境に合わせてソフトウェアを自由に改変し、特定の用途や問題に最適化することが容易にできます。ただし、OSSによってはライセンス制約が存在する場合もあります。\n\nフリー（無料）ソフトと混同されることがありますが、フリーソフトのほとんどはソースコードが非公開です。よって、ソースコードが公開されているかどうかで、OSSかの判断をするのが一般的です。\n\n## オープンソースソフトウェアの基本原則\n\nオープンソフトウェアに明確な定義はありませんが、「ソースコードが公開されていること」以外にも広く認知されている要件があります。これら要件は、米国のOpen Source Initiative（OSI）という団体が提唱した以下10項目を指すのが一般的です。\n\n* 再配布の自由\n* ソースコードの配布\n* 派生ソフトウェアの配布許可\n* 作成者のオリジナルコードの完全性\n* 個人やグループに対する差別禁止\n* 使用分野に対する差別禁止\n* ライセンスの配布\n* 特定製品でのみ有効なライセンスの禁止\n* 他ソフトウェアを制限するライセンスの禁止\n* ライセンスの技術的中立\n\n要約するとOSSの基本原則は、ユーザーやデベロッパーに自由を提供し、協力的な環境を促進することと言えます。ただし、「自由」ではあるものの、ライセンスによって一定のルールは設定されています。例えば、GPLやMITライセンスは、OSSに付随するライセンスの利用や再配布、改変の範囲を規定し、自由利用を促進しつつも、デベロッパーやユーザーの権利を保護しています。OSS利用の際は、こういったライセンスルールを理解し、遵守することを忘れないようにしましょう。ライセンスについては後ほど詳しく解説します。\n\n## オープンソースソフトウェアの具体例\n\nどういったソフトウェアがOSSなのかと問われると、すぐには思いつかないかもしれません。実際に、どういったソフトが様々な分野で活躍しているのかいくつかご紹介しましょう。\n\n### WordPress\n\nWordPressという名前は、誰もが一度は聞いたことがあるでしょう。WordPressはウェブサイトを簡単に作成できるコンテンツ管理システム（CMS）で、世界中でもっとも利用されているCMSとなっています。ウェブサイトデベロッパーは自由にカスタマイズを行うことができ、また、活発なコミュニティで互いをサポートし合うことにより、新たな拡張機能の開発等に貢献しています。\n\n### GIMP\n\nGIMPは、イラストレーター、グラフィックデザイナー、フォトグラファー、サイエンティストなど画像を扱う専門家に人気の画像編集ソフトウェアです。ユーザーは無料でダウンロードして利用でき、WordPressと同じく活発なコミュニティが、日々のバグ修正や、新プラグインを開発をサポートしています。\n\n### Brave Browser\n\nBraveは、ユーザーのプライバシー保護を主眼としたウェブブラウザであり、広告やトラッキングを防止してくれます。さらに、独自の暗号通貨（BAT）や検索システムを開発しているなどの理由で、デベロッパー間では人気のブラウザの一つです。Braveもオープンソースであるため、個人が自由にブラウザ機能をカスタマイズしたり、新たに機能を追加したりすることができる仕様となっています。\n\n### GitLabのオープンソースプロジェクト\n\n[GitLabプラットフォーム](https://about.gitlab.com/ja-jp/)を利用して開発されているオープンソースプロジェクトをいくつかご紹介します。\n\n#### Drupal\n\nDrupalはWordPressと同様に、オープンソースのコンテンツ管理システム（CMS）です。堅牢性と拡張性の高さが評価されており、NASAや経済産業省といった政府機関や、Teslaなどの企業に採用されています。\n\n#### VLC\n\nWindowsやMacにとどまらず、LinuxやiOS等でも使うことできる、メディアプレイヤーです。多様な種類の音声や動画ファイルを再生でき、様々なファイル形式に対応しています。広告等、ユーザーにとって不要な機能が一切搭載されておらず、世界中で広く利用されています。\n\n#### LibreOffice\n\nMicrosoft Officeとよく比較されることがあるのが、LibreOfficeです。無料で利用することができ、様々なオフィスツールを提供することから、たくさんの企業や個人に使用されています。\n\n## オープンソース開発のメリットとデメリット\n\nOSSの開発には様々なメリットとデメリットがあります。開発手法についての議論は付きませんが、ここでは言及されることが多いポイントをいくつか挙げてみます。\n\n### メリット\n\n#### コミュニティによる自発的なサポートと開発\n\nオープンソース開発は通常、世界中のデベロッパーが参加した活発なコミュニティを形成しています。多種多様なバックグランドを持つ個々のユーザーたちがお互いにアイデアやフィードバック、サポートし合うことを基本とし、継続的な開発とサポートをしてくれます。\n\n#### 高い透明性に担保された信頼とセキュリティ\n\nOSSの信頼とセキュリティは、誰もがソースコードを参照できることで実現されています。\n\nまず、たくさんのデベロッパーの目に触れるため、脆弱性やバグが比較的早い段階で発見されます。これにより、セキュリティを高レベルに引き上げることができます。そして、ソースコードが公開されているため、不正な動作やバックドアの存在といったリスクを排除しやすく、ソフトウェアの信頼性を高めてくれます。\n\n#### 開発にかかる時間と費用の削減\n\nオープンソースソフトウェアは大抵が無料で、自由にソースコードを改変できます。よって、ライセンス料とスクラッチ開発が不要であり、個人や企業の費用と開発時間を大幅に削減してくれます。\n\n### デメリット\n\n#### 開発プロジェクトの継続性\n\nオープンソース開発は、有志が中心となって行われる場合が多いため、プロジェクトが遅延したり、突然中止となったりするリスクがあります。また、安定した開発スケジュールが維持されないこともあります。\n\nプロジェクトの多くは無償、スポンサー、寄付で成り立っていることが一般的なので、開発コアメンバーが抜けた、資金が枯渇してしまった、などの理由から開発自体が立ち行かなくなることもあります。\n\n#### 責任の所在が曖昧\n\nコミュニティ主導で開発が進められる場合、ユーザーにバグや他ソフトと統合できないといった問題が発生しても商用ソフトウェアとは異なり、自己解決しなくてはならないケースが通常です。迅速かつ的確なサポートが受けづらいケースも、発生することがあります。\n\n#### ライセンスの準拠で\n\n当然ながら、OSSにもライセンスが存在します。無条件に利用や再配布ができるわけではないので、しっかりとライセンスを理解した上で使用しなければいけません。ライセンス規約に違反してしまい、過去には訴訟に発展したケースもあるため、注意が必要です。詳しくは後ほど解説します。\n\n### オープンソースの課題とGitLabのアプローチ\n\nGitLabというプラットフォームが、OSSにおける課題に対してどう取り組んでいるかについて、いくつかご紹介しましょう。詳細を知りたい場合は、[オープンソースプロジェクト向けのGitLabソリューション](https://about.gitlab.com/ja-jp/solutions/open-source/)を読んでみてください。\n\n#### 脆弱性の早期発見と修正\n\nオープンソースは、コードが公開されているため、悪意のある人物が脆弱性を発見してしまうリスクがあります。\n\n[DevSecOpsプラットフォーム](https://about.gitlab.com/ja-jp/topics/devsecops/)であるGitLabは、開発プロセス全体においてセキュリティを重要視しています。静的アプリケーションセキュリティテスト（SAST）や依存関係スキャンといった強力なツールが、早期の脆弱性発見と修正を実現する仕組みを実現します。\n\n#### サポートの補完\n\nOSSはコミュニティによるサポートが中心となり、的確なサポートや迅速な対応を受けられないケースが発生することがあります。\n\n[商用版GitLab](https://about.gitlab.com/ja-jp/pricing/)には、「GitLab Premium」「GitLab Ultimate」があり、公式サポートという選択肢が用意されています。また、コミュニティの結束を高める働きかけをすることで自発的サポートも促進しています。\n\n#### コミュニティの活性化\n\n活発なコミュニティなしに、OSSを成功させることはできませんが、これを維持するのは容易ではありません。\n\nGitLabは、[GitLabフォーラム](https://forum.gitlab.com/c/community/gitlab-for-open-source/49)を運営したり、[オープンソース団体向けプログラム](https://about.gitlab.com/ja-jp/solutions/open-source/join/)を実施、GitLabハッカソンやオンラインイベントを開催したりすることで、デベロッパー同士の繋がりを促進、コミュニティの活性化と拡大に貢献しています。\n\n## オープンソースのライセンスとその重要性\n\nオープンソースのライセンスは、ソフトウェアの利用、配布、変更等に関する権利と制限を明記したものであり、法的拘束力を持ちます。よって、ソフト利用者はこれをしっかりと理解した上で、トラブル回避をすることが望ましいといえます。\n\nまた、ソフトウェアデベロッパーがどのライセンス規約にするかを考える場合には、透明性を重視するのか、自由度を重視するのかなどにより選択するライセンスが異なってきます。ここでは、いくつか代表的なものをご紹介しましょう。\n\n以下に表としてまとめてみました。\n\n![オープンソース　ライセンスのタイプと代表例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752720035/v9ld6h78ilk22x30nged.jpg)\n\n### コピーレフト\n\nコピーレフトライセンスは、元となるソフトウェアを再配布する時には、派生物も元OSSと同じ条件下で行う必要があるというものです。このタイプのライセンスは、非常に伝播性が強いのが特徴です。\n\nまたコピーレフトという言葉は、「コピーライト」をもじったものから誕生しました。\n\n### 準コピーレフト\n\nコピーレフトと比べ、伝播性が多少弱いのが準コピーレフトです。元のOSSのソースコードを再利用した時に、元のライセンスと同条件で再配布する必要があります。\n\n### 非コピーレフト\n\nパーミッシブライセンスとも呼ばれます。名前の通りですが、元のOSSと同条件のライセンスにする必要がありません。ソースコードの公開義務がないため、商用利用されることが多いです。\n\n## よくある質問\n\n### オープンソースソフトウェア（OSS）とは何ですか？\n\nOSSとは、ソースコードが公開され、誰でも自由に利用、修正、配布できるソフトウェアのことです。\n\n### OSSのセキュリティは安心ですか？\n\nOSSライセンスは、ソフトウェアの利用や再配布に関する自由と制約を明確に定義したものです。\n\n### OSSのライセンスにはどんな種類がありますか？\n\nライセンスにはGPL、MIT、Apache Licenseなど、異なる自由度や利用条件を持つものがあり、コピーレフト、準コピーレフト、非コピーレフトの３つに大別されます。\n\n### なぜ企業がOSSを採用するのですか？\n\nコスト削減、柔軟性、信頼性向上、技術コミュニティとの連携が理由となる場合が多いです。またGitLabでは、[オープンソースプロジェクト向けのソリューション](https://about.gitlab.com/ja-jp/solutions/open-source/)を提供しています。ぜひご確認ください。\n\n*監修：佐々木 直晴* [@naosasaki](https://gitlab.com/naosasaki)*（GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[677,23,24,691],"security",{"featured":12,"template":13,"slug":693},"what-is-open-source",{"content":695,"config":703},{"title":696,"description":697,"authors":698,"heroImage":19,"body":700,"date":701,"category":9,"tags":702},"Git 2.50.0の新機能","git-diff-pairs(1)コマンドや、参照の一括更新を行うためのgit-rev-list(1)オプションなど、GitLabのGitチームとGitコミュニティによるコントリビュートをご紹介します。",[699],"Justin Tobler","Gitプロジェクトは最近、[Gitバージョン2.50.0](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/T/#u)をリリースしました。今回のリリースの注目すべきポイントをいくつかご紹介します。これには、GitLabのGitチームやより広範なGitコミュニティからのコントリビュートも含まれています。\n## 新しいgit-diff-pairs(1)コマンド\n\n差分は、すべてのコードレビューの中心となるもので、2つのリビジョン間で行われた\nすべての変更を表示します。GitLabでは、さまざまな場所で差分が表示されますが、最も\n一般的なのはマージリクエストの[「変更」タブ](https://docs.gitlab.com/user/project/merge_requests/changes/)です。\nその裏側では、差分の生成に[`git-diff(1)`](https://git-scm.com/docs/git-diff)が\n使われています。たとえば、以下のように使います。\n\n```shell\n$ git diff HEAD~1 HEAD\n```\n\nこのコマンドは、変更されたすべてのファイルの完全な差分を返します。ただし、リビジョン間で変更されたファイル数が非常に多い場合、スケーラビリティの課題が生じる可能性があります。GitLabのバックエンドでは、コマンドが自己設定されたタイムアウトに達してしまうこともあります。変更数が多い場合、\n差分の計算をより小さく扱いやすい単位に分割できる方法があれば、より効果的です。\n\nこの課題を解決する1つの方法は、\n[`git-diff-tree(1)`](https://git-scm.com/docs/git-diff-tree)を使って、\n変更されたすべてのファイルに関する情報を取得することです。\n\n```shell\n$ git diff-tree -r -M --abbrev HEAD~ HEAD\n:100644 100644 c9adfed339 99acf81487 M      Documentation/RelNotes/2.50.0.adoc\n:100755 100755 1047b8d11d 208e91a17f M      GIT-VERSION-GEN\n```\n\nGitはこの出力を[「raw」フォーマット](https://git-scm.com/docs/git-diff-tree#_raw_output_format)と呼んでいます。\n簡単に言えば、出力の各行にはファイルのペアと、\nそれらの間で何が変更されたかを示すメタデータが表示されます。大規模な変更に対して\n「パッチ」形式の出力を生成する方法と比べて、\nこの処理は比較的高速な上、すべての変更の概要を把握できます。また、このコマンドでは、`-M`フラグを付けることでリネーム検出を有効にし、変更がファイルのリネームによるものかどうかを判別することもできます。\n\nこの情報を使えば、`git-diff(1)`を使って各ファイルペアの差分を\n個別にコンピューティングすることができます。たとえば、以下のようにblob IDを\n直接指定することも可能です。\n\n```shell\n$ git diff 1047b8d11de767d290170979a9a20de1f5692e26 208e91a17f04558ca66bc19d73457ca64d5385f\n```\n\nこの処理は、各ファイルペアごとに繰り返すことができますが、\n個別のファイル差分ごとにGitプロセスを立ち上げるのは、あまり効率的ではありません。\nさらに、blob IDを使った場合、変更ステータスやファイルモードといった、\n親ツリーオブジェクトに格納されているコンテキスト情報が差分から失われてしまいます。\n本当に必要なのは、「raw」なファイルペア情報を元に、\n対応するパッチ出力を生成する仕組みです。\n\nバージョン2.50から、Gitに新しい組み込みコマンド\n[`git-diff-pairs(1)`](https://git-scm.com/docs/git-diff-pairs)が追加されました。このコマンドは、\n標準入力（stdin）から「raw」形式のファイルペア情報を受け取り、どのパッチを出力すべきかを正確に判断します。以下の例は、\nこのコマンドの使用方法を示しています。\n\n```shell\n$ git diff-tree -r -z -M HEAD~ HEAD | git diff-pairs -z\n```\n\nこのように使用した場合、出力結果は`git-diff(1)`を使った場合と同じになります。\nパッチ出力を生成する専用コマンドを分けることで、\n`git-diff-tree(1)`から得られた「raw」出力を、より小さなファイルペアのバッチに分割し、それぞれを別々の\n`git-diff-pairs(1)`プロセスにフィードすることができます。これにより、差分を一度にすべてコンピューティングする必要がなくなるため、\n先に挙げたスケーラビリティの課題が解決されます。今後のGitLabリリースでは、\nこの仕組みの応用により、\n特に変更量が多い場合における差分生成のパフォーマンス向上が\n期待されます。この変更についての詳細は、該当する\n[メーリングリストのスレッド](https://lore.kernel.org/git/20250228213346.1335224-1-jltobler@gmail.com/)をご覧ください。\n\n_このプロジェクトは[Justin Tobler](https://gitlab.com/justintobler)が主導しました。_\n\n## 参照更新の一括処理\n\nGitには、参照を更新するための[`git-update-ref(1)`](https://git-scm.com/docs/git-update-ref)\nコマンドが用意されています。このコマンドを`--stdin`フラグとともに使用すると、\n複数の参照を1つのトランザクションとしてまとめて更新できます。\nこれを行うには、各参照更新の指示を標準入力（stdin）で指定します。\nこの方法で参照を一括更新すると、アトミックな動作も実現できます。つまり、1つでも参照の更新に失敗した場合、\nトランザクション全体が中断され、\nどの参照も更新されません。以下は、この動作を示す例です。\n\n```shell\n# 3つの空のコミットと「foo」という名前のブランチを持つリポジトリを作成する\n$ git init\n$ git commit --allow-empty -m 1\n$ git commit --allow-empty -m 2\n$ git commit --allow-empty -m 3\n$ git branch foo\n\n# コミットIDを出力する\n$ git rev-list HEAD\ncf469bdf5436ea1ded57670b5f5a0797f72f1afc\n5a74cd330f04b96ce0666af89682d4d7580c354c\n5a6b339a8ebffde8c0590553045403dbda831518\n\n# トランザクションで新しい参照を作成し、既存の参照を更新しようとします。\n# 指定された古いオブジェクトIDが一致しないため、更新は失敗することが予想されます。\n$ git update-ref --stdin \u003C\u003CEOF\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n> EOF\nfatal: cannot lock ref 'refs/heads/foo': is at cf469bdf5436ea1ded57670b5f5a0797f72f1afc but expected 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n# 「bar」リファレンスは作成されませんでした。\n$ git switch bar\nfatal: invalid reference: bar\n```\n\n多くの参照を個別に更新する場合と比べて、一括で更新するほうがはるかに効率的です。\nこの方法は基本的にうまく機能しますが、\n一括更新による効率面のメリットを優先するために、\nリクエストされた参照更新の一部が失敗することを許容したい場合も\nあります。\n\n今回のリリースで、`git-update-ref(1)`に新しく`--batch-updates`オプションが追加されました。\nこのオプションを使用すると、1つ以上の参照更新が失敗しても、処理を続行できるようになります。\nこのモードでは、個々の失敗が次の形式で出力されます。\n\n```text\nrejected SP (\u003Cold-oid> | \u003Cold-target>) SP (\u003Cnew-oid> | \u003Cnew-target>) SP \u003Crejection-reason> LF\n```\n\nこれにより、成功した参照の更新はそのまま進行しつつ、どの更新が拒否されたのか、\nまたその理由についての情報も得ることができます。前の例と同じリポジトリを\n使った例は以下のとおりです。\n\n```shell\n# トランザクションで新しい参照を作成し、既存の参照を更新しようとします。\n$ git update-ref --stdin --batch-updates \u003C\u003CEOF\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n> EOF\nrejected refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c incorrect old value provided\n\n# 「foo」への更新が拒否されたにもかかわらず、「bar」参照が作成されました。\n$ git switch bar\nSwitched to branch 'bar'\n```\n\n今回は`--batch-updates`オプションを使用したことで、\n更新処理が失敗しても参照の作成は成功しました。この一連のパッチは、\n`git-fetch(1)`や`git-receive-pack(1)`における今後の一括参照更新時の\nパフォーマンス改善の基盤となります。詳細については、該当する\n[メーリングリストのスレッド](https://lore.kernel.org/git/20250408085120.614893-1-karthik.188@gmail.com/)をご覧ください。\n\n_このプロジェクトは、[Karthik Nayak](https://gitlab.com/knayakgl)が主導しました。_\n\n## git-cat-file(1)の新しいフィルタオプション\n\n[`git-cat-file(1)`](https://git-scm.com/docs/git-cat-file)を使うと、\nリポジトリ内に含まれるすべてのオブジェクトの情報を\n`--batch–all-objects`オプションで出力できます。たとえば、以下のように実行します。\n\n```shell\n# シンプルなリポジトリを設定します。\n$ git init\n$ echo foo >foo\n$ git add foo\n$ git commit -m init\n\n# 到達不能なオブジェクトを作成します。\n$ git commit --amend --no-edit\n\n# git-cat-file(1)を使用して、到達不能なオブジェクトを含むすべてのオブジェクトに関する情報を出力します。\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)'\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\ntree 205f6b799e7d5c2524468ca006a0131aa57ecce7\nblob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n```\n\n状況によっては、リポジトリ内のすべてのオブジェクトを検索し、\n特定の属性に基づいて一部のオブジェクトだけを出力したい場合があります。\nたとえば、コミットオブジェクトだけを表示したいときは、\n`grep(1)`を使って以下のように実行できます。\n\n```shell\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' | grep ^commit\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n```\n\nこの方法でも目的は達成できますが、出力のフィルタリングには欠点があります。\nそれは、`git-cat-file(1)`が\nユーザーが関心を持っていないオブジェクトも含め、リポジトリ内のすべてのオブジェクトをたどらなければならない点です。これはかなり非効率です。\n\n今回のリリースでは、`git-cat-file(1)`に`--filter`オプションが追加され、\n指定した条件に一致するオブジェクトだけを表示できるようになりました。これは`git-rev-list(1)`にある同名のオプションと似ていますが、\n対応しているフィルターの種類はその一部に限られています。\n対応しているフィルターは`blob:none`、`blob:limit=`および\n`object:type=`です。先ほどの例と同様に、オブジェクトはGitを使用して直接\n種類でフィルタリングできます。\n\n```shell\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' --filter='object:type=commit'\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n```\n\nGitに処理を任せられるのは便利なだけでなく、オブジェクト数の多い大規模なリポジトリにおいては\n効率面のメリットも期待できます。\nリポジトリにビットマップインデックスがある場合、\nGitが特定の種類のオブジェクトを効率的に検索できるようになり、パックファイル全体をスキャンする必要がなくなるため、\n処理速度が大幅に向上します。\n[Chromiumリポジトリ](https://github.com/chromium/chromium.git)で行われた\nベンチマークでは、こうした最適化による大きな改善が確認されています。\n\n```text\nBenchmark 1: git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter Time (mean ± σ):     82.806 s ±  6.363 s    [User: 30.956 s, System: 8.264 s] Range (min … max):   73.936 s … 89.690 s    10 runs\nBenchmark 2: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag Time (mean ± σ):      20.8 ms ±   1.3 ms    [User: 6.1 ms, System: 14.5 ms] Range (min … max):    18.2 ms …  23.6 ms    127 runs\nBenchmark 3: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit Time (mean ± σ):      1.551 s ±  0.008 s    [User: 1.401 s, System: 0.147 s] Range (min … max):    1.541 s …  1.566 s    10 runs\nBenchmark 4: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree Time (mean ± σ):     11.169 s ±  0.046 s    [User: 10.076 s, System: 1.063 s] Range (min … max):   11.114 s … 11.245 s    10 runs\nBenchmark 5: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob Time (mean ± σ):     67.342 s ±  3.368 s    [User: 20.318 s, System: 7.787 s] Range (min … max):   62.836 s … 73.618 s    10 runs\nBenchmark 6: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none Time (mean ± σ):     13.032 s ±  0.072 s    [User: 11.638 s, System: 1.368 s] Range (min … max):   12.960 s … 13.199 s    10 runs\nSummary git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag 74.75 ± 4.61 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit 538.17 ± 33.17 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree 627.98 ± 38.77 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none 3244.93 ± 257.23 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob 3990.07 ± 392.72 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter ```\n\n興味深いことに、これらの結果からは、処理時間がパックファイル内の総オブジェクト数ではなく、\n指定された種類のオブジェクト数に比例して増減することが示されています。\n元のメーリングリストのスレッドは、\n[こちら](https://lore.kernel.org/git/20250221-pks-cat-file-object-type-filter-v1-0-0852530888e2@pks.im/)でご覧いただけます。\n\n_このプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。_\n\n## バンドル生成時のパフォーマンスが向上\n\nGitには、指定した参照とそれに関連する到達可能なオブジェクトを含むリポジトリのアーカイブを生成する機能があります。\n具体的には、\n[`git-bundle(1)`](https://git-scm.com/docs/git-bundle)コマンドを使用します。この操作は、\nGitLabがリポジトリのバックアップを作成する際や、\n[バンドルURI](https://git-scm.com/docs/bundle-uri)メカニズムの一部としても使用されます。\n\n何百万もの参照を含む大規模なリポジトリでは、\nこの操作に数時間から数日かかることもあります。たとえば、GitLabのメインリポジトリ\n（[gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab)）では、\nバックアップに約48時間を要していました。調査の結果、バンドルに重複した参照が含まれないようにチェックする処理において、\nパフォーマンスのボトルネックが存在することが判明しました。\nこの実装では、すべての参照をイテレーションして比較するために入れ子の`for`loopが使われており、\n時間計算量はO(N^2)となっていました。これは、\nリポジトリ内の参照数が増えるほど、処理性能が大きく低下する構造です。\n\n今回のリリースでは、この問題に対応し、\nネストされたloopをマップ型のデータ構造に置き換えることで、処理速度が大幅に向上しました。以下は、\n10万件の参照を含むリポジトリでバンドルを作成した際のパフォーマンス改善を\n示すベンチマーク結果です。\n\n```text\nBenchmark 1: bundle (refcount = 100000, revision = master) Time (mean ± σ):     14.653 s ±  0.203 s    [User: 13.940 s, System: 0.762 s] Range (min … max):   14.237 s … 14.920 s    10 runs\nBenchmark 2: bundle (refcount = 100000, revision = HEAD) Time (mean ± σ):      2.394 s ±  0.023 s    [User: 1.684 s, System: 0.798 s] Range (min … max):    2.364 s …  2.425 s    10 runs\nSummary bundle (refcount = 100000, revision = HEAD) ran 6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master) ```\n\n詳しくは、\n[GitLabがリポジトリのバックアップ時間を48時間から41分に短縮した方法](https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes/)を紹介するブログ記事をご覧ください。\n元のメーリングリストのスレッドは\n[こちら](https://lore.kernel.org/git/20250401-488-generating-bundles-with-many-references-has-non-linear-performance-v1-0-6d23b2d96557@gmail.com/)でご覧いただけます。\n\n_このプロジェクトは[Karthik Nayak](https://gitlab.com/knayakgl)が主導しました。_\n\n## バンドルURIのアンバンドルの改善\n\nGitの[バンドルURI](https://git-scm.com/docs/bundle-uri)メカニズムは、\nフェッチするバンドルの場所をクライアントに提供することで、クローンやフェッチの速度を\n向上させることを目的としています。クライアントがバンドルをダウンロードすると、\n`refs/heads/*`以下の参照が、その関連オブジェクトとともにバンドルから\nリポジトリにコピーされます。バンドルには`refs/tags/*`のように\n`refs/heads/*`以外の参照も含まれていることがありますが、\nこれらはクローン時にバンドルURIを使用する場合、単に無視されていました。\n\nGit 2.50ではこの制限が解除され、\nダウンロードされたバンドルに含まれる`refs/*`に一致するすべての参照がコピーされるようになりました。\nこの機能を実装した[Scott Chacon](https://github.com/schacon)さんは、\n[gitlab-org/gitlab-foss](https://gitlab.com/gitlab-org/gitlab-foss)をクローンした際の\n挙動の違いを紹介しています。\n\n```shell\n$ git-v2.49 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.49\nCloning into 'gl2.49'...\nremote: Enumerating objects: 1092703, done.\nremote: Counting objects: 100% (973405/973405), done.\nremote: Compressing objects: 100% (385827/385827), done.\nremote: Total 959773 (delta 710976), reused 766809 (delta 554276), pack-reused 0 (from 0)\nReceiving objects: 100% (959773/959773), 366.94 MiB | 20.87 MiB/s, done.\nResolving deltas: 100% (710976/710976), completed with 9081 local objects.\nChecking objects: 100% (4194304/4194304), done.\nChecking connectivity: 959668, done.\nUpdating files: 100% (59972/59972), done.\n\n$ git-v2.50 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.50\nCloning into 'gl-2.50'...\nremote: Enumerating objects: 65538, done.\nremote: Counting objects: 100% (56054/56054), done.\nremote: Compressing objects: 100% (28950/28950), done.\nremote: Total 43877 (delta 27401), reused 25170 (delta 13546), pack-reused 0 (from 0)\nReceiving objects: 100% (43877/43877), 40.42 MiB | 22.27 MiB/s, done.\nResolving deltas: 100% (27401/27401), completed with 8564 local objects.\nUpdating files: 100% (59972/59972), done.\n```\n\nこれらの結果を比較すると、Git 2.50はバンドル展開後に43,887個（40.42 MiB）のオブジェクトをフェッチしているのに対し、\nGit 2.49は合計で959,773個（366.94 MiB）のオブジェクトをフェッチしています。\nGit 2.50では、取得されるオブジェクト数が約95%、\nデータ量が約90%削減されており、クライアントとサーバーの双方にとってメリットがあります。\nサーバー側ではクライアントに送信するデータ量が大幅に減り、\nクライアント側でもダウンロードおよび展開するデータが少なくて済みます。Chaconさんの提供した例では、\nこれによって処理速度が25%向上しました。\n\n詳細については、\n該当する[メーリングリストのスレッド](https://lore.kernel.org/git/pull.1897.git.git.1740489585344.gitgitgadget@gmail.com/)をご覧ください。\n\n_この一連のパッチは、[Scott Chacon](https://github.com/schacon)さんによって提供されました。_\n\n## 詳細はこちら\n\n本記事でご紹介したのは、最新リリースにおいてGitLabと広範なGitコミュニティによって行われた\nコントリビュートのごく一部にすぎません。Gitプロジェクトの[公式リリースのお知らせ](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/)では、\nさらに詳しい情報をご覧になれます。また、\n[以前のGitリリースのブログ記事](https://about.gitlab.com/blog/tags/git/)もぜひご覧ください。GitLabチームメンバーによる過去の主なコントリビュートをご確認いただけます。\n","2025-06-16",[25,24,23],{"featured":12,"template":13,"slug":704},"what-s-new-in-git-2-50-0",{"promotions":706},[707,721,734],{"id":708,"categories":709,"header":711,"text":712,"button":713,"image":718},"ai-modernization",[710],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":714,"config":715},"Get your AI maturity score",{"href":716,"dataGaName":717,"dataGaLocation":242},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":719},{"src":720},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":722,"categories":723,"header":726,"text":712,"button":727,"image":731},"devops-modernization",[724,725],"product","devsecops","Are you just managing tools or shipping innovation?",{"text":728,"config":729},"Get your DevOps maturity score",{"href":730,"dataGaName":717,"dataGaLocation":242},"/assessments/devops-modernization-assessment/",{"config":732},{"src":733},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":735,"categories":736,"header":737,"text":712,"button":738,"image":742},"security-modernization",[691],"Are you trading speed for security?",{"text":739,"config":740},"Get your security maturity score",{"href":741,"dataGaName":717,"dataGaLocation":242},"/assessments/security-modernization-assessment/",{"config":743},{"src":744},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"header":746,"blurb":747,"button":748,"secondaryButton":752},"今すぐ開発をスピードアップ","DevSecOpsに特化したインテリジェントオーケストレーションプラットフォームで実現できることをご確認ください。\n",{"text":45,"config":749},{"href":750,"dataGaName":48,"dataGaLocation":751},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":50,"config":753},{"href":52,"dataGaName":53,"dataGaLocation":751},1772652134447]