[{"data":1,"prerenderedAt":813},["ShallowReactive",2],{"/ja-jp/blog/whats-new-in-git-2-49-0":3,"navigation-ja-jp":39,"banner-ja-jp":449,"footer-ja-jp":459,"blog-post-authors-ja-jp-Toon Claes":695,"blog-related-posts-ja-jp-whats-new-in-git-2-49-0":709,"blog-promotions-ja-jp":751,"next-steps-ja-jp":804},{"id":4,"title":5,"authorSlugs":6,"authors":8,"body":10,"category":11,"categorySlug":11,"config":12,"content":16,"date":20,"description":17,"extension":25,"externalUrl":26,"featured":14,"heroImage":19,"isFeatured":14,"meta":27,"navigation":14,"path":28,"publishedDate":20,"rawbody":29,"seo":30,"slug":13,"stem":35,"tagSlugs":36,"tags":37,"template":15,"updatedDate":26,"__hash__":38},"blogPosts/ja-jp/blog/whats-new-in-git-2-49-0.yml","Git 2.49.0の新機能",[7],"toon-claes",[9],"Toon Claes","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/)","open-source",{"slug":13,"featured":14,"template":15},"whats-new-in-git-2-49-0",true,"BlogPost",{"title":5,"description":17,"authors":18,"heroImage":19,"date":20,"body":10,"category":11,"tags":21},"このリリースでは、zlib-ngによるパフォーマンス向上、新しい名前ハッシュアルゴリズム、そして新しいコマンドgit-backfill(1)の導入などが行われています。",[9],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663087/Blog/Hero%20Images/git3-cover.png","2025-03-14",[22,23,24],"community","open source","git","yml",null,{},"/ja-jp/blog/whats-new-in-git-2-49-0","seo:\n  title: Git 2.49.0の新機能\n  description: >-\n    このリリースでは、zlib-ngによるパフォーマンス向上、新しい名前ハッシュアルゴリズム、そして新しいコマンドgit-backfill(1)の導入などが行われています。\n  ogTitle: Git 2.49.0の新機能\n  ogDescription: >-\n    このリリースでは、zlib-ngによるパフォーマンス向上、新しい名前ハッシュアルゴリズム、そして新しいコマンドgit-backfill(1)の導入などが行われています。\n  noIndex: false\n  ogImage: >-\n    https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663087/Blog/Hero%20Images/git3-cover.png\n  ogUrl: https://about.gitlab.com/blog/whats-new-in-git-2-49-0\n  ogSiteName: https://about.gitlab.com\n  ogType: article\n  canonicalUrls: https://about.gitlab.com/blog/whats-new-in-git-2-49-0\ncontent:\n  title: Git 2.49.0の新機能\n  description: >-\n    このリリースでは、zlib-ngによるパフォーマンス向上、新しい名前ハッシュアルゴリズム、そして新しいコマンドgit-backfill(1)の導入などが行われています。\n  authors:\n    - Toon Claes\n  heroImage: >-\n    https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663087/Blog/Hero%20Images/git3-cover.png\n  date: '2025-03-14'\n  body: \"Gitプロジェクトは最近、[Git\n    2.49.0](https://lore.kernel.org/git/xmqqfrjfilc8.fsf@gitster.g/)をリリースしました。こ\\\n    のリリースには、GitLabのGitチームや、より広範なGitコミュニティからのコントリビュートが含まれます。注目すべきハイライトを見てみましょう。\n\n\n    この記事では以下の変更点についてご紹介します。\n\n    - [git-backfill(1)と新しいpath-walk\n    API](#git-backfill(1)-and-the-new-path-walk-api)\n\n    - [zlib-ngの導入](#introduction-of-zlib-ng)\n\n    - [Mesonの継続的なイテレーション](#continued-iteration-on-meson)\n\n    -\n    [.git/branches/および.git/remotes/の非推奨化](#deprecation-of-.gitbranches%2F-and-.\\\n    git%2Fremotes%2F)\n\n    - [libgitに対するRustバインディング](#rust-bindings-for-libgit)\n\n    - [新しい名前ハッシュアルゴリズム](#new-name-hashing-algorithm)\n\n    - [プロミサーリモート機能](#promisor-remote-capability)\n\n    - [`--revision`を使用した軽量なクローン](#thin-clone-using---revision)\n\n\n    ## git-backfill(1)と新しいpath-walk API\n\n\n    [`git-clone(1)`](https://git-scm.com/docs/git-clone)コマンドでGitリポジトリをクローンする際に、\n\n    [`--filter`](https://git-scm.com/docs/git-clone#Documentation/git-clone.txt\\\n    -code--filterltfilter-specgtcode)オプションを指定することができます。\n\n    このオプションを使用すると、部分クローンを作成できます。部分クローンでは、指定されたオブジェクトフィルターに従って、サーバーから到達可能なオブジェクト\\\n    の一部のみが送信されます。\n\n    例えば、`--filter=blob:none`を指定してクローンを作成すると、サーバーからblob（ファイルの中身）が一切フェッチされず、_ブロブを\\\n    含まないクローン_が作成されます。\n\n\n    ブロブを含まないクローンには、すべての到達可能なコミットとツリーは含まれますが、blobは含まれていません。そのため、[`git-checkout(1\\\n    )`](https://git-scm.com/docs/git-checkout)のような操作を行うと、\n\n    Gitは必要なblobをサーバーからダウンロードして、その操作を完了させます。ただし、[`git-blame(1)`](https://git-scm\\\n    .com/docs/git-blame)のような一部の操作では、\n\n    必要なオブジェクトが1つずつダウンロードされることになり、この処理が非常に遅くなります。\n\n    これは、`git-blame(1)`がコミット履歴をたどって必要なblobを特定し、\n\n    不足している各blobを個別にサーバーへリクエストする必要があるためです。\n\n\n    Git\n    2.49では、新たに`git-backfill(1)`というサブコマンドが導入されました。これは、ブロブを含まない部分クローンに対して、不足しているb\\\n    lobをダウンロードするために使用できます。\n\n\n    内部的には、`git-backfill(1)`は新しいパスウォークAPIを利用しています。これはGitが通常行うコミットのイテレーション処理とは異なり\\\n    ます。従来の方法では、コミットを1つずつイテレーションし、それぞれに関連するツリーやblobに再帰的にアクセスしていました。一方、パスウォークAPIは\\\n    パスごとに処理を行います。各パスについて関連するツリーオブジェクトのリストをスタックに追加し、そのスタックを深さ優先で処理します。つまり、コミット`1\\\n    `のすべてのオブジェクトを処理してからコミット`2`へ進むのではなく、ファイル`A`のすべてのバージョンを全コミットにわたって処理してからファイル`B\\\n    `に進む、という方式です。このアプローチは、パスごとにグループ化して処理する必要がある場合に、大幅なパフォーマンス向上をもたらします。\n\n\n    [`gitlab-org/git`](https://gitlab.com/gitlab-org/git)リポジトリのブロブを含まないクローンを作成し\\\n    、その使い方をお見せします。\n\n\n    ```shell\n\n    $ git clone --filter=blob:none --bare --no-tags\n    git@gitlab.com:gitlab-org/git.git\n\n    Cloning into bare repository 'git.git'...\n\n    remote: Enumerating objects: 245904, done.\n\n    remote: Counting objects: 100% (1736/1736), done.\n\n    remote: Compressing objects: 100% (276/276), done.\n\n    remote: Total 245904 (delta 1591), reused 1547 (delta 1459), pack-reused\n    244168 (from 1)\n\n    Receiving objects: 100% (245904/245904), 59.35 MiB | 15.96 MiB/s, done.\n\n    Resolving deltas: 100% (161482/161482), done.\n\n    ```\n\n\n    上の例では、Gitが初期ブランチをチェックアウトするためにblobをダウンロードする必要がないよう、`--bare`オプションを使用しています。このク\\\n    ローンにblobが含まれていないことは、次のコマンドで確認できます。\n\n\n    ```sh\n\n    $ git cat-file --batch-all-objects --batch-check='%(objecttype)' | sort |\n    uniq -c\n\n    \\  83977 commit\n\n    \\ 161927 tree\n\n    ```\n\n\n    もしこのリポジトリ内のファイル内容を確認したい場合、Gitはそのファイルをダウンロードする必要があります。\n\n\n    ```sh\n\n    $ git cat-file -p HEAD:README.md\n\n    remote: Enumerating objects: 1, done.\n\n    remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 1 (from 1)\n\n    Receiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\n\n\n    [![Build\n    status](https://github.com/git/git/workflows/CI/badge.svg)](https://github.\\\n    com/git/git/actions?query=branch%3Amaster+event%3Apush)\n\n\n    Git - fast, scalable, distributed revision control system\n\n    =========================================================\n\n\n    Git is a fast, scalable, distributed revision control system with an\n\n    unusually rich command set that provides both high-level operations\n\n    and full access to internals.\n\n\n    [中略]\n\n    ```\n\n\n    ご覧のとおり、Gitはまずリモートリポジトリにアクセスし、blobをダウンロードしてから内容を表示しています。\n\n\n    このファイルに対して`git-blame(1)`を実行したい場合は、さらに多くのデータをダウンロードする必要があります。\n\n\n    ```sh\n\n    $ git blame HEAD README.md\n\n    remote: Enumerating objects: 1, done.\n\n    remote: Counting objects: 100% (1/1), done.\n\n    remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\n\n    Receiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\n\n    remote: Enumerating objects: 1, done.\n\n    remote: Counting objects: 100% (1/1), done.\n\n    remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\n\n    Receiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\n\n    remote: Enumerating objects: 1, done.\n\n    remote: Counting objects: 100% (1/1), done.\n\n    remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\n\n    Receiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\n\n    remote: Enumerating objects: 1, done.\n\n\n    [中略]\n\n\n    df7375d772 README.md (Ævar Arnfjörð Bjarmason 2021-11-23 17:29:09 +0100  1)\n    [![Build\n    status](https://github.com/git/git/workflows/CI/badge.svg)](https://github.\\\n    com/git/git/actions?query=branch%3Amaster+event%3Apush)\n\n    5f7864663b README.md (Johannes Schindelin \\t2019-01-29 06:19:32 -0800  2)\n\n    28513c4f56 README.md (Matthieu Moy        \\t2016-02-25 09:37:29 +0100  3)\n    Git - fast, scalable, distributed revision control system\n\n    28513c4f56 README.md (Matthieu Moy        \\t2016-02-25 09:37:29 +0100  4)\n    =========================================================\n\n    556b6600b2 README\\t(Nicolas Pitre       \\t2007-01-17 13:04:39 -0500  5)\n\n    556b6600b2 README\\t(Nicolas Pitre       \\t2007-01-17 13:04:39 -0500  6) Git\n    is a fast, scalable, distributed revision control system with an\n\n    556b6600b2 README\\t(Nicolas Pitre       \\t2007-01-17 13:04:39 -0500  7)\n    unusually rich command set that provides both high-level operations\n\n    556b6600b2 README\\t(Nicolas Pitre       \\t2007-01-17 13:04:39 -0500  8) and\n    full access to internals.\n\n    556b6600b2 README\\t(Nicolas Pitre       \\t2007-01-17 13:04:39 -0500  9)\n\n\n    [中略]\n\n    ```\n\n\n    出力は省略していますが、ご覧のように、Gitはそのファイルの各リビジョンについて個別にサーバーへアクセスしています。これはとても非効率的です。そこで`\\\n    git-backfill(1)`を使えば、Gitに対してすべてのblobを一括でダウンロードするよう指示できます。\n\n\n    ```shell\n\n    $ git backfill\n\n    remote: Enumerating objects: 50711, done.\n\n    remote: Counting objects: 100% (15438/15438), done.\n\n    remote: Compressing objects: 100% (708/708), done.\n\n    remote: Total 50711 (delta 15154), reused 14730 (delta 14730), pack-reused\n    35273 (from 1)\n\n    Receiving objects: 100% (50711/50711), 11.62 MiB | 12.28 MiB/s, done.\n\n    Resolving deltas: 100% (49154/49154), done.\n\n    remote: Enumerating objects: 50017, done.\n\n    remote: Counting objects: 100% (10826/10826), done.\n\n    remote: Compressing objects: 100% (634/634), done.\n\n    remote: Total 50017 (delta 10580), reused 10192 (delta 10192), pack-reused\n    39191 (from 1)\n\n    Receiving objects: 100% (50017/50017), 12.17 MiB | 12.33 MiB/s, done.\n\n    Resolving deltas: 100% (48301/48301), done.\n\n    remote: Enumerating objects: 47303, done.\n\n    remote: Counting objects: 100% (7311/7311), done.\n\n    remote: Compressing objects: 100% (618/618), done.\n\n    remote: Total 47303 (delta 7021), reused 6693 (delta 6693), pack-reused\n    39992 (from 1)\n\n    Receiving objects: 100% (47303/47303), 40.84 MiB | 15.26 MiB/s, done.\n\n    Resolving deltas: 100% (43788/43788), done.\n\n    ```\n\n\n    これにより、すべてのblobが補完され、ブロブを含まないクローンが完全なクローンになります。\n\n\n    ```shell\n\n    $ git cat-file --batch-all-objects --batch-check='%(objecttype)' | sort |\n    uniq -c\n\n    \\ 148031 blob\n\n    \\  83977 commit\n\n    \\ 161927 tree\n\n    ```\n\n\n    この[プロジェクト](https://lore.kernel.org/git/pull.1820.v3.git.1738602667.gitgitga\\\n    dget@gmail.com/)は[Derrick\n    Stolee](https://stolee.dev/)によって主導され、[e565f37553](https://gitlab.com/gitlab\\\n    -org/git/-/commit/e565f3755342caf1d21e22359eaf09ec11d8c0ae)でマージされました。\n\n\n    ## zlib-ngの導入\n\n\n    `.git/`フォルダ内のすべてのオブジェクトは、Gitによって[`zlib`](https://zlib.net/)を使って圧縮されています。`zl\\\n    ib`は[RFC\n\n    1950](https://datatracker.ietf.org/doc/html/rfc1950)（ZLIB圧縮データフォーマット）のリファレン\\\n    ス実装であり、1995年に作られました。`zlib`は長い歴史を持ち、非常に高い移植性があり、\n\n    インターネット以前の多くのシステムもサポートしています。このように幅広いアーキテクチャやコンパイラをサポートしている一方で、\n\n    zlibには機能面での制限もあります。\n\n\n    その制限に対応するために生まれたのが[`zlib-ng`](https://github.com/zlib-ng/zlib-ng)というフォークです。\n\n    `zlib-ng`は、現代的なシステム向けに最適化されることを目指しており、レガシーシステムのサポートを廃止する代わりに、\n\n    Intel向けの最適化パッチや、Cloudflareによる最適化、その他いくつかの小規模なパッチが取り込まれています。\n\n\n    `zlib-ng`ライブラリ自体は`zlib`との互換レイヤーを提供しており、この互換性により、`zlib-ng`を`zlib`の代替としてそのまま差\\\n    し替えて使うことが可能です。\n\n    ただし、この互換レイヤーはすべてのLinuxディストリビューションで利用できるわけではありません。Git 2.49では以下の変更が加えられました。\n\n\n    - Gitプロジェクトへのzlib-ng互換レイヤーの追加\n\n    -\n    [`Makefile`](https://gitlab.com/gitlab-org/git/-/blob/b9d6f64393275b505937a\\\n    8621a6cc4875adde8e0/Makefile#L186-187)および[Mesonビルドファイル](https://gitlab.com/\\\n    gitlab-org/git/-/blob/b9d6f64393275b505937a8621a6cc4875adde8e0/meson.build#\\\n    L795-811)へのビルドオプションの追加\n\n\n    これらの追加により、`zlib-ng`によるパフォーマンス向上の恩恵を受けやすくなりました。\n\n\n    ローカルでのベンチマークでは、`zlib`ではなく`zlib-ng`を使用することで約25%の高速化が確認されています。現在、これらの変更をGitLa\\\n    b.comにも順次導入中です。\n\n\n    `zlib-ng`によるパフォーマンス向上の恩恵を受けたい場合は、まず`git version\n    --build-options`コマンドを実行して、お使いのマシンでGitがすでに`zlib-ng`を使用しているかどうかを確認してください。\n\n\n    ```shell\n\n    $ git version --build-options\n\n    git version 2.47.1\n\n    cpu: x86_64\n\n    no commit associated with this build\n\n    sizeof-long: 8\n\n    sizeof-size_t: 8\n\n    shell-path: /bin/sh\n\n    libcurl: 8.6.0\n\n    OpenSSL: OpenSSL 3.2.2 4 Jun 2024\n\n    zlib: 1.3.1.zlib-ng\n\n    ```\n\n\n    出力の一番下の行に`zlib-ng`と表示されていれば、すでにGitは高速な`zlib`のバリアントでビルドされています。表示されていない場合は、以下\\\n    のいずれかの方法で対応できます。\n\n\n    - お使いのGitパッケージのメンテナーに、`zlib-ng`のサポートを有効にしてもらうよう依頼する\n\n    - Gitをソースコードから自分でビルドする\n\n\n    なお、これらの[変更](https://gitlab.com/gitlab-org/git/-/commit/9d0e81e2ae3bd7f6d8a6\\\n    55be53c2396d7af3d2b0)\n\n    は[Patrick\n    Steinhardt](https://gitlab.com/pks-gitlab)によって[導入](https://lore.kernel.org/\\\n    git/20250128-b4-pks-compat-drop-uncompress2-v4-0-129bc36ae8f5@pks.im/)されました。\n\n\n    ## Mesonの継続的なイテレーション\n\n\n    Git\n    2.48のリリースについて紹介した記事では、[Mesonビルドシステムの導入](https://about.gitlab.com/ja-jp/blog\\\n    /whats-new-in-git-2-48-0/#meson%E3%83%93%E3%83%AB%E3%83%89%E3%82%B7%E3%82%B\\\n    9%E3%83%86%E3%83%A0)について触れました。[Meson](https://ja.wikipedia.org/wiki/Meson_(\\\n    %E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2))は、Gitプロジェクトで使用されるビル\\\n    ド自動化ツールで、将来的には[Autoconf](https://ja.wikipedia.org/wiki/Autoconf),\n\n    [CMake](https://ja.wikipedia.org/wiki/CMake)さらには\n\n    [Make](https://ja.wikipedia.org/wiki/Make_(UNIX))に取って代わる可能性もあります。\n\n\n    今回のリリースサイクルでも、Mesonの利用に関する作業が引き続き進められ、不足していた機能の追加や安定性向上のための以下の修正が行われました。\n\n\n    \\  -\n    [CIのテストカバレッジ改善](https://lore.kernel.org/git/20250122-b4-pks-meson-additions\\\n    -v3-0-5a51eb5d3dcd@pks.im/)が、コミット[72f1ddfbc9](https://gitlab.com/gitlab-org\\\n    /git/-/commit/72f1ddfbc95b47c6011bb423e6947418d1d72709)でマージされました\n\n    -\n    [`contrib/`ディレクトリでMesonを使えるようにする作業の一部](https://lore.kernel.org/git/20250219\\\n    -b4-pks-meson-contrib-v2-0-1ba5d7fde0b9@pks.im/)が、コミット[2a1530a953](https://\\\n    gitlab.com/gitlab-org/git/-/commit/2a1530a953cc4d2ae62416db86c545c7ccb73ace\\\n    )でマージされました\n\n    \\  -\n    [Mesonベースのビルド手順に関する修正や改善](https://lore.kernel.org/git/20250226-b4-pks-meson\\\n    -improvements-v3-0-60c77cf673ae@pks.im/)が、コミット[ab09eddf60](https://gitlab.c\\\n    om/gitlab-org/git/-/commit/ab09eddf601501290b5c719574fbe6c02314631f)でマージされま\\\n    した\n\n    \\  -\n    [git-subtree(1)のビルドにMesonを対応させる変更](https://lore.kernel.org/git/20250117-b4-\\\n    pks-build-subtree-v1-0-03c2ed6cc42e@pks.im/)が、コミット[3ddeb7f337](https://gitl\\\n    ab.com/gitlab-org/git/-/commit/3ddeb7f3373ae0e309d9df62ada24375afa456c7)でマー\\\n    ジされました\n\n    \\  -\n    [MesonにHTMLドキュメントページの生成を学習させる変更](https://lore.kernel.org/git/20241227-b4-pk\\\n    s-meson-docs-v2-0-f61e63edbfa1@pks.im/)が、コミット[1b4e9a5f8b](https://gitlab.co\\\n    m/gitlab-org/git/-/commit/1b4e9a5f8b5f048972c21fe8acafe0404096f694)でマージされました\n\n\n    これらの作業はすべて[Patrick Steinhardt](https://gitlab.com/pks-gitlab)によって行われました。\n\n\n    ## .git/branches/および.git/remotes/の非推奨化\n\n\n    おそらく、 `.git`ディレクトリやその中身についてはご存じかと思います。\n\n    しかし、 `.git/branches/`や`.git/remotes/`というサブディレクトリの存在についてはどうでしょうか？\n\n    ご存じの通り、ブランチへの参照は`.git/refs/heads/`に保存されているため、`.git/branches/`はそのための場所ではありませ\\\n    ん。そして、`.git/remotes/`の用途は何でしょうか？\n\n\n    2005年、[`.git/branches/`](https://git-scm.com/docs/git-fetch#_named_file_in_\\\n    git_dirbranches)はリモートの短縮名を保存するために導入されました。そしてその数か月後に、それらは[`.git/remotes/`](h\\\n    ttps://git-scm.com/docs/git-fetch#_named_file_in_git_dirremotes)に移動されました。\n\n    [2006年](https://lore.kernel.org/git/Pine.LNX.4.63.0604301520460.2646@wbgn01\\\n    3.biozentrum.uni-wuerzburg.de/)には、[`git-config(1)`](https://git-scm.com/doc\\\n    s/git-config)に[リモート](https://git-scm.com/docs/git-config#Documentation/git-\\\n    config.txt-remoteltnamegturl)設定を保存する機能が追加され、\n\n    これがリモートを設定する標準的な方法として定着しました。\n\n    その後2011年には、`.git/branches/`と`.git/remotes/`は「レガシー」であることが[文書化](https://gitla\\\n    b.com/git-scm/git/-/commit/3d3d282146e13f2d7f055ad056956fd8e5d7ed29#e615263\\\n    aaf131d42be8b0d0888ebd3fec954c6c9_132_124)され、現代のリポジトリでは使用されなくなりました。\n\n\n    そして2024年、Gitの次のメジャーバージョン（v3.0）の破壊的な変更の概要をまとめるドキュメント[破壊的な変更](https://git-scm\\\n    .com/docs/BreakingChanges)が作成されました。\n\n    このリリースはすぐに行われる予定はありませんが、このドキュメントにはそのリリースに含まれると予想される変更点について記載されています。\n\n    コミット[8ccc75c245](https://gitlab.com/git-scm/git/-/commit/8ccc75c2452b5814d2\\\n    445d60d54266293ca48674)では、`.git/branches/`および`.git/remotes/`ディレクトリの使用に関する内容\\\n    がこのドキュメントに追加され、これにより公式に非推奨とされ、Git 3.0で削除予定であることが明示されました。\n\n\n    [この非推奨化を正式に文書化](https://lore.kernel.org/git/20250122-pks-remote-branches-de\\\n    precation-v4-5-5cbf5b28afd5@pks.im/)した[Patrick\n    Steinhardt](https://gitlab.com/pks-gitlab)に感謝します。\n\n\n    ## libgitに対するRustバインディング\n\n\n    Gitをコンパイルすると、内部ライブラリ`libgit.a`が生成されます。このライブラリには、Gitの中核となる機能の一部が含まれています。\n\n\n    このライブラリ（およびGitの大部分）はC言語で書かれていますが、Git\n    2.49では一部の関数をRustから使えるようにするためのバインディングが追加されました。この実現のために、2つの新しいCargoパッケージ、`lib\\\n    git-sys`と`libgit-rs`が作成されました。これらのパッケージは、GitのSourceTree内の[`contrib/`](https:\\\n    //gitlab.com/gitlab-org/git/-/tree/master/contrib)サブディレクトリに配置されています。\n\n\n    [他言語関数インターフェイス](https://ja.wikipedia.org/wiki/Foreign_function_interface)を使\\\n    う場合、ライブラリを2つのパッケージに分けるのは[一般的](https://doc.rust-lang.org/cargo/reference/bui\\\n    ld-scripts.html#-sys-packages)な手法です。\n\n    `libgit-sys`パッケージは、C関数への純粋なインターフェースを提供し、ネイティブの`libgit.a`にリンクします。一方、`libgit-\\\n    rs`パッケージは、`libgit-sys`の関数をRustらしいスタイルで扱える高レベルなインターフェースを提供します。\n\n\n    現時点では、これらのRustパッケージで使える機能は非常に限定的で、対応しているのは`git-config(1)`とやり取りするためのインターフェース\\\n    のみです。\n\n\n    この取り組みは[Josh\n    Steadmon](https://lore.kernel.org/git/8793ff64a7f6c4c04dd03b71162a85849feda\\\n    944.1738187176.git.steadmon@google.com/)さんによって主導され、コミット[a4af0b6288](https:/\\\n    /gitlab.com/gitlab-org/git/-/commit/a4af0b6288e25eb327ae9018cee09def9e43f1c\\\n    d)でマージされました。\n\n\n    ## 新しい名前ハッシュアルゴリズム\n\n\n    `.git/`にあるGitのオブジェクトデータベースは、その大部分のデータを\n    パックファイルに保存しています。また、このパックファイルは、Gitのサーバーとクライアント間でオブジェクトをやり取りする際にも使われます。\n\n\n    パックファイルのフォーマットについては、[`gitformat-pack(5)`](https://git-scm.com/docs/gitforma\\\n    t-pack)に詳しく書かれていますが、その中でも重要なのが差分圧縮です。差分圧縮では、すべてのオブジェクトがそのまま保存されるわけではなく、一部のオ\\\n    ブジェクトは他のオブジェクトとの_差分_として保存されます。つまり、オブジェクトの内容全体を保存するのではなく、他のオブジェクトと比較した変更点だけを\\\n    記録します。\n\n\n    差分の計算や保存方法についてはここでは詳しく触れませんが、\n\n    非常に似ているファイルをグループ化しておくことが重要なのは想像できるかと思います。Git\n    v2.48以前では、Gitは「ファイルパスの最後の16文字」をもとに、blobが似ているかどうかを判断していました。このアルゴリズムはバージョン`1`\\\n    と呼ばれています。\n\n\n    Git\n    2.49では、バージョン`2`のアルゴリズムが追加されました。これはバージョン`1`のイテレーションで、親ディレクトリの影響を減らすように調整されたバ\\\n    ージョンです。どちらのアルゴリズムを使用するかは、[`git-repack(1)`](https://git-scm.com/docs/git-rep\\\n    ack)の`--name-hash-version`オプションで指定できます。\n\n\n    以下は、このプロジェクトを推進した[Derrick Stolee](https://stolee.dev/)さんによる、`git repack -adf\n    --name-hash-version=\u003Cn>`を実行した際のパックファイルサイズの比較です。\n\n\n    | リポジトリ                                          \\t| バージョン1のサイズ   |\n    バージョン2のサイズ |\n\n    |---------------------------------------------------|-----------|---------|\n\n    | [fluentui](https://github.com/microsoft/fluentui) | 440 MB \\t| 161 MB   |\n\n    | Repo B                                        \\t| 6,248 MB   | 856 MB   |\n\n    | Repo C                                        \\t| 37,278 MB  | 6,921 MB |\n\n    | Repo D                                        \\t| 131,204 MB | 7,463 MB |\n\n\n    この件に関する詳細は、コミット[aae91a86fb](https://gitlab.com/gitlab-org/git/-/commit/aae9\\\n    1a86fb2a71ff89a71b63ccec3a947b26ca51)にマージされた[パッチセット](https://lore.kernel.or\\\n    g/git/pull.1823.v4.git.1738004554.gitgitgadget@gmail.com/)にて確認できます。\n\n\n    ## プロミサーリモート機能\n\n\n    Gitが大きなファイルを扱うのに向いていないことは、よく知られています。この問題に対する解決策として、[Git\n    LFS](https://git-lfs.com/)のようなツールがありますが、依然として以下のような欠点が残っています。\n\n\n    - Git\n    LFSでは、どのファイルをLFSに入れるかをユーザーが自分で設定する必要があり、サーバー側ではそれについて制御できず、すべてのファイルを提供する必要が\\\n    あります。\n\n    -\n    リポジトリにファイルがコミットされると、履歴を書き換えない限り、それを取り除く方法がありません。これは特に大きなファイルでは厄介で、一度入れると永遠に\\\n    残ってしまいます。\n\n    - ユーザーは、Git LFSに入れるファイルを後から変更することはできません。\n\n    - Git LFS のようなツールは、導入・学習・運用すべてにそれなりの労力が必要です。\n\n\n    以前からGitにはプロミサーリモートという概念が存在しており、この機能を大きなファイルに対処するための手段として利用できます。そしてGit\n    2.49では、この機能がさらに一歩前進しました。\n\n\n    新しい「プロミサーリモート」機能の考え方は比較的シンプルです。Gitサーバーがすべてのオブジェクトを自ら送信する代わりに、「これらのオブジェクトは_X\\\n    YZ_からダウンロードしてね」とGitクライアントに伝えます。この_XYZ_がプロミサーリモートです。\n\n\n    Git\n    2.49では、サーバーがプロミサーリモートの情報をクライアントに通知できるようになりました。この変更は、[`gitprotocol-v2`](http\\\n    s://git-scm.com/docs/gitprotocol-v2)の拡張として行われています。サーバーとクライアントがデータを送受信している間に\\\n    、サーバーは自分が知っているプロミサーリモートの名前やURLをクライアントに送信します。\n\n\n    現時点では、Gitクライアントはクローン時にサーバーから受け取ったプロミサーリモートの情報をまだ利用していません。つまり、今のところは、クローン元のリ\\\n    モートからすべてのオブジェクトを取得しています。しかし今後は、サーバーから受け取ったプロミサーリモート情報を活用できるように開発を進め、より簡単に使え\\\n    る仕組みにしていく予定です。\n\n\n    この[パッチセット](https://lore.kernel.org/git/20250218113204.2847463-1-christian.c\\\n    ouder@gmail.com/)は[Christian\n    Couder](https://gitlab.com/chriscool)さんによって提出され、コミット[2c6fd30198](https://gi\\\n    tlab.com/gitlab-org/git/-/commit/2c6fd30198187c928cbf927802556908c381799c)で\\\n    マージされました。\n\n\n    ## `--revision`を使用した軽量なクローン\n\n\n    [`git-clone(1)`](https://git-scm.com/docs/git-clone)に新しく`--revision`オプションが追\\\n    加されました。このオプションを使うことで、指定されたリビジョンの履歴のみを含む、軽量なクローンを作成できます。このオプションは`--branch`に似\\\n    ていますが、`refs/heads/main`、`refs/tags/v1.0`、`refs/merge-requests/123`のような\n    リファレンス名や、16進数のコミットオブジェクトIDを受け取る点が異なります。`--branch`との違いは、このオプションでは追跡ブランチが作られず\\\n    、`HEAD`がデタッチ状態になる点です。そのため、このクローンを使ってブランチにコントリビュートするといった用途には向いていません。\n\n\n    `--revision`と`--depth`を組み合わせて使うことで、非常にミニマルなクローンを作成できます。おすすめの用途は、自動テストです。たとえ\\\n    ば、CIシステムが特定のブランチ（またはリファレンス）をチェックアウトして、ソースコードのテストを行うだけでいい場合、この最小限のクローンで十分です。\n\n\n    この[変更](https://gitlab.com/gitlab-org/git/-/commit/5785d9143bcb3ef19452a83bc\\\n    2e870ff3d5ed95a)は[Toon\n    Claes](https://gitlab.com/toon)さんによって[推進](https://lore.kernel.org/git/20250\\\n    206-toon-clone-refs-v7-0-4622b7392202@iotcl.com/)されました。\n\n\n    # もっと詳しく\n\n    - [Git\n    2.48.0の新機能](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-48-0/)\n\n    - [Git 2.47.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-47-0/)\n\n    - [Git 2.46.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-46-0/)\"\n  category: open-source\n  tags:\n    - community\n    - open source\n    - git\nconfig:\n  slug: whats-new-in-git-2-49-0\n  featured: true\n  template: BlogPost\n",{"title":5,"description":17,"ogTitle":5,"ogDescription":17,"noIndex":31,"ogImage":19,"ogUrl":32,"ogSiteName":33,"ogType":34,"canonicalUrls":32},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",[22,11,24],[22,23,24],"UBe_cAu-PG9d0PE56mXlQipRBOceXKu8RUTsWrHt-C4",{"data":40},{"logo":41,"freeTrial":46,"sales":51,"login":56,"items":61,"search":369,"minimal":402,"duo":419,"switchNav":428,"pricingDeployment":439},{"config":42},{"href":43,"dataGaName":44,"dataGaLocation":45},"/ja-jp/","gitlab logo","header",{"text":47,"config":48},"無料トライアルを開始",{"href":49,"dataGaName":50,"dataGaLocation":45},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp&glm_content=default-saas-trial/","free trial",{"text":52,"config":53},"お問い合わせ",{"href":54,"dataGaName":55,"dataGaLocation":45},"/ja-jp/sales/","sales",{"text":57,"config":58},"サインイン",{"href":59,"dataGaName":60,"dataGaLocation":45},"https://gitlab.com/users/sign_in/","sign in",[62,89,186,191,291,351],{"text":63,"config":64,"cards":66},"プラットフォーム",{"dataNavLevelOne":65},"platform",[67,73,81],{"title":63,"description":68,"link":69},"DevSecOpsに特化したインテリジェントオーケストレーションプラットフォーム",{"text":70,"config":71},"プラットフォームを探索",{"href":72,"dataGaName":65,"dataGaLocation":45},"/ja-jp/platform/",{"title":74,"description":75,"link":76},"GitLab Duo Agent Platform","ソフトウェアライフサイクル全体を支えるエージェント型AI",{"text":77,"config":78},"GitLab Duoのご紹介",{"href":79,"dataGaName":80,"dataGaLocation":45},"/ja-jp/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":82,"description":83,"link":84},"GitLabが選ばれる理由","エンタープライズがGitLabを選ぶ主な理由をご覧ください",{"text":85,"config":86},"詳細はこちら",{"href":87,"dataGaName":88,"dataGaLocation":45},"/ja-jp/why-gitlab/","why gitlab",{"text":90,"left":14,"config":91,"link":93,"lists":97,"footer":168},"製品",{"dataNavLevelOne":92},"solutions",{"text":94,"config":95},"すべてのソリューションを表示",{"href":96,"dataGaName":92,"dataGaLocation":45},"/ja-jp/solutions/",[98,123,146],{"title":99,"description":100,"link":101,"items":106},"自動化","CI/CDと自動化でデプロイを加速",{"config":102},{"icon":103,"href":104,"dataGaName":105,"dataGaLocation":45},"AutomatedCodeAlt","/ja-jp/solutions/delivery-automation/","automated software delivery",[107,111,114,119],{"text":108,"config":109},"CI/CD",{"href":110,"dataGaLocation":45,"dataGaName":108},"/ja-jp/solutions/continuous-integration/",{"text":74,"config":112},{"href":79,"dataGaLocation":45,"dataGaName":113},"gitlab duo agent platform - product menu",{"text":115,"config":116},"ソースコード管理",{"href":117,"dataGaLocation":45,"dataGaName":118},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":120,"config":121},"自動化されたソフトウェアデリバリー",{"href":104,"dataGaLocation":45,"dataGaName":122},"Automated software delivery",{"title":124,"description":125,"link":126,"items":131},"セキュリティ","セキュリティを犠牲にすることなくコード作成を高速化",{"config":127},{"href":128,"dataGaName":129,"dataGaLocation":45,"icon":130},"/ja-jp/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[132,136,141],{"text":133,"config":134},"アプリケーションセキュリティテスト",{"href":128,"dataGaName":135,"dataGaLocation":45},"Application security testing",{"text":137,"config":138},"ソフトウェアサプライチェーンの安全性",{"href":139,"dataGaLocation":45,"dataGaName":140},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":142,"config":143},"ソフトウェアコンプライアンス",{"href":144,"dataGaName":145,"dataGaLocation":45},"/ja-jp/solutions/software-compliance/","software compliance",{"title":147,"link":148,"items":153},"測定",{"config":149},{"icon":150,"href":151,"dataGaName":152,"dataGaLocation":45},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[154,158,163],{"text":155,"config":156},"可視性と測定",{"href":151,"dataGaLocation":45,"dataGaName":157},"Visibility and Measurement",{"text":159,"config":160},"バリューストリーム管理",{"href":161,"dataGaLocation":45,"dataGaName":162},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":164,"config":165},"分析とインサイト",{"href":166,"dataGaLocation":45,"dataGaName":167},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":169,"items":170},"GitLabが活躍する場所",[171,176,181],{"text":172,"config":173},"大企業",{"href":174,"dataGaLocation":45,"dataGaName":175},"/ja-jp/enterprise/","enterprise",{"text":177,"config":178},"スモールビジネス",{"href":179,"dataGaLocation":45,"dataGaName":180},"/ja-jp/small-business/","small business",{"text":182,"config":183},"公共部門",{"href":184,"dataGaLocation":45,"dataGaName":185},"/ja-jp/solutions/public-sector/","public sector",{"text":187,"config":188},"価格",{"href":189,"dataGaName":190,"dataGaLocation":45,"dataNavLevelOne":190},"/ja-jp/pricing/","pricing",{"text":192,"config":193,"link":195,"lists":199,"feature":278},"リソース",{"dataNavLevelOne":194},"resources",{"text":196,"config":197},"すべてのリソースを表示",{"href":198,"dataGaName":194,"dataGaLocation":45},"/ja-jp/resources/",[200,233,251],{"title":201,"items":202},"はじめに",[203,208,213,218,223,228],{"text":204,"config":205},"インストール",{"href":206,"dataGaName":207,"dataGaLocation":45},"/ja-jp/install/","install",{"text":209,"config":210},"クイックスタートガイド",{"href":211,"dataGaName":212,"dataGaLocation":45},"/ja-jp/get-started/","quick setup checklists",{"text":214,"config":215},"学ぶ",{"href":216,"dataGaLocation":45,"dataGaName":217},"https://university.gitlab.com/","learn",{"text":219,"config":220},"製品ドキュメント",{"href":221,"dataGaName":222,"dataGaLocation":45},"https://docs.gitlab.com/ja-jp/","product documentation",{"text":224,"config":225},"ベストプラクティスビデオ",{"href":226,"dataGaName":227,"dataGaLocation":45},"/ja-jp/getting-started-videos/","best practice videos",{"text":229,"config":230},"インテグレーション",{"href":231,"dataGaName":232,"dataGaLocation":45},"/ja-jp/integrations/","integrations",{"title":234,"items":235},"検索する",[236,241,246],{"text":237,"config":238},"お客様成功事例",{"href":239,"dataGaName":240,"dataGaLocation":45},"/ja-jp/customers/","customer success stories",{"text":242,"config":243},"ブログ",{"href":244,"dataGaName":245,"dataGaLocation":45},"/ja-jp/blog/","blog",{"text":247,"config":248},"リモート",{"href":249,"dataGaName":250,"dataGaLocation":45},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":252,"items":253},"つなげる",[254,259,263,268,273],{"text":255,"config":256},"GitLabサービス",{"href":257,"dataGaName":258,"dataGaLocation":45},"/ja-jp/services/","services",{"text":260,"config":261},"コミュニティ",{"href":262,"dataGaName":22,"dataGaLocation":45},"/community/",{"text":264,"config":265},"フォーラム",{"href":266,"dataGaName":267,"dataGaLocation":45},"https://forum.gitlab.com/","forum",{"text":269,"config":270},"イベント",{"href":271,"dataGaName":272,"dataGaLocation":45},"/events/","events",{"text":274,"config":275},"パートナー",{"href":276,"dataGaName":277,"dataGaLocation":45},"/ja-jp/partners/","partners",{"background":279,"textColor":280,"text":281,"image":282,"link":286},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":283,"config":284},"ソースプロモカード",{"src":285},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":287,"config":288},"最新情報を読む",{"href":289,"dataGaName":290,"dataGaLocation":45},"/ja-jp/the-source/","the source",{"text":292,"config":293,"lists":295},"会社情報",{"dataNavLevelOne":294},"company",[296],{"items":297},[298,303,309,311,316,321,326,331,336,341,346],{"text":299,"config":300},"GitLabについて",{"href":301,"dataGaName":302,"dataGaLocation":45},"/ja-jp/company/","about",{"text":304,"config":305,"footerGa":308},"採用情報",{"href":306,"dataGaName":307,"dataGaLocation":45},"/jobs/","jobs",{"dataGaName":307},{"text":269,"config":310},{"href":271,"dataGaName":272,"dataGaLocation":45},{"text":312,"config":313},"経営陣",{"href":314,"dataGaName":315,"dataGaLocation":45},"/company/team/e-group/","leadership",{"text":317,"config":318},"チーム",{"href":319,"dataGaName":320,"dataGaLocation":45},"/company/team/","team",{"text":322,"config":323},"ハンドブック",{"href":324,"dataGaName":325,"dataGaLocation":45},"https://handbook.gitlab.com/","handbook",{"text":327,"config":328},"投資家向け情報",{"href":329,"dataGaName":330,"dataGaLocation":45},"https://ir.gitlab.com/","investor relations",{"text":332,"config":333},"トラストセンター",{"href":334,"dataGaName":335,"dataGaLocation":45},"/ja-jp/security/","trust center",{"text":337,"config":338},"AI Transparency Center",{"href":339,"dataGaName":340,"dataGaLocation":45},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":342,"config":343},"ニュースレター",{"href":344,"dataGaName":345,"dataGaLocation":45},"/company/contact/#contact-forms","newsletter",{"text":347,"config":348},"プレス",{"href":349,"dataGaName":350,"dataGaLocation":45},"/press/","press",{"text":52,"config":352,"lists":353},{"dataNavLevelOne":294},[354],{"items":355},[356,359,364],{"text":52,"config":357},{"href":54,"dataGaName":358,"dataGaLocation":45},"talk to sales",{"text":360,"config":361},"サポートを受ける",{"href":362,"dataGaName":363,"dataGaLocation":45},"https://support.gitlab.com","support portal",{"text":365,"config":366},"カスタマーポータル",{"href":367,"dataGaName":368,"dataGaLocation":45},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":370,"login":371,"suggestions":378},"閉じる",{"text":372,"link":373},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":374,"config":375},"GitLab.com",{"href":59,"dataGaName":376,"dataGaLocation":377},"search login","search",{"text":379,"default":380},"提案",[381,383,388,390,394,398],{"text":74,"config":382},{"href":79,"dataGaName":74,"dataGaLocation":377},{"text":384,"config":385},"コード提案（AI）",{"href":386,"dataGaName":387,"dataGaLocation":377},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":108,"config":389},{"href":110,"dataGaName":108,"dataGaLocation":377},{"text":391,"config":392},"GitLab on AWS",{"href":393,"dataGaName":391,"dataGaLocation":377},"/ja-jp/partners/technology-partners/aws/",{"text":395,"config":396},"GitLab on Google Cloud",{"href":397,"dataGaName":395,"dataGaLocation":377},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":399,"config":400},"GitLabを選ぶ理由",{"href":87,"dataGaName":401,"dataGaLocation":377},"Why GitLab?",{"freeTrial":403,"mobileIcon":407,"desktopIcon":412,"secondaryButton":415},{"text":47,"config":404},{"href":405,"dataGaName":50,"dataGaLocation":406},"https://gitlab.com/-/trials/new/","nav",{"altText":408,"config":409},"GitLabアイコン",{"src":410,"dataGaName":411,"dataGaLocation":406},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":408,"config":413},{"src":414,"dataGaName":411,"dataGaLocation":406},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":201,"config":416},{"href":417,"dataGaName":418,"dataGaLocation":406},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/get-started/","get started",{"freeTrial":420,"mobileIcon":424,"desktopIcon":426},{"text":421,"config":422},"GitLab Duoの詳細について",{"href":79,"dataGaName":423,"dataGaLocation":406},"gitlab duo",{"altText":408,"config":425},{"src":410,"dataGaName":411,"dataGaLocation":406},{"altText":408,"config":427},{"src":414,"dataGaName":411,"dataGaLocation":406},{"button":429,"mobileIcon":434,"desktopIcon":436},{"text":430,"config":431},"/switch",{"href":432,"dataGaName":433,"dataGaLocation":406},"#contact","switch",{"altText":408,"config":435},{"src":410,"dataGaName":411,"dataGaLocation":406},{"altText":408,"config":437},{"src":438,"dataGaName":411,"dataGaLocation":406},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":440,"mobileIcon":445,"desktopIcon":447},{"text":441,"config":442},"料金ページに戻る",{"href":189,"dataGaName":443,"dataGaLocation":406,"icon":444},"back to pricing","GoBack",{"altText":408,"config":446},{"src":410,"dataGaName":411,"dataGaLocation":406},{"altText":408,"config":448},{"src":414,"dataGaName":411,"dataGaLocation":406},{"title":450,"button":451,"config":456},"エージェント型AIがソフトウェア配信をどのように変革するかをご覧ください",{"text":452,"config":453},"GitLab Transcendを今すぐ視聴",{"href":454,"dataGaName":455,"dataGaLocation":45},"/ja-jp/events/transcend/virtual/","transcend event",{"layout":457,"icon":458,"disabled":14},"release","AiStar",{"data":460},{"text":461,"source":462,"edit":468,"contribute":473,"config":478,"items":483,"minimal":686},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":463,"config":464},"ページのソースを表示",{"href":465,"dataGaName":466,"dataGaLocation":467},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":469,"config":470},"このページを編集",{"href":471,"dataGaName":472,"dataGaLocation":467},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":474,"config":475},"ご協力をお願いします",{"href":476,"dataGaName":477,"dataGaLocation":467},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":479,"facebook":480,"youtube":481,"linkedin":482},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[484,529,582,625,652],{"title":187,"links":485,"subMenu":500},[486,490,495],{"text":487,"config":488},"プランの表示",{"href":189,"dataGaName":489,"dataGaLocation":467},"view plans",{"text":491,"config":492},"Premiumを選ぶ理由",{"href":493,"dataGaName":494,"dataGaLocation":467},"/ja-jp/pricing/premium/","why premium",{"text":496,"config":497},"Ultimateを選ぶ理由",{"href":498,"dataGaName":499,"dataGaLocation":467},"/ja-jp/pricing/ultimate/","why ultimate",[501],{"title":52,"links":502},[503,505,507,509,514,519,524],{"text":52,"config":504},{"href":54,"dataGaName":55,"dataGaLocation":467},{"text":360,"config":506},{"href":362,"dataGaName":363,"dataGaLocation":467},{"text":365,"config":508},{"href":367,"dataGaName":368,"dataGaLocation":467},{"text":510,"config":511},"ステータス",{"href":512,"dataGaName":513,"dataGaLocation":467},"https://status.gitlab.com/","status",{"text":515,"config":516},"利用規約",{"href":517,"dataGaName":518,"dataGaLocation":467},"/terms/","terms of use",{"text":520,"config":521},"プライバシーに関する声明",{"href":522,"dataGaName":523,"dataGaLocation":467},"/ja-jp/privacy/","privacy statement",{"text":525,"config":526},"Cookie 優先設定",{"dataGaName":527,"dataGaLocation":467,"id":528,"isOneTrustButton":14},"cookie preferences","ot-sdk-btn",{"title":90,"links":530,"subMenu":539},[531,535],{"text":532,"config":533},"DevSecOpsプラットフォーム",{"href":72,"dataGaName":534,"dataGaLocation":467},"devsecops platform",{"text":536,"config":537},"AI支援開発",{"href":79,"dataGaName":538,"dataGaLocation":467},"ai-assisted development",[540],{"title":541,"links":542},"トピック",[543,547,552,557,562,567,572,577],{"text":108,"config":544},{"href":545,"dataGaName":546,"dataGaLocation":467},"/ja-jp/topics/ci-cd/","cicd",{"text":548,"config":549},"GitOps",{"href":550,"dataGaName":551,"dataGaLocation":467},"/ja-jp/topics/gitops/","gitops",{"text":553,"config":554},"DevOps",{"href":555,"dataGaName":556,"dataGaLocation":467},"/ja-jp/topics/devops/","devops",{"text":558,"config":559},"バージョン管理",{"href":560,"dataGaName":561,"dataGaLocation":467},"/ja-jp/topics/version-control/","version control",{"text":563,"config":564},"DevSecOps",{"href":565,"dataGaName":566,"dataGaLocation":467},"/ja-jp/topics/devsecops/","devsecops",{"text":568,"config":569},"クラウドネイティブ",{"href":570,"dataGaName":571,"dataGaLocation":467},"/ja-jp/topics/cloud-native/","cloud native",{"text":573,"config":574},"コーディングのためのAI",{"href":575,"dataGaName":576,"dataGaLocation":467},"/ja-jp/topics/devops/ai-for-coding/","ai for coding",{"text":578,"config":579},"エージェント型AI",{"href":580,"dataGaName":581,"dataGaLocation":467},"/ja-jp/topics/agentic-ai/","agentic ai",{"title":583,"links":584},"ソリューション",[585,588,590,595,599,602,605,608,610,612,615,620],{"text":133,"config":586},{"href":128,"dataGaName":587,"dataGaLocation":467},"Application Security Testing",{"text":120,"config":589},{"href":104,"dataGaName":105,"dataGaLocation":467},{"text":591,"config":592},"アジャイル開発",{"href":593,"dataGaName":594,"dataGaLocation":467},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":596,"config":597},"SCM",{"href":117,"dataGaName":598,"dataGaLocation":467},"source code management",{"text":108,"config":600},{"href":110,"dataGaName":601,"dataGaLocation":467},"continuous integration & delivery",{"text":159,"config":603},{"href":161,"dataGaName":604,"dataGaLocation":467},"value stream management",{"text":548,"config":606},{"href":607,"dataGaName":551,"dataGaLocation":467},"/ja-jp/solutions/gitops/",{"text":172,"config":609},{"href":174,"dataGaName":175,"dataGaLocation":467},{"text":177,"config":611},{"href":179,"dataGaName":180,"dataGaLocation":467},{"text":613,"config":614},"公共機関",{"href":184,"dataGaName":185,"dataGaLocation":467},{"text":616,"config":617},"教育",{"href":618,"dataGaName":619,"dataGaLocation":467},"/ja-jp/solutions/education/","education",{"text":621,"config":622},"金融サービス",{"href":623,"dataGaName":624,"dataGaLocation":467},"/ja-jp/solutions/finance/","financial services",{"title":192,"links":626},[627,629,631,633,636,638,640,642,644,646,648,650],{"text":204,"config":628},{"href":206,"dataGaName":207,"dataGaLocation":467},{"text":209,"config":630},{"href":211,"dataGaName":212,"dataGaLocation":467},{"text":214,"config":632},{"href":216,"dataGaName":217,"dataGaLocation":467},{"text":219,"config":634},{"href":221,"dataGaName":635,"dataGaLocation":467},"docs",{"text":242,"config":637},{"href":244,"dataGaName":245,"dataGaLocation":467},{"text":237,"config":639},{"href":239,"dataGaName":240,"dataGaLocation":467},{"text":247,"config":641},{"href":249,"dataGaName":250,"dataGaLocation":467},{"text":255,"config":643},{"href":257,"dataGaName":258,"dataGaLocation":467},{"text":260,"config":645},{"href":262,"dataGaName":22,"dataGaLocation":467},{"text":264,"config":647},{"href":266,"dataGaName":267,"dataGaLocation":467},{"text":269,"config":649},{"href":271,"dataGaName":272,"dataGaLocation":467},{"text":274,"config":651},{"href":276,"dataGaName":277,"dataGaLocation":467},{"title":292,"links":653},[654,656,658,660,662,664,666,670,675,677,679,681],{"text":299,"config":655},{"href":301,"dataGaName":294,"dataGaLocation":467},{"text":304,"config":657},{"href":306,"dataGaName":307,"dataGaLocation":467},{"text":312,"config":659},{"href":314,"dataGaName":315,"dataGaLocation":467},{"text":317,"config":661},{"href":319,"dataGaName":320,"dataGaLocation":467},{"text":322,"config":663},{"href":324,"dataGaName":325,"dataGaLocation":467},{"text":327,"config":665},{"href":329,"dataGaName":330,"dataGaLocation":467},{"text":667,"config":668},"Sustainability",{"href":669,"dataGaName":667,"dataGaLocation":467},"/sustainability/",{"text":671,"config":672},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":673,"dataGaName":674,"dataGaLocation":467},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":332,"config":676},{"href":334,"dataGaName":335,"dataGaLocation":467},{"text":342,"config":678},{"href":344,"dataGaName":345,"dataGaLocation":467},{"text":347,"config":680},{"href":349,"dataGaName":350,"dataGaLocation":467},{"text":682,"config":683},"現代奴隷制の透明性に関する声明",{"href":684,"dataGaName":685,"dataGaLocation":467},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":687},[688,690,693],{"text":515,"config":689},{"href":517,"dataGaName":518,"dataGaLocation":467},{"text":691,"config":692},"Cookieの設定",{"dataGaName":527,"dataGaLocation":467,"id":528,"isOneTrustButton":14},{"text":520,"config":694},{"href":522,"dataGaName":523,"dataGaLocation":467},[696],{"id":697,"title":9,"body":26,"config":698,"content":700,"description":26,"extension":25,"meta":704,"navigation":14,"path":705,"seo":706,"stem":707,"__hash__":708},"blogAuthors/en-us/blog/authors/toon-claes.yml",{"template":699},"BlogAuthor",{"name":9,"config":701},{"headshot":702,"ctfId":703},"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",[710,724,739],{"content":711,"config":722},{"heroImage":712,"body":713,"authors":714,"updatedDate":716,"date":717,"title":718,"tags":719,"description":721,"category":11},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1776457632/llddiylsgwuze0u1rjks.png","AIがコードを書く時代になりました。それはもはや当然のことです。しかし、計画、セキュリティ、コンプライアンス、デプロイメントはどうでしょうか？これらの課題はまだ残っています。私はコントリビュータープログラムを長年運営してきましたが、コミュニティがこれほどまでにテクノロジーに反応するのを見たことがありませんでした。\n\nそこで私たちは[GitLab Duo Agent Platform](https://about.gitlab.com/ja-jp/gitlab-duo-agent-platform/)を開放し、世界中の開発者に対して、チームがより安全なソフトウェアを迅速にリリースできるAIエージェントの構築を呼びかけました。質問に答えるだけのチャットボットではなく、ワークフローに直接入り込み、イベントに反応し、ユーザーの代わりに行動するエージェントです。GitLab AIハッカソンは、2026年2月9日から3月25日まで、ハッカソンプラットフォームのDevpostで開催されました。Google CloudとAnthropicがコスポンサーとして参加しました。\n\nGoogle CloudおよびAnthropicとともにこのハッカソンを企画した際、私は審査員に4つの観点でスコアリングするよう依頼しました。技術的な完成度、デザイン、潜在的なインパクト、そしてアイデアの質です。参加者が多く集まることを期待していましたが、実際の結果は私たちの予想をはるかに上回るものでした。19名の審査員が18日間かけてすべてのエントリーを審査しました。Google CloudとAnthropicは審査員、賞品、クラウドアクセスを提供しました。コミュニティは、これらの課題を解決したいという思いから、数百ものエージェントとフローを構築したのです。\n\n約7,000人の開発者が参加し、数週間で600以上のエージェントとフローを構築しました。全カテゴリーの賞金総額は、GitLab、Google Cloud、Anthropicから合計65,000ドルに上りました。\n\nベテランエンジニアが退職してチームの知識の半分を持ち去っていくのを目の当たりにしたことがある方なら、なぜグランプリ受賞プロジェクトがこれほど刺さるのか、おわかりいただけるでしょう。\n\nコミュニティが何を作り上げたのか、ぜひご覧ください。\n\n## グランプリ：LORE\n\n[LORE](https://devpost.com/software/lore-living-organizational-record-engine)（Living Organizational Record Engine）は、各質問を適切なエージェントに振り分けるルーターを備えた8つのエージェント、ナレッジグラフ内の循環ループを防ぐロジック、ビジュアルダッシュボード、そしてカーボントラッキングで構成されています。コマンドラインツールには43のテストが付属しています（ハッカソンプロジェクトで43のテストとは、驚くべき数字です）。\n\nLOREが解決するのは、エンジニアの頭の中に蓄積された知識が、退職とともに失われてしまうというリアルな問題です。私の経験上、ハッカソンプロジェクトで43のテストを書くチームはほとんどいません。その数字が、このチームの本気度を物語っています。\n\n審査員のApril Guo氏（Anthropic）はこう記しました。「ハッカソンの作品というより、製品のような完成度です。」\n\n### Google Cloud賞受賞者\n\n[Gitdefender](https://devpost.com/software/gitdefender)がGoogle Cloudグランプリを受賞しました。コードレビューのワークフロー内でセキュリティ上の問題を発見・修正します。バグを検出し、修正を記述し、コードレビューを自動でオープンします。開発者が介入する必要はありません。\n\n[Aegis](https://devpost.com/software/aegis-2m1oq0)がGoogle Cloud準グランプリを受賞しました。すべての判断に対してAIによる説明を提供し、Google Cloudにデプロイされた本番環境にも対応しています。\n\n### Anthropic賞受賞者\n\n[GraphDev](https://devpost.com/software/graphdev)がAnthropicグランプリを受賞しました。コードの依存関係をマッピングし、システムが時間とともにどのように変化したかを可視化します。審査員のAboobacker MK氏（GitLab）は「GitLabのナレッジグラフに関する私たちの取り組みと方向性が一致している」と指摘しました。また審査員のAyush Billore氏（GitLab）は「デモとUXが素晴らしく、システムの変遷や変更による影響範囲を理解するうえで非常に有用です」と述べました。変更を加える前に、その全体的な影響を把握することができます。\n\n[DocSync](https://devpost.com/software/pipeheal)がAnthropicの準グランプリを受賞しました。Detector、Writer、Reviewerの3つのエージェントを使用します。DocSyncが修正に確信を持てる場合はコードレビューをオープンし、そうでない場合は人間が確認するためのイシューを作成します。\n\n## カテゴリー賞受賞者\n\n### 最も技術的に印象的な作品\n\nデータベースのマイグレーションは障害の原因になりがちです。[Time-Traveler](https://devpost.com/software/time-traveler-w3cxp0)は、本番環境のコピーを安全に作成し、そのコピーに対してマイグレーションを実行して結果を報告します。ブリッジで接続された5つのエージェントが動作し、Google Cloudへの実際のデプロイ、実際のPostgreSQLマイグレーション、そして実際のデータを使用します。\n\n### 最もインパクトのある作品\n\n[RedAgent](https://devpost.com/software/redagent)は、AIが生成したセキュリティレポートを検証し、AI分析結果と開発者の行動の間にある信頼のギャップを解消します。セキュリティスキャンにAIを活用しているチームであれば、この問題はご存知でしょう。検証できないという理由でAIの分析結果を無視してしまうチームを、私も多く見てきました。RedAgentは、AIの出力を開発者に届ける前に検証する手段をチームに提供します。\n\n### 最も使いやすい作品\n\n[Launch Control](https://devpost.com/software/launch-control-bgp8az)は洗練されたUXと堅牢なインフラを備え、サステナビリティの面でも高評価を得ました。\n\n## サステナビリティの可能性\n\n5つのプロジェクトが、環境への配慮に対して賞またはボーナスを受賞しました。CI/CDパイプラインと同様に、ソフトウェアデリバリーにはカーボンコストがかかります。そして今や、LLMも大規模なコンピューティングリソースを消費します。私たちはGreen Agentカテゴリーを設け、開発者にそのフットプリントの計測と削減に挑戦してもらいました。GitLabのサステナビリティチームのStacy ClineとKim Buncleが、Green Agentカテゴリーの審査に参加しました。\n\n### Green Agent賞\n\n[GreenPipe](https://devpost.com/software/greenpipe)は、CI/CDパイプラインの環境負荷をスキャンし、カーボンフットプリントレポートを生成します。審査員のKim BuncleとRajesh Agadi氏（Google）の両者から高く評価されました。\n\n### サステナブルデザインボーナス\n\nサステナブルデザインボーナスは、モデルの最適化技術からエネルギー効率の高いアーキテクチャの選択に至るまで、設計において卓越したサステナビリティへの取り組みを示したプロジェクトに授与されました。\n\n* [BugFlow](https://devpost.com/software/bugflow-ai-regression-detective-ci-optimizer)は20分間で1件のバグレポートから10件の修正を実現しました。\n* [DELTA Cyber Reasoning](https://devpost.com/software/delta-cyber-reasoning-system)はセキュリティのための自動ファジングテストです。\n* [CarbonLint](https://devpost.com/software/carbonlint)はエネルギー消費にコード分析を応用しました。\n* [TFGuardian](https://devpost.com/software/tfguardian)はカーボンフットプリントアナライザーなど複数のエージェントを備えています。\n\nサステナブルデザインボーナス受賞者の皆さん、おめでとうございます！\n\n審査員のJens-Joris Decorte氏（TechWolf）は成果をこう述べています：月額コストが556ドルから18ドルに下がり、カーボン排出量が96%削減されました（サステナビリティの観点から見ても、月538ドルのコスト削減です）。\n\n## 特別賞とその他の受賞者\n\n6つのプロジェクトが特別賞を受賞しました：\n\n- [SecurityMonkey](https://devpost.com/software/securitymonkey)は既知の脆弱性をテストブランチに注入し、セキュリティスキャナーがどれだけ検知できるかをスコアリングします。\n- [stregent](https://devpost.com/software/stregent)はCI/CDパイプラインを監視し、開発者がノートPCを開かずにWhatsAppから調査・マージ修正を行えるようにします。\n- [Compliance Sentinel](https://devpost.com/software/compliance-sentinel-autonomous-devsecops-governance)はすべてのマージリクエストのコンプライアンスリスクをスコアリングし、重大な違反が検出された場合はマージをブロックします。\n- [Carbon Tracker](https://devpost.com/software/carbon-tracker-ij25kf)はCI/CDパイプラインの各ジョブのカーボンフットプリントを算出し、最適化のヒントをマージリクエストに投稿します。\n- [RepoWarden](https://devpost.com/software/docuguard)は初のLiving Specification Engineであり、コードが「何をするか」だけでなく「なぜ書かれたか」を記録するAIシステムです。\n- [MR Compliance Auditor](https://devpost.com/software/mr-compliance-auditor)はマージリクエスト全体からエビデンスを収集し、SOC 2コントロールにマッピングして、コンプライアンススコアをライブダッシュボードにストリーミングします。\n\n審査中で私が最も印象に残った言葉は、Luca Chun Lun Lit氏（Anthropic）がstregentのモバイルファーストなアプローチについて述べたものです。「スマートフォンから実質的にコーディングできるというのは、エンジニアリング体験の新たなレベルです。」\n\n> [プロジェクトギャラリー](https://gitlab.devpost.com/project-gallery)で600以上のエントリーをご覧ください。\n\n## 今後の展開\n\nこのハッカソンに参加したすべてのエージェントは、単一プロジェクト内で動作していました。それでも印象的な成果を上げています。一部の参加者は、リポジトリ内のコードの関係性や依存関係を把握するために、ローカルのナレッジグラフをエージェントと並行して動かしていました。LOREはプロジェクトの履歴を記録し、Gitdefenderは脆弱性を発見します。より豊かなローカルコンテキストとエージェントを組み合わせることで、コントリビューターはすでにより精度の高いツールを構築しつつあります。次回のハッカソンは、コントリビューターが豊かなコンテキストですでに実現していることをさらに発展させます。詳細が公開され次第いち早くお知らせを受け取るには、[contributors.gitlab.com](https://contributors.gitlab.com/)でサインアップしてください。\n\n## さあ、始めましょう\n\nこのハッカソンの舞台裏を支えてくれたLee Tickett氏（GitLab）とMattias Michaux氏（GitLab）に、特別な感謝を申し上げます！\n\n参加してくださったすべての開発者の皆さん、ありがとうございました。約7,000人のみなさんが、GitLab Duo Agent Platformの可能性を証明してくれました。皆さんが作り上げたものを誇りに思いますし、次に何を構築してくれるのか、今から楽しみです。\n\n[GitLab Duo Agent Platform](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/)で自分だけのエージェントを構築しましょう。コミュニティが作成したエージェントは[AIカタログ](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/ai_catalog/)でご覧いただけます。オーケストレーションはあなたが、加速はAIが担います。\n",[715],"Nick Veenhof","2026-04-23","2026-04-22","GitLab AIハッカソン2026：受賞者発表",[720,22],"AI/ML","約7,000人の開発者がGitLab Duo Agent Platform上で600以上のAIエージェントとフローを構築したハッカソンの結果をご紹介。",{"featured":31,"template":15,"slug":723},"gitlab-ai-hackathon-2026-meet-the-winners",{"content":725,"config":737},{"date":726,"heroImage":727,"title":728,"authors":729,"category":11,"body":731,"description":732,"tags":733},"2025-08-04","https://res.cloudinary.com/about-gitlab-com/image/upload/v1754287290/averr2ecwl01q2f9lknf.jpg","git mergeコマンドの基本を徹底解説",[730],"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コマンドについてコマンドの基本的な使い方からリクエストコードまで解説します。",[734,24,735,736],"collaboration","tutorial","workflow",{"featured":14,"template":15,"slug":738},"git-merge-command-overview",{"content":740,"config":749},{"title":741,"description":742,"authors":743,"heroImage":744,"date":745,"body":746,"category":11,"tags":747},"オープンソースソフトウェア（OSS）とは？詳しく解説​","オープンソースの意味や、メリットとデメリットについて、分かりやすく解説します。",[730],"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合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[734,22,23,748],"security",{"featured":14,"template":15,"slug":750},"what-is-open-source",{"promotions":752},[753,767,779,790],{"id":754,"categories":755,"header":757,"text":758,"button":759,"image":764},"ai-modernization",[756],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":760,"config":761},"Get your AI maturity score",{"href":762,"dataGaName":763,"dataGaLocation":245},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":765},{"src":766},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":768,"categories":769,"header":771,"text":758,"button":772,"image":776},"devops-modernization",[770,566],"product","Are you just managing tools or shipping innovation?",{"text":773,"config":774},"Get your DevOps maturity score",{"href":775,"dataGaName":763,"dataGaLocation":245},"/assessments/devops-modernization-assessment/",{"config":777},{"src":778},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":780,"categories":781,"header":782,"text":758,"button":783,"image":787},"security-modernization",[748],"Are you trading speed for security?",{"text":784,"config":785},"Get your security maturity score",{"href":786,"dataGaName":763,"dataGaLocation":245},"/assessments/security-modernization-assessment/",{"config":788},{"src":789},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":791,"paths":792,"header":795,"text":796,"button":797,"image":802},"github-azure-migration",[793,794],"migration-from-azure-devops-to-gitlab","integrating-azure-devops-scm-and-gitlab","Is your team ready for GitHub's Azure move?","GitHub is already rebuilding around Azure. Find out what it means for you.",{"text":798,"config":799},"See how GitLab compares to GitHub",{"href":800,"dataGaName":801,"dataGaLocation":245},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":803},{"src":778},{"header":805,"blurb":806,"button":807,"secondaryButton":811},"今すぐ開発をスピードアップ","DevSecOpsに特化したインテリジェントオーケストレーションプラットフォームで実現できることをご確認ください。\n",{"text":47,"config":808},{"href":809,"dataGaName":50,"dataGaLocation":810},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/ja-jp/","feature",{"text":52,"config":812},{"href":54,"dataGaName":55,"dataGaLocation":810},1777493655617]