[{"data":1,"prerenderedAt":814},["ShallowReactive",2],{"/ja-jp/blog/whats-new-in-git-2-48-0":3,"navigation-ja-jp":40,"banner-ja-jp":450,"footer-ja-jp":460,"blog-post-authors-ja-jp-Christian Couder":696,"blog-related-posts-ja-jp-whats-new-in-git-2-48-0":710,"blog-promotions-ja-jp":752,"next-steps-ja-jp":805},{"id":4,"title":5,"authorSlugs":6,"authors":8,"body":10,"category":11,"categorySlug":11,"config":12,"content":16,"date":20,"description":17,"extension":26,"externalUrl":27,"featured":14,"heroImage":19,"isFeatured":14,"meta":28,"navigation":14,"path":29,"publishedDate":20,"rawbody":30,"seo":31,"slug":13,"stem":36,"tagSlugs":37,"tags":38,"template":15,"updatedDate":25,"__hash__":39},"blogPosts/ja-jp/blog/whats-new-in-git-2-48-0.yml","Git 2.48.0の新機能",[7],"christian-couder",[9],"Christian Couder","Gitプロジェクトは先日[Git 2.48.0](https://lore.kernel.org/git/xmqqplku7cvm.fsf@gitster.g/)をリリースしました。本記事では、GitLabのGitチームや幅広いGitコミュニティからのコントリビュートなど、このリリースにおけるハイライトをご紹介します。\n\n## Mesonビルドシステム\n\nこれまで長い間、Gitは[Makefile](https://en.wikipedia.org/wiki/GNU_Make)ベースまたは[Autoconf](https://en.wikipedia.org/wiki/Autoconf)ベースのビルドシステムのいずれかを使用してビルドできる仕組みになっていました。しかし、Gitデベロッパーの多くはMakefileベースのビルドシステムを主に利用しており、[Autoconfベースのビルドシステムは機能やメンテナンスの面で後れ](https://lore.kernel.org/git/GV1PR02MB848925A79A9DD733848182D58D662@GV1PR02MB8489.eurprd02.prod.outlook.com/)を取っていました。また、Windowsデベロッパーがよく利用する統合開発環境（IDE）は、MakefileやAutoconfベースのビルドシステムを十分にサポートしていないという問題もありました。\n\n2020年に[CMake](https://cmake.org/)を使用したGitのビルドが可能になり、特にVisual Studio向けに、WindowsでのサポートやIDE統合が改善されました。また、out-of-sourceビルドなどのモダンなビルドシステムも追加されました。\n\nしかし、最近ではCMakeのサポートも後れを取っており、前述の2つのビルドシステムを完全に置き換えるには適していない可能性が出てきました。こうした背景から、GitLabのGitエンジニアリングマネージャーである[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が、[Meson](https://mesonbuild.com/)ビルドシステムを導入しました。これにより、最終的にAutoconf、CMake、そして場合によってはMakefileベースのビルドシステムを置き換えることが期待されています。\n\nMesonビルドシステムの主なメリットは以下のとおりです。\n* MakefileやCMakeでは難しいビルドオプションを簡単に確認できる\n* AutoconfやCMakeに比べてシンプルな構文\n* さまざまなOS、コンパイラ、IDEをサポート\n* out-of-sourceビルドなど、モダンなビルドシステムに対応\n\n以下に、Mesonを使用したGitのビルド方法をご紹介します。\n\n```shell\n$ cd git             \t# Gitのソースコードのルートディレクトリに移動\n$ meson setup build/ \t# \"build\"をビルドディレクトリとして設定\n$ cd build           \t# \"build\"ディレクトリに移動\n$ meson compile      \t# Gitをビルド\n$ meson test         \t# 新しいビルドをテスト\n$ meson install      \t# 新しいビルドをインストール\n\n```\n\n`meson setup \u003Cbuild_dir>`を使うことで、複数のビルドディレクトリを設定できます。また、ビルドディレクトリ内で`meson configure`を実行して、そのディレクトリのビルド構成を確認または変更できます。\n\n詳しい手順は、Gitコードリポジトリの[`meson.build`ファイル](https://gitlab.com/gitlab-org/git/-/blob/master/meson.build)の冒頭に記載されています。また、Gitで使用される[ビルドシステムの比較](https://gitlab.com/gitlab-org/git/-/blob/master/Documentation/technical/build-systems.txt)は、Gitの技術ドキュメントで確認できます。\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n## Gitのメモリリーク完全解消（テストスイートによる検証済み）\n\n前回のGit 2.47.0リリースに関するブログ記事で触れたように、GitLabでは[プロジェクト内で発生したメモリリークの修正](https://about.gitlab.com/blog/whats-new-in-git-2-47-0/#code-refactoring-and-maintainability-improvements)に取り組んできました。その結果、Git 2.47.0リリース以前は、223のテストファイルで確認されていたメモリリークが、最終的に60ファイルまで削減されました。\n\nその後、残りの60ファイルにおけるメモリリークもすべて解消され、テストスイートで検証された範囲では、Gitは完全にメモリリークがない状態となりました。この成果は、Git内部コンポーネントを内部ライブラリに「ライブラリ化（変換）」するという長年の目標に向け大きく前進したことを示しています。また、メモリ使用の最適化にもつながります。\n\n今後、新たに追加されるテストはデフォルトでメモリリークがないことが求められます。リークを含むテストも可能ですが、その場合、作成者は例外的な処理を使用して、メモリリークを解消できない理由を明示する必要があります。\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n## バンドルURIチェックの改善\n\nGit 2.46.0リリースに関するブログ記事で[Xing Xin](https://lore.kernel.org/git/pull.1730.git.1715742069966.gitgitgadget@gmail.com/)による[バンドルURI修正](https://about.gitlab.com/blog/whats-new-in-git-2-46-0/#bundle-uri-fixes)を取り上げました。 その後、Xing Xinは[バンドルを使ったフェッチ](https://lore.kernel.org/git/pull.1730.v8.git.1718770053.gitgitgadget@gmail.com/)が、通常のフェッチと同様に[fsck](https://git-scm.com/docs/git-fsck)メカニズムで完全に検証されるように改良しました。\n\n通常のフェッチの検証では、[異なるfsckの問題](https://git-scm.com/docs/git-fsck#_fsck_messages)に対して[異なる重大度](https://git-scm.com/docs/git-fsck#Documentation/git-fsck.txt-fsckltmsg-idgt)を指定することで、特定のリポジトリにおいて何を許容し、何を拒否するかを細かく制御できます。しかし、これまでバンドルを使ったフェッチではこうした制御は不可能でした。\n\n[バンドルURI](https://git-scm.com/docs/bundle-uri)の有用性と安全性をさらに高めるために、[この問題を解決](https://lore.kernel.org/git/20241121204119.1440773-1-jltobler@gmail.com/)し、バンドルを使ったフェッチの検証にも異なるfsck問題に対して異なる重大度を指定できるようにしました。\n\nこのプロジェクトは[Justin Tobler](https://gitlab.com/justintobler)が主導しました。\n\n## 参照の整合性チェックを追加\n\nGit 2.47.0リリースに関するブログ記事で、[Google Summer of Code 2024](https://summerofcode.withgoogle.com/archive/2024/projects/ukm4PTEF)（GSoC 2024）の一環としてJialuo Sheが[「verify」サブコマンドをgit-refs(1)に追加](https://about.gitlab.com/blog/whats-new-in-git-2-47-0/#new-subcommand-for-git-refs\\(1\\))したことについて言及しました。\n\n記事では、最終目標として、この新しいサブコマンドをgit-fsck(1)に統合し、リポジトリの整合性チェックを一元化できるようにすることを挙げました。GSoC終了後、Jialuo Sheはこの統合作業に着手しました。\n\n[この取り組み](https://lore.kernel.org/git/ZrtrT1CPI4YUf5db@ArchLinux/)の結果、git-fsck(1)は、参照の内容が不適切な場合や、シンボリック参照としてシンボリックリンクが使用された場合、ターゲットが無効な参照を指している場合など、参照に関連するさまざまな問題を検出し処理できるようになりました。git-fsck(1)の一部として`git refs verify`を呼び出し、git-fsck(1)が現在実行しているバックエンドに依存しないすべてのチェックを`git refs verify`が引き継ぐ必要がありますが、参照の整合性チェックを一元化するという最終目標に一歩近づきました。\n\nこのプロジェクトはJialuo Sheが主導しました。\n\n## reftableにおけるイテレータの再利用\n\n[Git 2.45.0](https://gitlab.com/gitlab-org/git/-/raw/master/Documentation/RelNotes/2.45.0.txt)のリリースでは、参照（主にブランチやタグ）を管理する新しいバックエンドとして「reftable」フォーマットが導入されました。reftableバックエンドについての詳細は、この機能を紹介している過去の[Gitリリースに関するブログ記事](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-45-0/)や、[reftableの仕組みを詳しく解説した](https://about.gitlab.com/ja-jp/blog/a-beginners-guide-to-the-git-reftable-format/)初心者向けガイドをお読みください。\n\n2.45.0以降もバックエンドの改良を重ね、最近では、[内部イテレータの再利用](https://lore.kernel.org/git/cover.1730732881.git.ps@pks.im/)によってランダムな参照を読み取る際のパフォーマンスを向上させることに注力しました。こうした改善がなされるまでは、単一の参照を読み取るたびに新しいイテレータを作成し、対象のテーブル内の正しい位置を探してそこに移動させ、次の値を読み取る必要があり、多くの参照を短時間で読み取る際にはきわめて非効率でした。しかし、今回の変更により、単一のイテレータを作成し、それを再利用して複数の参照を読み取ることで、処理効率を高められるようになりました。\n\nその結果、reftableに関連するさまざまなユースケースでパフォーマンスが向上しました。特に、ランダム読み取りが頻繁に実行されるトランザクション内で多くの参照を作成する際に、7%の速度向上が確認されています。また、この変更によって、イテレータ内で保持される状態をより多く再利用できるようになるため、最適化がさらに進むと予想できます。\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n## `git-refs migrate`におけるreflog対応\n\nGit 2.46.0のリリース記事では、[このツールに関する取り組み](https://about.gitlab.com/blog/whats-new-in-git-2-46-0/#tooling-to-migrate-reference-backends)に加え、いまだ存在する課題についても次のように言及しています。\n\n「リポジトリ内のreflogは参照バックエンドのコンポーネントであり、フォーマット間の移行も必要となります。残念ながら、現時点ではツールを使用してファイルとreftableバックエンドの間でreflogを変換することはできません」\n\n[この課題はGit 2.48.0で解決](https://lore.kernel.org/git/20241216-320-git-refs-migrate-reflogs-v4-0-d7cd3f197453@gmail.com/)されました。\n`git refs migrate`を使うことでreflogの移行も可能になりました。複数のワークツリーを持つリポジトリを扱うことはまだできませんが、残された課題はこの一点のみであり、ワークツリーを使用していない場合は、既存のリポジトリでreftableバックエンドをすでに利用することが可能です。\n\nこのプロジェクトは[Karthik Nayak](https://gitlab.com/knayakgl)が主導しました。\n\n## Ref-filterの最適化\n\n「ref-filter」サブシステムは、`git for-each-ref`、`git branch`、`git tag`といったコマンドで使用されるフォーマットコードで、Git参照に関連する情報を並べ替え、フィルタリング、フォーマット、表示する役割を担っています。\n\nリポジトリの規模が大きくなるにつれて、扱う参照の数も増加します。そのため、reftableバックエンドなどの参照を保存するバックエンド（上記参照）の改善だけでなく、「ref-filter」サブシステムのようなフォーマットコードの最適化にも取り組んでいます。\n\n今回、ref-filterのコードでバックエンドの順序通りに参照を処理すべき場合に、参照の一時的なバッファリングやイテレーション処理を不要にする[方法を特定](https://lore.kernel.org/git/d23c3e3ee7fdb49fcd05b4f2e52dd2a1cfdc10f2.1729510342.git.ps@pks.im/)しました。この結果、メモリの節約が可能になり、特定のコマンドでは処理速度が最大で770倍も速くなるケースが確認されています。\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n## 補足情報\n\nこのブログ記事では、最新リリースにおけるGitLabや広範なGitコミュニティによるコントリビュートの一部をご紹介しました。詳細は、Gitプロジェクトの公式リリース発表をご覧いただくと詳細をご確認いただけます。また、[これまでのGitリリースに関するブログ記事](https://about.gitlab.com/blog/tags/git/)では、GitLabチームの過去のコントリビュートもハイライトされていますので、ぜひご確認ください。\n\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/)（英語）\n- [Git 2.45.0の新機能](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-45-0/)\n- [初心者向けGit reftableフォーマットガイド](https://about.gitlab.com/ja-jp/blog/a-beginners-guide-to-the-git-reftable-format/)\n\n\u003Cbr>\n*監修：小松原 つかさ* [*@tkomatsubara*](https://gitlab.com/tkomatsubara)\u003Cbr>\n*（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*","open-source",{"slug":13,"featured":14,"template":15},"whats-new-in-git-2-48-0",true,"BlogPost",{"title":5,"description":17,"authors":18,"heroImage":19,"date":20,"body":10,"category":11,"tags":21,"updatedDate":25},"Gitの最新バージョンについてご紹介します。新たなビルドシステムに加え、最適化された新しいreftableバックエンドが導入されました。また、GitLabのGitチームおよびGitコミュニティによるコントリビュートもご紹介します。",[9],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663691/Blog/Hero%20Images/AdobeStock_752438815.jpg","2025-01-10",[22,23,24],"git","open source","community","2025-02-13","yml",null,{},"/ja-jp/blog/whats-new-in-git-2-48-0","seo:\n  title: Git 2.48.0の新機能\n  description: >-\n    Gitの最新バージョンについてご紹介します。新たなビルドシステムに加え、最適化された新しいreftableバックエンドが導入されました。また、GitLabのGitチームおよびGitコミュニティによるコントリビュートもご紹介します。\n  ogTitle: Git 2.48.0の新機能\n  ogDescription: >-\n    Gitの最新バージョンについてご紹介します。新たなビルドシステムに加え、最適化された新しいreftableバックエンドが導入されました。また、GitLabのGitチームおよびGitコミュニティによるコントリビュートもご紹介します。\n  noIndex: false\n  ogImage: >-\n    https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663691/Blog/Hero%20Images/AdobeStock_752438815.jpg\n  ogUrl: https://about.gitlab.com/blog/whats-new-in-git-2-48-0\n  ogSiteName: https://about.gitlab.com\n  ogType: article\n  canonicalUrls: https://about.gitlab.com/blog/whats-new-in-git-2-48-0\ncontent:\n  title: Git 2.48.0の新機能\n  description: >-\n    Gitの最新バージョンについてご紹介します。新たなビルドシステムに加え、最適化された新しいreftableバックエンドが導入されました。また、GitLabのGitチームおよびGitコミュニティによるコントリビュートもご紹介します。\n  authors:\n    - Christian Couder\n  heroImage: >-\n    https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663691/Blog/Hero%20Images/AdobeStock_752438815.jpg\n  date: '2025-01-10'\n  body: \"Gitプロジェクトは先日[Git\n    2.48.0](https://lore.kernel.org/git/xmqqplku7cvm.fsf@gitster.g/)をリリースしました。本\\\n    記事では、GitLabのGitチームや幅広いGitコミュニティからのコントリビュートなど、このリリースにおけるハイライトをご紹介します。\n\n\n    ## Mesonビルドシステム\n\n\n    これまで長い間、Gitは[Makefile](https://en.wikipedia.org/wiki/GNU_Make)ベースまたは[Autoco\\\n    nf](https://en.wikipedia.org/wiki/Autoconf)ベースのビルドシステムのいずれかを使用してビルドできる仕組みにな\\\n    っていました。しかし、Gitデベロッパーの多くはMakefileベースのビルドシステムを主に利用しており、[Autoconfベースのビルドシステムは機\\\n    能やメンテナンスの面で後れ](https://lore.kernel.org/git/GV1PR02MB848925A79A9DD733848182D\\\n    58D662@GV1PR02MB8489.eurprd02.prod.outlook.com/)を取っていました。また、Windowsデベロッパーがよ\\\n    く利用する統合開発環境（IDE）は、MakefileやAutoconfベースのビルドシステムを十分にサポートしていないという問題もありました。\n\n\n    2020年に[CMake](https://cmake.org/)を使用したGitのビルドが可能になり、特にVisual\n    Studio向けに、WindowsでのサポートやIDE統合が改善されました。また、out-of-sourceビルドなどのモダンなビルドシステムも追加さ\\\n    れました。\n\n\n    しかし、最近ではCMakeのサポートも後れを取っており、前述の2つのビルドシステムを完全に置き換えるには適していない可能性が出てきました。こうした背景\\\n    から、GitLabのGitエンジニアリングマネージャーである[Patrick\n    Steinhardt](https://gitlab.com/pks-gitlab)が、[Meson](https://mesonbuild.com/\\\n    )ビルドシステムを導入しました。これにより、最終的にAutoconf、CMake、そして場合によってはMakefileベースのビルドシステムを置き換え\\\n    ることが期待されています。\n\n\n    Mesonビルドシステムの主なメリットは以下のとおりです。\n\n    * MakefileやCMakeでは難しいビルドオプションを簡単に確認できる\n\n    * AutoconfやCMakeに比べてシンプルな構文\n\n    * さまざまなOS、コンパイラ、IDEをサポート\n\n    * out-of-sourceビルドなど、モダンなビルドシステムに対応\n\n\n    以下に、Mesonを使用したGitのビルド方法をご紹介します。\n\n\n    ```shell\n\n    $ cd git             \\t# Gitのソースコードのルートディレクトリに移動\n\n    $ meson setup build/ \\t# \\\"build\\\"をビルドディレクトリとして設定\n\n    $ cd build           \\t# \\\"build\\\"ディレクトリに移動\n\n    $ meson compile      \\t# Gitをビルド\n\n    $ meson test         \\t# 新しいビルドをテスト\n\n    $ meson install      \\t# 新しいビルドをインストール\n\n\n    ```\n\n\n    `meson setup \u003Cbuild_dir>`を使うことで、複数のビルドディレクトリを設定できます。また、ビルドディレクトリ内で`meson\n    configure`を実行して、そのディレクトリのビルド構成を確認または変更できます。\n\n\n    詳しい手順は、Gitコードリポジトリの[`meson.build`ファイル](https://gitlab.com/gitlab-org/git/-/\\\n    blob/master/meson.build)の冒頭に記載されています。また、Gitで使用される[ビルドシステムの比較](https://gitla\\\n    b.com/gitlab-org/git/-/blob/master/Documentation/technical/build-systems.tx\\\n    t)は、Gitの技術ドキュメントで確認できます。\n\n\n    このプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n\n    ## Gitのメモリリーク完全解消（テストスイートによる検証済み）\n\n\n    前回のGit\n    2.47.0リリースに関するブログ記事で触れたように、GitLabでは[プロジェクト内で発生したメモリリークの修正](https://about.gi\\\n    tlab.com/blog/whats-new-in-git-2-47-0/#code-refactoring-and-maintainability\\\n    -improvements)に取り組んできました。その結果、Git\n    2.47.0リリース以前は、223のテストファイルで確認されていたメモリリークが、最終的に60ファイルまで削減されました。\n\n\n    その後、残りの60ファイルにおけるメモリリークもすべて解消され、テストスイートで検証された範囲では、Gitは完全にメモリリークがない状態となりました。\\\n    この成果は、Git内部コンポーネントを内部ライブラリに「ライブラリ化（変換）」するという長年の目標に向け大きく前進したことを示しています。また、メモリ\\\n    使用の最適化にもつながります。\n\n\n    今後、新たに追加されるテストはデフォルトでメモリリークがないことが求められます。リークを含むテストも可能ですが、その場合、作成者は例外的な処理を使用し\\\n    て、メモリリークを解消できない理由を明示する必要があります。\n\n\n    このプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n\n    ## バンドルURIチェックの改善\n\n\n    Git 2.46.0リリースに関するブログ記事で[Xing\n    Xin](https://lore.kernel.org/git/pull.1730.git.1715742069966.gitgitgadget@g\\\n    mail.com/)による[バンドルURI修正](https://about.gitlab.com/blog/whats-new-in-git-2-4\\\n    6-0/#bundle-uri-fixes)を取り上げました。 その後、Xing\n    Xinは[バンドルを使ったフェッチ](https://lore.kernel.org/git/pull.1730.v8.git.1718770053.\\\n    gitgitgadget@gmail.com/)が、通常のフェッチと同様に[fsck](https://git-scm.com/docs/git-fs\\\n    ck)メカニズムで完全に検証されるように改良しました。\n\n\n    通常のフェッチの検証では、[異なるfsckの問題](https://git-scm.com/docs/git-fsck#_fsck_messages)\\\n    に対して[異なる重大度](https://git-scm.com/docs/git-fsck#Documentation/git-fsck.txt-f\\\n    sckltmsg-idgt)を指定することで、特定のリポジトリにおいて何を許容し、何を拒否するかを細かく制御できます。しかし、これまでバンドルを使った\\\n    フェッチではこうした制御は不可能でした。\n\n\n    [バンドルURI](https://git-scm.com/docs/bundle-uri)の有用性と安全性をさらに高めるために、[この問題を解決](\\\n    https://lore.kernel.org/git/20241121204119.1440773-1-jltobler@gmail.com/)し、\\\n    バンドルを使ったフェッチの検証にも異なるfsck問題に対して異なる重大度を指定できるようにしました。\n\n\n    このプロジェクトは[Justin Tobler](https://gitlab.com/justintobler)が主導しました。\n\n\n    ## 参照の整合性チェックを追加\n\n\n    Git 2.47.0リリースに関するブログ記事で、[Google Summer of Code\n    2024](https://summerofcode.withgoogle.com/archive/2024/projects/ukm4PTEF)（G\\\n    SoC 2024）の一環としてJialuo\n    Sheが[「verify」サブコマンドをgit-refs(1)に追加](https://about.gitlab.com/blog/whats-new\\\n    -in-git-2-47-0/#new-subcommand-for-git-refs\\\\(1\\\\))したことについて言及しました。\n\n\n    記事では、最終目標として、この新しいサブコマンドをgit-fsck(1)に統合し、リポジトリの整合性チェックを一元化できるようにすることを挙げました。\\\n    GSoC終了後、Jialuo Sheはこの統合作業に着手しました。\n\n\n    [この取り組み](https://lore.kernel.org/git/ZrtrT1CPI4YUf5db@ArchLinux/)の結果、git-fs\\\n    ck(1)は、参照の内容が不適切な場合や、シンボリック参照としてシンボリックリンクが使用された場合、ターゲットが無効な参照を指している場合など、参照に\\\n    関連するさまざまな問題を検出し処理できるようになりました。git-fsck(1)の一部として`git refs\n    verify`を呼び出し、git-fsck(1)が現在実行しているバックエンドに依存しないすべてのチェックを`git refs\n    verify`が引き継ぐ必要がありますが、参照の整合性チェックを一元化するという最終目標に一歩近づきました。\n\n\n    このプロジェクトはJialuo Sheが主導しました。\n\n\n    ## reftableにおけるイテレータの再利用\n\n\n    [Git\n    2.45.0](https://gitlab.com/gitlab-org/git/-/raw/master/Documentation/RelNot\\\n    es/2.45.0.txt)のリリースでは、参照（主にブランチやタグ）を管理する新しいバックエンドとして「reftable」フォーマットが導入されまし\\\n    た。reftableバックエンドについての詳細は、この機能を紹介している過去の[Gitリリースに関するブログ記事](https://about.git\\\n    lab.com/ja-jp/blog/whats-new-in-git-2-45-0/)や、[reftableの仕組みを詳しく解説した](https:\\\n    //about.gitlab.com/ja-jp/blog/a-beginners-guide-to-the-git-reftable-format/\\\n    )初心者向けガイドをお読みください。\n\n\n    2.45.0以降もバックエンドの改良を重ね、最近では、[内部イテレータの再利用](https://lore.kernel.org/git/cover.\\\n    1730732881.git.ps@pks.im/)によってランダムな参照を読み取る際のパフォーマンスを向上させることに注力しました。こうした改善がな\\\n    されるまでは、単一の参照を読み取るたびに新しいイテレータを作成し、対象のテーブル内の正しい位置を探してそこに移動させ、次の値を読み取る必要があり、多く\\\n    の参照を短時間で読み取る際にはきわめて非効率でした。しかし、今回の変更により、単一のイテレータを作成し、それを再利用して複数の参照を読み取ることで、処\\\n    理効率を高められるようになりました。\n\n\n    その結果、reftableに関連するさまざまなユースケースでパフォーマンスが向上しました。特に、ランダム読み取りが頻繁に実行されるトランザクション内で\\\n    多くの参照を作成する際に、7%の速度向上が確認されています。また、この変更によって、イテレータ内で保持される状態をより多く再利用できるようになるため、\\\n    最適化がさらに進むと予想できます。\n\n\n    このプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n\n    ## `git-refs migrate`におけるreflog対応\n\n\n    Git\n    2.46.0のリリース記事では、[このツールに関する取り組み](https://about.gitlab.com/blog/whats-new-in-\\\n    git-2-46-0/#tooling-to-migrate-reference-backends)に加え、いまだ存在する課題についても次のように言及\\\n    しています。\n\n\n    「リポジトリ内のreflogは参照バックエンドのコンポーネントであり、フォーマット間の移行も必要となります。残念ながら、現時点ではツールを使用してファ\\\n    イルとreftableバックエンドの間でreflogを変換することはできません」\n\n\n    [この課題はGit\n    2.48.0で解決](https://lore.kernel.org/git/20241216-320-git-refs-migrate-reflog\\\n    s-v4-0-d7cd3f197453@gmail.com/)されました。\n\n    `git refs\n    migrate`を使うことでreflogの移行も可能になりました。複数のワークツリーを持つリポジトリを扱うことはまだできませんが、残された課題はこの一\\\n    点のみであり、ワークツリーを使用していない場合は、既存のリポジトリでreftableバックエンドをすでに利用することが可能です。\n\n\n    このプロジェクトは[Karthik Nayak](https://gitlab.com/knayakgl)が主導しました。\n\n\n    ## Ref-filterの最適化\n\n\n    「ref-filter」サブシステムは、`git for-each-ref`、`git branch`、`git\n    tag`といったコマンドで使用されるフォーマットコードで、Git参照に関連する情報を並べ替え、フィルタリング、フォーマット、表示する役割を担っています。\n\n\n    リポジトリの規模が大きくなるにつれて、扱う参照の数も増加します。そのため、reftableバックエンドなどの参照を保存するバックエンド（上記参照）の改\\\n    善だけでなく、「ref-filter」サブシステムのようなフォーマットコードの最適化にも取り組んでいます。\n\n\n    今回、ref-filterのコードでバックエンドの順序通りに参照を処理すべき場合に、参照の一時的なバッファリングやイテレーション処理を不要にする[方法\\\n    を特定](https://lore.kernel.org/git/d23c3e3ee7fdb49fcd05b4f2e52dd2a1cfdc10f2.1\\\n    729510342.git.ps@pks.im/)しました。この結果、メモリの節約が可能になり、特定のコマンドでは処理速度が最大で770倍も速くなるケ\\\n    ースが確認されています。\n\n\n    このプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n\n    ## 補足情報\n\n\n    このブログ記事では、最新リリースにおけるGitLabや広範なGitコミュニティによるコントリビュートの一部をご紹介しました。詳細は、Gitプロジェクト\\\n    の公式リリース発表をご覧いただくと詳細をご確認いただけます。また、[これまでのGitリリースに関するブログ記事](https://about.gitl\\\n    ab.com/blog/tags/git/)では、GitLabチームの過去のコントリビュートもハイライトされていますので、ぜひご確認ください。\n\n\n    - [Git\n    2.47.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-47-0/)（英語）\n\n    - [Git\n    2.46.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-46-0/)（英語）\n\n    - [Git\n    2.45.0の新機能](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-45-0/)\n\n    - [初心者向けGit\n    reftableフォーマットガイド](https://about.gitlab.com/ja-jp/blog/a-beginners-guide-to\\\n    -the-git-reftable-format/)\n\n\n    \u003Cbr>\n\n    *監修：小松原 つかさ* [*@tkomatsubara*](https://gitlab.com/tkomatsubara)\u003Cbr>\n\n    *（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\"\n  category: open-source\n  tags:\n    - git\n    - open source\n    - community\n  updatedDate: '2025-02-13'\nconfig:\n  slug: whats-new-in-git-2-48-0\n  featured: true\n  template: BlogPost\n",{"title":5,"description":17,"ogTitle":5,"ogDescription":17,"noIndex":32,"ogImage":19,"ogUrl":33,"ogSiteName":34,"ogType":35,"canonicalUrls":33},false,"https://about.gitlab.com/blog/whats-new-in-git-2-48-0","https://about.gitlab.com","article","ja-jp/blog/whats-new-in-git-2-48-0",[22,11,24],[22,23,24],"vpcRtsNcMvENp2KU-3IT-kboo6BWRK1yGgzMNsVbCgc",{"data":41},{"logo":42,"freeTrial":47,"sales":52,"login":57,"items":62,"search":370,"minimal":403,"duo":420,"switchNav":429,"pricingDeployment":440},{"config":43},{"href":44,"dataGaName":45,"dataGaLocation":46},"/ja-jp/","gitlab logo","header",{"text":48,"config":49},"無料トライアルを開始",{"href":50,"dataGaName":51,"dataGaLocation":46},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp&glm_content=default-saas-trial/","free trial",{"text":53,"config":54},"お問い合わせ",{"href":55,"dataGaName":56,"dataGaLocation":46},"/ja-jp/sales/","sales",{"text":58,"config":59},"サインイン",{"href":60,"dataGaName":61,"dataGaLocation":46},"https://gitlab.com/users/sign_in/","sign in",[63,90,187,192,292,352],{"text":64,"config":65,"cards":67},"プラットフォーム",{"dataNavLevelOne":66},"platform",[68,74,82],{"title":64,"description":69,"link":70},"DevSecOpsに特化したインテリジェントオーケストレーションプラットフォーム",{"text":71,"config":72},"プラットフォームを探索",{"href":73,"dataGaName":66,"dataGaLocation":46},"/ja-jp/platform/",{"title":75,"description":76,"link":77},"GitLab Duo Agent Platform","ソフトウェアライフサイクル全体を支えるエージェント型AI",{"text":78,"config":79},"GitLab Duoのご紹介",{"href":80,"dataGaName":81,"dataGaLocation":46},"/ja-jp/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":83,"description":84,"link":85},"GitLabが選ばれる理由","エンタープライズがGitLabを選ぶ主な理由をご覧ください",{"text":86,"config":87},"詳細はこちら",{"href":88,"dataGaName":89,"dataGaLocation":46},"/ja-jp/why-gitlab/","why gitlab",{"text":91,"left":14,"config":92,"link":94,"lists":98,"footer":169},"製品",{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"すべてのソリューションを表示",{"href":97,"dataGaName":93,"dataGaLocation":46},"/ja-jp/solutions/",[99,124,147],{"title":100,"description":101,"link":102,"items":107},"自動化","CI/CDと自動化でデプロイを加速",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":46},"AutomatedCodeAlt","/ja-jp/solutions/delivery-automation/","automated software delivery",[108,112,115,120],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":46,"dataGaName":109},"/ja-jp/solutions/continuous-integration/",{"text":75,"config":113},{"href":80,"dataGaLocation":46,"dataGaName":114},"gitlab duo agent platform - product menu",{"text":116,"config":117},"ソースコード管理",{"href":118,"dataGaLocation":46,"dataGaName":119},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":121,"config":122},"自動化されたソフトウェアデリバリー",{"href":105,"dataGaLocation":46,"dataGaName":123},"Automated software delivery",{"title":125,"description":126,"link":127,"items":132},"セキュリティ","セキュリティを犠牲にすることなくコード作成を高速化",{"config":128},{"href":129,"dataGaName":130,"dataGaLocation":46,"icon":131},"/ja-jp/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[133,137,142],{"text":134,"config":135},"アプリケーションセキュリティテスト",{"href":129,"dataGaName":136,"dataGaLocation":46},"Application security testing",{"text":138,"config":139},"ソフトウェアサプライチェーンの安全性",{"href":140,"dataGaLocation":46,"dataGaName":141},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":143,"config":144},"ソフトウェアコンプライアンス",{"href":145,"dataGaName":146,"dataGaLocation":46},"/ja-jp/solutions/software-compliance/","software compliance",{"title":148,"link":149,"items":154},"測定",{"config":150},{"icon":151,"href":152,"dataGaName":153,"dataGaLocation":46},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[155,159,164],{"text":156,"config":157},"可視性と測定",{"href":152,"dataGaLocation":46,"dataGaName":158},"Visibility and Measurement",{"text":160,"config":161},"バリューストリーム管理",{"href":162,"dataGaLocation":46,"dataGaName":163},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":165,"config":166},"分析とインサイト",{"href":167,"dataGaLocation":46,"dataGaName":168},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":170,"items":171},"GitLabが活躍する場所",[172,177,182],{"text":173,"config":174},"大企業",{"href":175,"dataGaLocation":46,"dataGaName":176},"/ja-jp/enterprise/","enterprise",{"text":178,"config":179},"スモールビジネス",{"href":180,"dataGaLocation":46,"dataGaName":181},"/ja-jp/small-business/","small business",{"text":183,"config":184},"公共部門",{"href":185,"dataGaLocation":46,"dataGaName":186},"/ja-jp/solutions/public-sector/","public sector",{"text":188,"config":189},"価格",{"href":190,"dataGaName":191,"dataGaLocation":46,"dataNavLevelOne":191},"/ja-jp/pricing/","pricing",{"text":193,"config":194,"link":196,"lists":200,"feature":279},"リソース",{"dataNavLevelOne":195},"resources",{"text":197,"config":198},"すべてのリソースを表示",{"href":199,"dataGaName":195,"dataGaLocation":46},"/ja-jp/resources/",[201,234,252],{"title":202,"items":203},"はじめに",[204,209,214,219,224,229],{"text":205,"config":206},"インストール",{"href":207,"dataGaName":208,"dataGaLocation":46},"/ja-jp/install/","install",{"text":210,"config":211},"クイックスタートガイド",{"href":212,"dataGaName":213,"dataGaLocation":46},"/ja-jp/get-started/","quick setup checklists",{"text":215,"config":216},"学ぶ",{"href":217,"dataGaLocation":46,"dataGaName":218},"https://university.gitlab.com/","learn",{"text":220,"config":221},"製品ドキュメント",{"href":222,"dataGaName":223,"dataGaLocation":46},"https://docs.gitlab.com/ja-jp/","product documentation",{"text":225,"config":226},"ベストプラクティスビデオ",{"href":227,"dataGaName":228,"dataGaLocation":46},"/ja-jp/getting-started-videos/","best practice videos",{"text":230,"config":231},"インテグレーション",{"href":232,"dataGaName":233,"dataGaLocation":46},"/ja-jp/integrations/","integrations",{"title":235,"items":236},"検索する",[237,242,247],{"text":238,"config":239},"お客様成功事例",{"href":240,"dataGaName":241,"dataGaLocation":46},"/ja-jp/customers/","customer success stories",{"text":243,"config":244},"ブログ",{"href":245,"dataGaName":246,"dataGaLocation":46},"/ja-jp/blog/","blog",{"text":248,"config":249},"リモート",{"href":250,"dataGaName":251,"dataGaLocation":46},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":253,"items":254},"つなげる",[255,260,264,269,274],{"text":256,"config":257},"GitLabサービス",{"href":258,"dataGaName":259,"dataGaLocation":46},"/ja-jp/services/","services",{"text":261,"config":262},"コミュニティ",{"href":263,"dataGaName":24,"dataGaLocation":46},"/community/",{"text":265,"config":266},"フォーラム",{"href":267,"dataGaName":268,"dataGaLocation":46},"https://forum.gitlab.com/","forum",{"text":270,"config":271},"イベント",{"href":272,"dataGaName":273,"dataGaLocation":46},"/events/","events",{"text":275,"config":276},"パートナー",{"href":277,"dataGaName":278,"dataGaLocation":46},"/ja-jp/partners/","partners",{"background":280,"textColor":281,"text":282,"image":283,"link":287},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":284,"config":285},"ソースプロモカード",{"src":286},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":288,"config":289},"最新情報を読む",{"href":290,"dataGaName":291,"dataGaLocation":46},"/ja-jp/the-source/","the source",{"text":293,"config":294,"lists":296},"会社情報",{"dataNavLevelOne":295},"company",[297],{"items":298},[299,304,310,312,317,322,327,332,337,342,347],{"text":300,"config":301},"GitLabについて",{"href":302,"dataGaName":303,"dataGaLocation":46},"/ja-jp/company/","about",{"text":305,"config":306,"footerGa":309},"採用情報",{"href":307,"dataGaName":308,"dataGaLocation":46},"/jobs/","jobs",{"dataGaName":308},{"text":270,"config":311},{"href":272,"dataGaName":273,"dataGaLocation":46},{"text":313,"config":314},"経営陣",{"href":315,"dataGaName":316,"dataGaLocation":46},"/company/team/e-group/","leadership",{"text":318,"config":319},"チーム",{"href":320,"dataGaName":321,"dataGaLocation":46},"/company/team/","team",{"text":323,"config":324},"ハンドブック",{"href":325,"dataGaName":326,"dataGaLocation":46},"https://handbook.gitlab.com/","handbook",{"text":328,"config":329},"投資家向け情報",{"href":330,"dataGaName":331,"dataGaLocation":46},"https://ir.gitlab.com/","investor relations",{"text":333,"config":334},"トラストセンター",{"href":335,"dataGaName":336,"dataGaLocation":46},"/ja-jp/security/","trust center",{"text":338,"config":339},"AI Transparency Center",{"href":340,"dataGaName":341,"dataGaLocation":46},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":343,"config":344},"ニュースレター",{"href":345,"dataGaName":346,"dataGaLocation":46},"/company/contact/#contact-forms","newsletter",{"text":348,"config":349},"プレス",{"href":350,"dataGaName":351,"dataGaLocation":46},"/press/","press",{"text":53,"config":353,"lists":354},{"dataNavLevelOne":295},[355],{"items":356},[357,360,365],{"text":53,"config":358},{"href":55,"dataGaName":359,"dataGaLocation":46},"talk to sales",{"text":361,"config":362},"サポートを受ける",{"href":363,"dataGaName":364,"dataGaLocation":46},"https://support.gitlab.com","support portal",{"text":366,"config":367},"カスタマーポータル",{"href":368,"dataGaName":369,"dataGaLocation":46},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":371,"login":372,"suggestions":379},"閉じる",{"text":373,"link":374},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":375,"config":376},"GitLab.com",{"href":60,"dataGaName":377,"dataGaLocation":378},"search login","search",{"text":380,"default":381},"提案",[382,384,389,391,395,399],{"text":75,"config":383},{"href":80,"dataGaName":75,"dataGaLocation":378},{"text":385,"config":386},"コード提案（AI）",{"href":387,"dataGaName":388,"dataGaLocation":378},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":109,"config":390},{"href":111,"dataGaName":109,"dataGaLocation":378},{"text":392,"config":393},"GitLab on AWS",{"href":394,"dataGaName":392,"dataGaLocation":378},"/ja-jp/partners/technology-partners/aws/",{"text":396,"config":397},"GitLab on Google Cloud",{"href":398,"dataGaName":396,"dataGaLocation":378},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":400,"config":401},"GitLabを選ぶ理由",{"href":88,"dataGaName":402,"dataGaLocation":378},"Why GitLab?",{"freeTrial":404,"mobileIcon":408,"desktopIcon":413,"secondaryButton":416},{"text":48,"config":405},{"href":406,"dataGaName":51,"dataGaLocation":407},"https://gitlab.com/-/trials/new/","nav",{"altText":409,"config":410},"GitLabアイコン",{"src":411,"dataGaName":412,"dataGaLocation":407},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":409,"config":414},{"src":415,"dataGaName":412,"dataGaLocation":407},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":202,"config":417},{"href":418,"dataGaName":419,"dataGaLocation":407},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/get-started/","get started",{"freeTrial":421,"mobileIcon":425,"desktopIcon":427},{"text":422,"config":423},"GitLab Duoの詳細について",{"href":80,"dataGaName":424,"dataGaLocation":407},"gitlab duo",{"altText":409,"config":426},{"src":411,"dataGaName":412,"dataGaLocation":407},{"altText":409,"config":428},{"src":415,"dataGaName":412,"dataGaLocation":407},{"button":430,"mobileIcon":435,"desktopIcon":437},{"text":431,"config":432},"/switch",{"href":433,"dataGaName":434,"dataGaLocation":407},"#contact","switch",{"altText":409,"config":436},{"src":411,"dataGaName":412,"dataGaLocation":407},{"altText":409,"config":438},{"src":439,"dataGaName":412,"dataGaLocation":407},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":441,"mobileIcon":446,"desktopIcon":448},{"text":442,"config":443},"料金ページに戻る",{"href":190,"dataGaName":444,"dataGaLocation":407,"icon":445},"back to pricing","GoBack",{"altText":409,"config":447},{"src":411,"dataGaName":412,"dataGaLocation":407},{"altText":409,"config":449},{"src":415,"dataGaName":412,"dataGaLocation":407},{"title":451,"button":452,"config":457},"エージェント型AIがソフトウェア配信をどのように変革するかをご覧ください",{"text":453,"config":454},"GitLab Transcendを今すぐ視聴",{"href":455,"dataGaName":456,"dataGaLocation":46},"/ja-jp/events/transcend/virtual/","transcend event",{"layout":458,"icon":459,"disabled":14},"release","AiStar",{"data":461},{"text":462,"source":463,"edit":469,"contribute":474,"config":479,"items":484,"minimal":687},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":464,"config":465},"ページのソースを表示",{"href":466,"dataGaName":467,"dataGaLocation":468},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":470,"config":471},"このページを編集",{"href":472,"dataGaName":473,"dataGaLocation":468},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":475,"config":476},"ご協力をお願いします",{"href":477,"dataGaName":478,"dataGaLocation":468},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":480,"facebook":481,"youtube":482,"linkedin":483},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[485,530,583,626,653],{"title":188,"links":486,"subMenu":501},[487,491,496],{"text":488,"config":489},"プランの表示",{"href":190,"dataGaName":490,"dataGaLocation":468},"view plans",{"text":492,"config":493},"Premiumを選ぶ理由",{"href":494,"dataGaName":495,"dataGaLocation":468},"/ja-jp/pricing/premium/","why premium",{"text":497,"config":498},"Ultimateを選ぶ理由",{"href":499,"dataGaName":500,"dataGaLocation":468},"/ja-jp/pricing/ultimate/","why ultimate",[502],{"title":53,"links":503},[504,506,508,510,515,520,525],{"text":53,"config":505},{"href":55,"dataGaName":56,"dataGaLocation":468},{"text":361,"config":507},{"href":363,"dataGaName":364,"dataGaLocation":468},{"text":366,"config":509},{"href":368,"dataGaName":369,"dataGaLocation":468},{"text":511,"config":512},"ステータス",{"href":513,"dataGaName":514,"dataGaLocation":468},"https://status.gitlab.com/","status",{"text":516,"config":517},"利用規約",{"href":518,"dataGaName":519,"dataGaLocation":468},"/terms/","terms of use",{"text":521,"config":522},"プライバシーに関する声明",{"href":523,"dataGaName":524,"dataGaLocation":468},"/ja-jp/privacy/","privacy statement",{"text":526,"config":527},"Cookie 優先設定",{"dataGaName":528,"dataGaLocation":468,"id":529,"isOneTrustButton":14},"cookie preferences","ot-sdk-btn",{"title":91,"links":531,"subMenu":540},[532,536],{"text":533,"config":534},"DevSecOpsプラットフォーム",{"href":73,"dataGaName":535,"dataGaLocation":468},"devsecops platform",{"text":537,"config":538},"AI支援開発",{"href":80,"dataGaName":539,"dataGaLocation":468},"ai-assisted development",[541],{"title":542,"links":543},"トピック",[544,548,553,558,563,568,573,578],{"text":109,"config":545},{"href":546,"dataGaName":547,"dataGaLocation":468},"/ja-jp/topics/ci-cd/","cicd",{"text":549,"config":550},"GitOps",{"href":551,"dataGaName":552,"dataGaLocation":468},"/ja-jp/topics/gitops/","gitops",{"text":554,"config":555},"DevOps",{"href":556,"dataGaName":557,"dataGaLocation":468},"/ja-jp/topics/devops/","devops",{"text":559,"config":560},"バージョン管理",{"href":561,"dataGaName":562,"dataGaLocation":468},"/ja-jp/topics/version-control/","version control",{"text":564,"config":565},"DevSecOps",{"href":566,"dataGaName":567,"dataGaLocation":468},"/ja-jp/topics/devsecops/","devsecops",{"text":569,"config":570},"クラウドネイティブ",{"href":571,"dataGaName":572,"dataGaLocation":468},"/ja-jp/topics/cloud-native/","cloud native",{"text":574,"config":575},"コーディングのためのAI",{"href":576,"dataGaName":577,"dataGaLocation":468},"/ja-jp/topics/devops/ai-for-coding/","ai for coding",{"text":579,"config":580},"エージェント型AI",{"href":581,"dataGaName":582,"dataGaLocation":468},"/ja-jp/topics/agentic-ai/","agentic ai",{"title":584,"links":585},"ソリューション",[586,589,591,596,600,603,606,609,611,613,616,621],{"text":134,"config":587},{"href":129,"dataGaName":588,"dataGaLocation":468},"Application Security Testing",{"text":121,"config":590},{"href":105,"dataGaName":106,"dataGaLocation":468},{"text":592,"config":593},"アジャイル開発",{"href":594,"dataGaName":595,"dataGaLocation":468},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":597,"config":598},"SCM",{"href":118,"dataGaName":599,"dataGaLocation":468},"source code management",{"text":109,"config":601},{"href":111,"dataGaName":602,"dataGaLocation":468},"continuous integration & delivery",{"text":160,"config":604},{"href":162,"dataGaName":605,"dataGaLocation":468},"value stream management",{"text":549,"config":607},{"href":608,"dataGaName":552,"dataGaLocation":468},"/ja-jp/solutions/gitops/",{"text":173,"config":610},{"href":175,"dataGaName":176,"dataGaLocation":468},{"text":178,"config":612},{"href":180,"dataGaName":181,"dataGaLocation":468},{"text":614,"config":615},"公共機関",{"href":185,"dataGaName":186,"dataGaLocation":468},{"text":617,"config":618},"教育",{"href":619,"dataGaName":620,"dataGaLocation":468},"/ja-jp/solutions/education/","education",{"text":622,"config":623},"金融サービス",{"href":624,"dataGaName":625,"dataGaLocation":468},"/ja-jp/solutions/finance/","financial services",{"title":193,"links":627},[628,630,632,634,637,639,641,643,645,647,649,651],{"text":205,"config":629},{"href":207,"dataGaName":208,"dataGaLocation":468},{"text":210,"config":631},{"href":212,"dataGaName":213,"dataGaLocation":468},{"text":215,"config":633},{"href":217,"dataGaName":218,"dataGaLocation":468},{"text":220,"config":635},{"href":222,"dataGaName":636,"dataGaLocation":468},"docs",{"text":243,"config":638},{"href":245,"dataGaName":246,"dataGaLocation":468},{"text":238,"config":640},{"href":240,"dataGaName":241,"dataGaLocation":468},{"text":248,"config":642},{"href":250,"dataGaName":251,"dataGaLocation":468},{"text":256,"config":644},{"href":258,"dataGaName":259,"dataGaLocation":468},{"text":261,"config":646},{"href":263,"dataGaName":24,"dataGaLocation":468},{"text":265,"config":648},{"href":267,"dataGaName":268,"dataGaLocation":468},{"text":270,"config":650},{"href":272,"dataGaName":273,"dataGaLocation":468},{"text":275,"config":652},{"href":277,"dataGaName":278,"dataGaLocation":468},{"title":293,"links":654},[655,657,659,661,663,665,667,671,676,678,680,682],{"text":300,"config":656},{"href":302,"dataGaName":295,"dataGaLocation":468},{"text":305,"config":658},{"href":307,"dataGaName":308,"dataGaLocation":468},{"text":313,"config":660},{"href":315,"dataGaName":316,"dataGaLocation":468},{"text":318,"config":662},{"href":320,"dataGaName":321,"dataGaLocation":468},{"text":323,"config":664},{"href":325,"dataGaName":326,"dataGaLocation":468},{"text":328,"config":666},{"href":330,"dataGaName":331,"dataGaLocation":468},{"text":668,"config":669},"Sustainability",{"href":670,"dataGaName":668,"dataGaLocation":468},"/sustainability/",{"text":672,"config":673},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":674,"dataGaName":675,"dataGaLocation":468},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":333,"config":677},{"href":335,"dataGaName":336,"dataGaLocation":468},{"text":343,"config":679},{"href":345,"dataGaName":346,"dataGaLocation":468},{"text":348,"config":681},{"href":350,"dataGaName":351,"dataGaLocation":468},{"text":683,"config":684},"現代奴隷制の透明性に関する声明",{"href":685,"dataGaName":686,"dataGaLocation":468},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":688},[689,691,694],{"text":516,"config":690},{"href":518,"dataGaName":519,"dataGaLocation":468},{"text":692,"config":693},"Cookieの設定",{"dataGaName":528,"dataGaLocation":468,"id":529,"isOneTrustButton":14},{"text":521,"config":695},{"href":523,"dataGaName":524,"dataGaLocation":468},[697],{"id":698,"title":9,"body":27,"config":699,"content":701,"description":27,"extension":26,"meta":705,"navigation":14,"path":706,"seo":707,"stem":708,"__hash__":709},"blogAuthors/en-us/blog/authors/christian-couder.yml",{"template":700},"BlogAuthor",{"name":9,"config":702},{"headshot":703,"ctfId":704},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663687/Blog/Author%20Headshots/chriscool-headshot.jpg","chriscool",{},"/en-us/blog/authors/christian-couder",{},"en-us/blog/authors/christian-couder","6VsKjKNdm1XKAmFMZHj53ROyylDlxaSJhcARRkw6EQQ",[711,725,740],{"content":712,"config":723},{"heroImage":713,"body":714,"authors":715,"updatedDate":717,"date":718,"title":719,"tags":720,"description":722,"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",[716],"Nick Veenhof","2026-04-23","2026-04-22","GitLab AIハッカソン2026：受賞者発表",[721,24],"AI/ML","約7,000人の開発者がGitLab Duo Agent Platform上で600以上のAIエージェントとフローを構築したハッカソンの結果をご紹介。",{"featured":32,"template":15,"slug":724},"gitlab-ai-hackathon-2026-meet-the-winners",{"content":726,"config":738},{"date":727,"heroImage":728,"title":729,"authors":730,"category":11,"body":732,"description":733,"tags":734},"2025-08-04","https://res.cloudinary.com/about-gitlab-com/image/upload/v1754287290/averr2ecwl01q2f9lknf.jpg","git mergeコマンドの基本を徹底解説",[731],"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コマンドについてコマンドの基本的な使い方からリクエストコードまで解説します。",[735,22,736,737],"collaboration","tutorial","workflow",{"featured":14,"template":15,"slug":739},"git-merge-command-overview",{"content":741,"config":750},{"title":742,"description":743,"authors":744,"heroImage":745,"date":746,"body":747,"category":11,"tags":748},"オープンソースソフトウェア（OSS）とは？詳しく解説​","オープンソースの意味や、メリットとデメリットについて、分かりやすく解説します。",[731],"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合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[735,24,23,749],"security",{"featured":14,"template":15,"slug":751},"what-is-open-source",{"promotions":753},[754,768,780,791],{"id":755,"categories":756,"header":758,"text":759,"button":760,"image":765},"ai-modernization",[757],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":761,"config":762},"Get your AI maturity score",{"href":763,"dataGaName":764,"dataGaLocation":246},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":766},{"src":767},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":769,"categories":770,"header":772,"text":759,"button":773,"image":777},"devops-modernization",[771,567],"product","Are you just managing tools or shipping innovation?",{"text":774,"config":775},"Get your DevOps maturity score",{"href":776,"dataGaName":764,"dataGaLocation":246},"/assessments/devops-modernization-assessment/",{"config":778},{"src":779},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":781,"categories":782,"header":783,"text":759,"button":784,"image":788},"security-modernization",[749],"Are you trading speed for security?",{"text":785,"config":786},"Get your security maturity score",{"href":787,"dataGaName":764,"dataGaLocation":246},"/assessments/security-modernization-assessment/",{"config":789},{"src":790},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":792,"paths":793,"header":796,"text":797,"button":798,"image":803},"github-azure-migration",[794,795],"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":799,"config":800},"See how GitLab compares to GitHub",{"href":801,"dataGaName":802,"dataGaLocation":246},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":804},{"src":779},{"header":806,"blurb":807,"button":808,"secondaryButton":812},"今すぐ開発をスピードアップ","DevSecOpsに特化したインテリジェントオーケストレーションプラットフォームで実現できることをご確認ください。\n",{"text":48,"config":809},{"href":810,"dataGaName":51,"dataGaLocation":811},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/ja-jp/","feature",{"text":53,"config":813},{"href":55,"dataGaName":56,"dataGaLocation":811},1777493635052]