[{"data":1,"prerenderedAt":825},["ShallowReactive",2],{"/ja-jp/blog/whats-new-in-git-2-45-0":3,"navigation-ja-jp":39,"banner-ja-jp":459,"footer-ja-jp":469,"blog-post-authors-ja-jp-Patrick Steinhardt":705,"blog-related-posts-ja-jp-whats-new-in-git-2-45-0":720,"blog-promotions-ja-jp":763,"next-steps-ja-jp":816},{"id":4,"title":5,"authorSlugs":6,"authors":8,"body":10,"category":11,"categorySlug":11,"config":12,"content":16,"date":23,"description":17,"extension":25,"externalUrl":26,"featured":15,"heroImage":19,"isFeatured":15,"meta":27,"navigation":28,"path":29,"publishedDate":23,"rawbody":30,"seo":31,"slug":14,"stem":35,"tagSlugs":36,"tags":37,"template":13,"updatedDate":24,"__hash__":38},"blogPosts/ja-jp/blog/whats-new-in-git-2-45-0.md","Git 2.45.0の新機能",[7],"patrick-steinhardt",[9],"Patrick Steinhardt","Gitプロジェクトは最近、[Gitバージョン2.45.0](https://lore.kernel.org/git/xmqq8r0ww0sj.fsf@gitster.g/)をリリースしました。このリリースのハイライトを見てみましょう。これには、GitLabのGitチームと、より広範なGitコミュニティからのコントリビュートによるものがあります。\n\n## Reftables: 新しい参照ストレージバックエンド\n\nすべてのGitリポジトリは、次の2つの基本的なデータ構造を追跡する必要があります:\n\n- ファイルのデータ、ディレクトリ構造、コミットメッセージ、タグを保存するオブジェクトグラフ。\n- 特定のオブジェクトをよりアクセスしやすい名前に関連付けるためのオブジェクトグラフへのポインタである参照。たとえば、ブランチは名前が `refs/heads/` プレフィックスで始まる参照です。\n\n参照がリポジトリに保存されるディスク上のフォーマットは、Gitの発足以来ほとんど変わっておらず、「files」フォーマットと呼ばれています。参照を作成するたびに、Gitは、パスが参照名と一致するGitリポジトリ内のプレーンなファイルである、いわゆる「ルース参照」を作成します。たとえば、\n\n```shell\n$ git init .\nInitialized empty Git repository in /tmp/repo/.git/\n\n# Updating a reference will cause Git to create a \"loose ref\". This loose ref is\n# a simple file which contains the object ID of the commit.\n$ git commit --allow-empty --message \"Initial commit\"\n[main (root-commit) c70f266] Initial commit\n$ cat .git/refs/heads/main\nc70f26689975782739ef9666af079535b12b5946\n\n# Creating a second reference will end up with a second loose ref.\n$ git branch feature\n$ cat .git/refs/heads/feature\nc70f26689975782739ef9666af079535b12b5946\n$ tree .git/refs\n.git/refs/\n├── heads\n│   ├── feature\n│   └── main\n└── tags\n\n3 directories, 2 files\n```\n\n時々、Gitはそれらの参照を「パックされた」ファイルフォーマットにパックして、参照をより効率的に検索できるようにします。たとえば、\n\n```shell\n# Packing references will create \"packed\" references, which are a sorted list of\n# references. The loose reference does not exist anymore.\n$ git pack-refs --all\n$ cat .git/refs/heads/main\ncat: .git/refs/heads/main: No such file or directory\n$ cat .git/packed-refs\n# pack-refs with: peeled fully-peeled sorted\nc70f26689975782739ef9666af079535b12b5946 refs/heads/feature\nc70f26689975782739ef9666af079535b12b5946 refs/heads/main\n```\n\nこのフォーマットはかなりシンプルですが、次のような制限があります。\n\n- 多くの参照を持つ大規模な単一のリポジトリでは、スケーラビリティの問題が発生し始めました。参照を削除することは、特に非効率的です。なぜなら、削除済みの参照を削除するには、「packed - refs」ファイル全体を書き換える必要があるからです。当社の最大のリポジトリでは、参照を削除するごとに数ギガバイトのデータを書き換える可能性があります。\n- すべての参照を把握するには複数のファイルを読み取る必要があるため、同時に書き込みを行うことなく参照をアトミックに読み取ることはできません。\n- 複数のファイルを作成または更新する必要があるため、アトミックに書き込みを実行することができず、ワンステップで実行できません。\n- 完全な「packed - refs」ファイルを書き換える必要があるため、参照のメンテナンスはスケーリングがうまくいきません。\n- ルース参照はファイルシステムパスをその名前として使用するため、ファイルシステム固有の動作の対象となります。例えば、大文字と小文字を区別しないファイルシステムは、単に大文字と小文字が異なるだけの参照を保存することはできません。\n\nこれらの問題に対処するために、Git v2.45.0は新しい「reftable」バックエンドを導入しました。これは、新しいバイナリフォーマットを使用して参照を保存します。この新しいバックエンドは非常に長い間開発され続けてきました。最初は2017年7月に[Shawn Pearce](https://sfconservancy.org/blog/2018/jan/30/shawn-pearce/)によって提案され、[JGit](https://www.eclipse.org/jgit/)に実装されました。これは[Gerrit プロジェクト](https://www.gerritcodereview.com/)で広く使用されています。2021年、[Han-Wen Nienhuys](https://hanwen.home.xs4all.nl/)がライブラリをGitにアップストリームし、[reftableフォーマット](https://git-scm.com/docs/reftable)の読み取りと書き込みを可能にしました。\n\nGit v2.45.0 でアップストリームした新しい「reftable」バックエンドは、ついにreftableライブラリとGitを統合し、新しいフォーマットをGitリポジトリのストレージバックエンドとして使用できるようになりました。\n\n少なくともGit v2.45.0を使用していれば、`--ref-format=reftable` スイッチを`git-init(1)` または `git-clone(1)` のいずれかに渡すことで、「reftable」フォーマットを使用して新しいリポジトリを作成できます。たとえば、\n\n```shell\n$ git init --ref-format=reftable .\nInitialized empty Git repository in /tmp/repo/.git/\n$ git rev-parse --show-ref-format\nreftable\n$ find -type f .git/reftable/\n.git/reftable/0x000000000001-0x000000000001-01b5e47d.ref\n.git/reftable/tables.list\n\n$ git commit --allow-empty --message \"Initial commit\"\n$ find -type f .git/reftable/\n.git/reftable/0x000000000001-0x000000000001-01b5e47d.ref\n.git/reftable/0x000000000002-0x000000000002-87006b81.ref\n.git/reftable/tables.list\n```\n\nご覧のとおり、参照は `.git/refs` ディレクトリではなく `.git/reftable` に保存されています。参照と参照ログは、`.ref` で終わるファイルである「テーブル」に保存されますが、`tables.list` ファイルには現在アクティブなすべてのテーブルのリストが含まれています。この仕組みの技術的な詳細については、別のブログ記事でご説明します。引き続きブログをご覧いただくようお願いいたします。\n\n「reftable」バックエンドは、「files」バックエンドに取って代わるものです。したがって、ユーザーの観点からは、すべてが同じように機能する必要があります。\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。また、Shawn Pearceがフォーマットのオリジナルを発案、Han - Wen Nienhuysがreftableライブラリを作成しています。\n\n## 参照用ツールの改善\n「reftable」フォーマットは、私たちが抱えている多くの問題を解決してくれる一方で、新しい問題も生み出しています。 最も重要な問題の1つが、格納されているデータへのアクセシビリティです。\n\n「files」バックエンドを使用すると、最悪の場合、通常のUnixツールを使用して参照の状態を調べることになります。「packed」参照と「loose」参照の両方には、人間が簡単に理解できるデータが含まれています。これは、バイナリフォーマットである「reftable」フォーマットとは異なります。したがって、Gitは新しい「reftable」フォーマットからデータを抽出するために必要なすべてのツールを提供する必要があります。\n\n### すべての参照の一覧表示\n最初の問題は、リポジトリからすべての参照を把握するのは基本的に不可能であるということです。 Gitで参照を作成したり変更できるのに、すべての参照を網羅的にリストできないと聞くと、困惑する方もいるかもしれません。\n\n確かに、「files」バックエンドはできません。`refs/` プレフィックスで始まるすべての「通常の」参照を簡単にリストすることはできますが、Gitはいわゆる[pseudo refs](https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefpseudorefapseudoref)（疑似参照）も使用します。これらのファイルはGitディレクトリのルートに直接存在し、たとえば `.git/MERGE_HEAD` などのようなファイルです。問題は、これらの疑似参照が、Gitが格納する、たとえば `.git/config` のような他のファイルの隣に存在することです。\n\n一部の疑似参照はよく知られているため識別しやすく、理論上はGitが書き込むことができる参照に制限はありません。「foobar」という参照を作成するのを妨げるものはありません。\n\nたとえば、\n\n```shell\n$ git update-ref foobar HEAD\n$ cat .git/foobar\nf32633d4d7da32ccc3827e90ecdc10570927c77d\n```\n\n「files」バックエンドにある問題は、ディレクトリをスキャンして参照を列挙するしかないということです。したがって `.git/foobar` が実際には参照であることを理解するために、Gitはファイルを開き、ファイルが参照のようにフォーマットされているかどうかを確認する必要があります。\n\n一方、「reftable」バックエンドは、それに含まれるすべての参照について簡単に認識します。参照はデータ構造にエンコードされているため、それらの参照をデコードして返すだけです。しかし、「files」バックエンドの制限により、存在するすべての参照について学ぶことができるツールは存在しません。\n\nこの問題に対処するために、`git-for-each-ref(1)` に `--include-root-refs` という新しいフラグを追加しました。これにより、参照名の階層のルートに存在するすべての参照もリストアップされます。\nたとえば、\n\n```shell\n$ git for-each-ref --include-root-refs\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    HEAD\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    MERGE_HEAD\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    refs/heads/main\n```\n\n「files」バックエンドの場合、この新しいフラグはベストエフォートで処理され、既知の疑似参照名に一致するすべての参照が含まれます。「reftable」バックエンドの場合、それに関連するすべての参照をすべてリストアップすることができます。\n\nこのプロジェクトは、[Karthik Nayak](https://gitlab.com/knayakgl)が主導しました。\n\n### すべての参照ログの一覧表示\n\nブランチを更新するたびに、Gitはデフォルトでそれらのブランチの更新をいわゆる参照ログで追跡します。この参照ログを使用すると、意図しない変更を行った場合に、そのブランチへの変更をロールバックできるため、非常に役立つツールとなります。\n\n「files」バックエンドでは、これらのログは `.git/logs` ディレクトリに保存されます。\n\n```shell\n$ find -type f .git/logs/\n.git/logs/HEAD\n.git/logs/refs/heads/main\n```\n\n実際、このディレクトリ内のファイルを一覧表示することが、そもそもどの参照が実際に参照ログを保持しているかを知る唯一の方法です。これは、参照と一緒にそれらのログを保存する「reftable」バックエンドの問題です。そのため、「reftable」フォーマットを使用すると、リポジトリにどの参照ログが存在するかを知る方法はまったくありません。\n\nこれは実際には「reftable」フォーマットの欠陥ではありませんが、Gitが提供するツールにおける不備です。この欠落に対処するために、`git-reflog(1)` に新しい `list` サブコマンドを導入しました。これにより、すべての既存の参照ログをリストアップできます。\n\n```shell\n$ git reflog list\nHEAD\nrefs/heads/main\n```\n\nこのプロジェクトは、[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n### 参照のより効率的なパッキング\n\nGitリポジトリを効率的に保つには、定期的なメンテナンスが必要です。 通常、このメンテナンスは `git maintenance run --auto` を実行してGitリポジトリにデータを書き込むさまざまなGitコマンドによってトリガーされます。このコマンドは、Gitが計算リソースを無駄にしないように、実際に最適化が必要なデータ構造のみを最適化します。\n\nGitのメンテナンスによって最適化されるデータ構造の1つは、`git pack-refs --all` を実行することによって行われる参照データベースです。「files」バックエンドの場合、これは、すべての参照が「packed - refs」ファイルに再パックされ、ルース参照が削除されることを意味します。一方、「reftable」バックエンドの場合、すべてのテーブルが単一のテーブルにマージされます。\n\n「files」バックエンドについては、合理的に改善することはできません。「packed - refs」ファイル全体を書き直す必要があることを考えると、すべてのルース参照をパックしたいと考えるのは理にかなっています。\n\nしかし、「reftable」バックエンドの場合、「reftable」バックエンドが自己最適化されるため、最適ではありません。Gitは、新しいテーブルを「reftable」バックエンドに追加するたびに、必要に応じて自動コンパクションを実行し、テーブルを一緒にマージします。したがって、参照データベースは常に適切に最適化された状態にある必要があり、そのため、すべてのテーブルを一緒にマージすることは無駄な努力となります。\n\nそこでGit v2.45.0では、新しい `git pack-refs --auto` モードを導入し、参照バックエンドに必要に応じて最適化を行うようにしました。 「files」バックエンドは、`--auto` フラグが設定されていても同じように動作し続けますが、「reftable」バックエンドは、自動コンパクションにすでに使用されているのと同じ経験則を使用します。 実際には、これはほとんどの場合何も操作を行いません。\n\nさらに、`git maintenance run --auto` は、デフォルトでこの新しいモードを使用するために、`-tauto` フラグを `git-pack-refs(1)` に渡すように調整されています。\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n## 補足情報\n\nこのブログ記事では、新しい「reftable」バックエンドに重点を置いています。このバックエンドにより、多くの参照を持つ大規模なリポジトリでの拡張性が向上しました。また、このバックエンドをうまく機能させるために関連したツールも導入しました。このGitリリースではさまざまなパフォーマンスの向上、バグ修正、その他の細かい機能がGitコミュニティによって導入されています。Gitプロジェクトの[公式リリース発表](https://lore.kernel.org/git/xmqq8r0ww0sj.fsf@gitster.g/)をご覧いただくと詳細をご確認いただけます。\n\n*監修：小松原 つかさ\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\n\n## 過去のGitリリースへのコントリビューション\n* [Git 2.44.0へのGitLabのコントリビューション](https://about.gitlab.com/blog/gitlabs-contributions-to-git-2-44-0/)\n* [Git 2.43.0へのGitLabのコントリビューション](https://about.gitlab.com/blog/the-contributions-we-made-to-the-git-2-43-release/)\n* [Git 2.42.0へのGitLabのコントリビューション](https://about.gitlab.com/blog/contributions-to-git-2-42-release/)\n* [Git 2.41.0へのGitLabのコントリビューション](https://about.gitlab.com/blog/contributions-to-latest-git-release/)","open-source",{"template":13,"slug":14,"featured":15},"BlogPost","whats-new-in-git-2-45-0",false,{"title":5,"description":17,"authors":18,"heroImage":19,"tags":20,"category":11,"date":23,"updatedDate":24,"body":10},"ここでは、GitLabのGitチームと、より広範なGitコミュニティが最新のGitリリースにコントリビュートしたいくつかのハイライトを紹介します。これには、「reftables」や参照用の優れたツールなどが挙げられます。",[9],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659507/Blog/Hero%20Images/AdobeStock_623844718.jpg",[21,22],"git","community","2024-04-30","2024-05-17","md",null,{},true,"/ja-jp/blog/whats-new-in-git-2-45-0","---\nseo:\n  title: Git 2.45.0の新機能\n  description: >-\n    ここでは、GitLabのGitチームと、より広範なGitコミュニティが最新のGitリリースにコントリビュートしたいくつかのハイライトを紹介します。これには、「reftables」や参照用の優れたツールなどが挙げられます。\n  ogTitle: Git 2.45.0の新機能\n  ogDescription: >-\n    ここでは、GitLabのGitチームと、より広範なGitコミュニティが最新のGitリリースにコントリビュートしたいくつかのハイライトを紹介します。これには、「reftables」や参照用の優れたツールなどが挙げられます。\n  noIndex: false\n  ogImage: >-\n    https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659507/Blog/Hero%20Images/AdobeStock_623844718.jpg\n  ogUrl: https://about.gitlab.com/blog/whats-new-in-git-2-45-0\n  ogSiteName: https://about.gitlab.com\n  ogType: article\n  canonicalUrls: https://about.gitlab.com/blog/whats-new-in-git-2-45-0\ntitle: Git 2.45.0の新機能\ndescription: ここでは、GitLabのGitチームと、より広範なGitコミュニティが最新のGitリリースにコントリビュートしたいくつかのハイライトを紹介します。これには、「reftables」や参照用の優れたツールなどが挙げられます。\nauthors:\n  - Patrick Steinhardt\nheroImage: https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659507/Blog/Hero%20Images/AdobeStock_623844718.jpg\ntags:\n  - git\n  - community\ncategory: open-source\ndate: '2024-04-30'\nupdatedDate: '2024-05-17'\nslug: whats-new-in-git-2-45-0\nfeatured: false\ntemplate: BlogPost\n---\n\nGitプロジェクトは最近、[Gitバージョン2.45.0](https://lore.kernel.org/git/xmqq8r0ww0sj.fsf@gitster.g/)をリリースしました。このリリースのハイライトを見てみましょう。これには、GitLabのGitチームと、より広範なGitコミュニティからのコントリビュートによるものがあります。\n\n## Reftables: 新しい参照ストレージバックエンド\n\nすべてのGitリポジトリは、次の2つの基本的なデータ構造を追跡する必要があります:\n\n- ファイルのデータ、ディレクトリ構造、コミットメッセージ、タグを保存するオブジェクトグラフ。\n- 特定のオブジェクトをよりアクセスしやすい名前に関連付けるためのオブジェクトグラフへのポインタである参照。たとえば、ブランチは名前が `refs/heads/` プレフィックスで始まる参照です。\n\n参照がリポジトリに保存されるディスク上のフォーマットは、Gitの発足以来ほとんど変わっておらず、「files」フォーマットと呼ばれています。参照を作成するたびに、Gitは、パスが参照名と一致するGitリポジトリ内のプレーンなファイルである、いわゆる「ルース参照」を作成します。たとえば、\n\n```shell\n$ git init .\nInitialized empty Git repository in /tmp/repo/.git/\n\n# Updating a reference will cause Git to create a \"loose ref\". This loose ref is\n# a simple file which contains the object ID of the commit.\n$ git commit --allow-empty --message \"Initial commit\"\n[main (root-commit) c70f266] Initial commit\n$ cat .git/refs/heads/main\nc70f26689975782739ef9666af079535b12b5946\n\n# Creating a second reference will end up with a second loose ref.\n$ git branch feature\n$ cat .git/refs/heads/feature\nc70f26689975782739ef9666af079535b12b5946\n$ tree .git/refs\n.git/refs/\n├── heads\n│   ├── feature\n│   └── main\n└── tags\n\n3 directories, 2 files\n```\n\n時々、Gitはそれらの参照を「パックされた」ファイルフォーマットにパックして、参照をより効率的に検索できるようにします。たとえば、\n\n```shell\n# Packing references will create \"packed\" references, which are a sorted list of\n# references. The loose reference does not exist anymore.\n$ git pack-refs --all\n$ cat .git/refs/heads/main\ncat: .git/refs/heads/main: No such file or directory\n$ cat .git/packed-refs\n# pack-refs with: peeled fully-peeled sorted\nc70f26689975782739ef9666af079535b12b5946 refs/heads/feature\nc70f26689975782739ef9666af079535b12b5946 refs/heads/main\n```\n\nこのフォーマットはかなりシンプルですが、次のような制限があります。\n\n- 多くの参照を持つ大規模な単一のリポジトリでは、スケーラビリティの問題が発生し始めました。参照を削除することは、特に非効率的です。なぜなら、削除済みの参照を削除するには、「packed - refs」ファイル全体を書き換える必要があるからです。当社の最大のリポジトリでは、参照を削除するごとに数ギガバイトのデータを書き換える可能性があります。\n- すべての参照を把握するには複数のファイルを読み取る必要があるため、同時に書き込みを行うことなく参照をアトミックに読み取ることはできません。\n- 複数のファイルを作成または更新する必要があるため、アトミックに書き込みを実行することができず、ワンステップで実行できません。\n- 完全な「packed - refs」ファイルを書き換える必要があるため、参照のメンテナンスはスケーリングがうまくいきません。\n- ルース参照はファイルシステムパスをその名前として使用するため、ファイルシステム固有の動作の対象となります。例えば、大文字と小文字を区別しないファイルシステムは、単に大文字と小文字が異なるだけの参照を保存することはできません。\n\nこれらの問題に対処するために、Git v2.45.0は新しい「reftable」バックエンドを導入しました。これは、新しいバイナリフォーマットを使用して参照を保存します。この新しいバックエンドは非常に長い間開発され続けてきました。最初は2017年7月に[Shawn Pearce](https://sfconservancy.org/blog/2018/jan/30/shawn-pearce/)によって提案され、[JGit](https://www.eclipse.org/jgit/)に実装されました。これは[Gerrit プロジェクト](https://www.gerritcodereview.com/)で広く使用されています。2021年、[Han-Wen Nienhuys](https://hanwen.home.xs4all.nl/)がライブラリをGitにアップストリームし、[reftableフォーマット](https://git-scm.com/docs/reftable)の読み取りと書き込みを可能にしました。\n\nGit v2.45.0 でアップストリームした新しい「reftable」バックエンドは、ついにreftableライブラリとGitを統合し、新しいフォーマットをGitリポジトリのストレージバックエンドとして使用できるようになりました。\n\n少なくともGit v2.45.0を使用していれば、`--ref-format=reftable` スイッチを`git-init(1)` または `git-clone(1)` のいずれかに渡すことで、「reftable」フォーマットを使用して新しいリポジトリを作成できます。たとえば、\n\n```shell\n$ git init --ref-format=reftable .\nInitialized empty Git repository in /tmp/repo/.git/\n$ git rev-parse --show-ref-format\nreftable\n$ find -type f .git/reftable/\n.git/reftable/0x000000000001-0x000000000001-01b5e47d.ref\n.git/reftable/tables.list\n\n$ git commit --allow-empty --message \"Initial commit\"\n$ find -type f .git/reftable/\n.git/reftable/0x000000000001-0x000000000001-01b5e47d.ref\n.git/reftable/0x000000000002-0x000000000002-87006b81.ref\n.git/reftable/tables.list\n```\n\nご覧のとおり、参照は `.git/refs` ディレクトリではなく `.git/reftable` に保存されています。参照と参照ログは、`.ref` で終わるファイルである「テーブル」に保存されますが、`tables.list` ファイルには現在アクティブなすべてのテーブルのリストが含まれています。この仕組みの技術的な詳細については、別のブログ記事でご説明します。引き続きブログをご覧いただくようお願いいたします。\n\n「reftable」バックエンドは、「files」バックエンドに取って代わるものです。したがって、ユーザーの観点からは、すべてが同じように機能する必要があります。\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。また、Shawn Pearceがフォーマットのオリジナルを発案、Han - Wen Nienhuysがreftableライブラリを作成しています。\n\n## 参照用ツールの改善\n「reftable」フォーマットは、私たちが抱えている多くの問題を解決してくれる一方で、新しい問題も生み出しています。 最も重要な問題の1つが、格納されているデータへのアクセシビリティです。\n\n「files」バックエンドを使用すると、最悪の場合、通常のUnixツールを使用して参照の状態を調べることになります。「packed」参照と「loose」参照の両方には、人間が簡単に理解できるデータが含まれています。これは、バイナリフォーマットである「reftable」フォーマットとは異なります。したがって、Gitは新しい「reftable」フォーマットからデータを抽出するために必要なすべてのツールを提供する必要があります。\n\n### すべての参照の一覧表示\n最初の問題は、リポジトリからすべての参照を把握するのは基本的に不可能であるということです。 Gitで参照を作成したり変更できるのに、すべての参照を網羅的にリストできないと聞くと、困惑する方もいるかもしれません。\n\n確かに、「files」バックエンドはできません。`refs/` プレフィックスで始まるすべての「通常の」参照を簡単にリストすることはできますが、Gitはいわゆる[pseudo refs](https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefpseudorefapseudoref)（疑似参照）も使用します。これらのファイルはGitディレクトリのルートに直接存在し、たとえば `.git/MERGE_HEAD` などのようなファイルです。問題は、これらの疑似参照が、Gitが格納する、たとえば `.git/config` のような他のファイルの隣に存在することです。\n\n一部の疑似参照はよく知られているため識別しやすく、理論上はGitが書き込むことができる参照に制限はありません。「foobar」という参照を作成するのを妨げるものはありません。\n\nたとえば、\n\n```shell\n$ git update-ref foobar HEAD\n$ cat .git/foobar\nf32633d4d7da32ccc3827e90ecdc10570927c77d\n```\n\n「files」バックエンドにある問題は、ディレクトリをスキャンして参照を列挙するしかないということです。したがって `.git/foobar` が実際には参照であることを理解するために、Gitはファイルを開き、ファイルが参照のようにフォーマットされているかどうかを確認する必要があります。\n\n一方、「reftable」バックエンドは、それに含まれるすべての参照について簡単に認識します。参照はデータ構造にエンコードされているため、それらの参照をデコードして返すだけです。しかし、「files」バックエンドの制限により、存在するすべての参照について学ぶことができるツールは存在しません。\n\nこの問題に対処するために、`git-for-each-ref(1)` に `--include-root-refs` という新しいフラグを追加しました。これにより、参照名の階層のルートに存在するすべての参照もリストアップされます。\nたとえば、\n\n```shell\n$ git for-each-ref --include-root-refs\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    HEAD\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    MERGE_HEAD\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    refs/heads/main\n```\n\n「files」バックエンドの場合、この新しいフラグはベストエフォートで処理され、既知の疑似参照名に一致するすべての参照が含まれます。「reftable」バックエンドの場合、それに関連するすべての参照をすべてリストアップすることができます。\n\nこのプロジェクトは、[Karthik Nayak](https://gitlab.com/knayakgl)が主導しました。\n\n### すべての参照ログの一覧表示\n\nブランチを更新するたびに、Gitはデフォルトでそれらのブランチの更新をいわゆる参照ログで追跡します。この参照ログを使用すると、意図しない変更を行った場合に、そのブランチへの変更をロールバックできるため、非常に役立つツールとなります。\n\n「files」バックエンドでは、これらのログは `.git/logs` ディレクトリに保存されます。\n\n```shell\n$ find -type f .git/logs/\n.git/logs/HEAD\n.git/logs/refs/heads/main\n```\n\n実際、このディレクトリ内のファイルを一覧表示することが、そもそもどの参照が実際に参照ログを保持しているかを知る唯一の方法です。これは、参照と一緒にそれらのログを保存する「reftable」バックエンドの問題です。そのため、「reftable」フォーマットを使用すると、リポジトリにどの参照ログが存在するかを知る方法はまったくありません。\n\nこれは実際には「reftable」フォーマットの欠陥ではありませんが、Gitが提供するツールにおける不備です。この欠落に対処するために、`git-reflog(1)` に新しい `list` サブコマンドを導入しました。これにより、すべての既存の参照ログをリストアップできます。\n\n```shell\n$ git reflog list\nHEAD\nrefs/heads/main\n```\n\nこのプロジェクトは、[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n### 参照のより効率的なパッキング\n\nGitリポジトリを効率的に保つには、定期的なメンテナンスが必要です。 通常、このメンテナンスは `git maintenance run --auto` を実行してGitリポジトリにデータを書き込むさまざまなGitコマンドによってトリガーされます。このコマンドは、Gitが計算リソースを無駄にしないように、実際に最適化が必要なデータ構造のみを最適化します。\n\nGitのメンテナンスによって最適化されるデータ構造の1つは、`git pack-refs --all` を実行することによって行われる参照データベースです。「files」バックエンドの場合、これは、すべての参照が「packed - refs」ファイルに再パックされ、ルース参照が削除されることを意味します。一方、「reftable」バックエンドの場合、すべてのテーブルが単一のテーブルにマージされます。\n\n「files」バックエンドについては、合理的に改善することはできません。「packed - refs」ファイル全体を書き直す必要があることを考えると、すべてのルース参照をパックしたいと考えるのは理にかなっています。\n\nしかし、「reftable」バックエンドの場合、「reftable」バックエンドが自己最適化されるため、最適ではありません。Gitは、新しいテーブルを「reftable」バックエンドに追加するたびに、必要に応じて自動コンパクションを実行し、テーブルを一緒にマージします。したがって、参照データベースは常に適切に最適化された状態にある必要があり、そのため、すべてのテーブルを一緒にマージすることは無駄な努力となります。\n\nそこでGit v2.45.0では、新しい `git pack-refs --auto` モードを導入し、参照バックエンドに必要に応じて最適化を行うようにしました。 「files」バックエンドは、`--auto` フラグが設定されていても同じように動作し続けますが、「reftable」バックエンドは、自動コンパクションにすでに使用されているのと同じ経験則を使用します。 実際には、これはほとんどの場合何も操作を行いません。\n\nさらに、`git maintenance run --auto` は、デフォルトでこの新しいモードを使用するために、`-tauto` フラグを `git-pack-refs(1)` に渡すように調整されています。\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n## 補足情報\n\nこのブログ記事では、新しい「reftable」バックエンドに重点を置いています。このバックエンドにより、多くの参照を持つ大規模なリポジトリでの拡張性が向上しました。また、このバックエンドをうまく機能させるために関連したツールも導入しました。このGitリリースではさまざまなパフォーマンスの向上、バグ修正、その他の細かい機能がGitコミュニティによって導入されています。Gitプロジェクトの[公式リリース発表](https://lore.kernel.org/git/xmqq8r0ww0sj.fsf@gitster.g/)をご覧いただくと詳細をご確認いただけます。\n\n*監修：小松原 つかさ\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\n\n## 過去のGitリリースへのコントリビューション\n* [Git 2.44.0へのGitLabのコントリビューション](https://about.gitlab.com/blog/gitlabs-contributions-to-git-2-44-0/)\n* [Git 2.43.0へのGitLabのコントリビューション](https://about.gitlab.com/blog/the-contributions-we-made-to-the-git-2-43-release/)\n* [Git 2.42.0へのGitLabのコントリビューション](https://about.gitlab.com/blog/contributions-to-git-2-42-release/)\n* [Git 2.41.0へのGitLabのコントリビューション](https://about.gitlab.com/blog/contributions-to-latest-git-release/)\n",{"title":5,"description":17,"ogTitle":5,"ogDescription":17,"noIndex":15,"ogImage":19,"ogUrl":32,"ogSiteName":33,"ogType":34,"canonicalUrls":32},"https://about.gitlab.com/blog/whats-new-in-git-2-45-0","https://about.gitlab.com","article","ja-jp/blog/whats-new-in-git-2-45-0",[21,22],[21,22],"mZS1_zmtkybzuTcPglx4D0S3n8_dMFHNX2Mv4kZNgz4",{"logo":40,"freeTrial":45,"sales":50,"login":55,"items":60,"search":379,"minimal":412,"duo":429,"switchNav":438,"pricingDeployment":449},{"config":41},{"href":42,"dataGaName":43,"dataGaLocation":44},"/ja-jp/","gitlab logo","header",{"text":46,"config":47},"無料トライアルを開始",{"href":48,"dataGaName":49,"dataGaLocation":44},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp&glm_content=default-saas-trial/","free trial",{"text":51,"config":52},"お問い合わせ",{"href":53,"dataGaName":54,"dataGaLocation":44},"/ja-jp/sales/","sales",{"text":56,"config":57},"サインイン",{"href":58,"dataGaName":59,"dataGaLocation":44},"https://gitlab.com/users/sign_in/","sign in",[61,90,192,197,299,360],{"text":62,"config":63,"menu":65},"プラットフォーム",{"dataNavLevelOne":64},"platform",{"type":66,"columns":67},"cards",[68,74,82],{"title":62,"description":69,"link":70},"DevSecOpsに特化したインテリジェントオーケストレーションプラットフォーム",{"text":71,"config":72},"プラットフォームを探索",{"href":73,"dataGaName":64,"dataGaLocation":44},"/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":44},"/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":44},"/ja-jp/why-gitlab/","why gitlab",{"text":91,"left":28,"config":92,"menu":94},"製品",{"dataNavLevelOne":93},"solutions",{"type":95,"link":96,"columns":100,"feature":171},"lists",{"text":97,"config":98},"すべてのソリューションを表示",{"href":99,"dataGaName":93,"dataGaLocation":44},"/ja-jp/solutions/",[101,126,149],{"title":102,"description":103,"link":104,"items":109},"自動化","CI/CDと自動化でデプロイを加速",{"config":105},{"icon":106,"href":107,"dataGaName":108,"dataGaLocation":44},"AutomatedCodeAlt","/ja-jp/solutions/delivery-automation/","automated software delivery",[110,114,117,122],{"text":111,"config":112},"CI/CD",{"href":113,"dataGaLocation":44,"dataGaName":111},"/ja-jp/solutions/continuous-integration/",{"text":75,"config":115},{"href":80,"dataGaLocation":44,"dataGaName":116},"gitlab duo agent platform - product menu",{"text":118,"config":119},"ソースコード管理",{"href":120,"dataGaLocation":44,"dataGaName":121},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":123,"config":124},"自動化されたソフトウェアデリバリー",{"href":107,"dataGaLocation":44,"dataGaName":125},"Automated software delivery",{"title":127,"description":128,"link":129,"items":134},"セキュリティ","セキュリティを犠牲にすることなくコード作成を高速化",{"config":130},{"href":131,"dataGaName":132,"dataGaLocation":44,"icon":133},"/ja-jp/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[135,139,144],{"text":136,"config":137},"アプリケーションセキュリティテスト",{"href":131,"dataGaName":138,"dataGaLocation":44},"Application security testing",{"text":140,"config":141},"ソフトウェアサプライチェーンの安全性",{"href":142,"dataGaLocation":44,"dataGaName":143},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":145,"config":146},"ソフトウェアコンプライアンス",{"href":147,"dataGaName":148,"dataGaLocation":44},"/ja-jp/solutions/software-compliance/","software compliance",{"title":150,"link":151,"items":156},"測定",{"config":152},{"icon":153,"href":154,"dataGaName":155,"dataGaLocation":44},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[157,161,166],{"text":158,"config":159},"可視性と測定",{"href":154,"dataGaLocation":44,"dataGaName":160},"Visibility and Measurement",{"text":162,"config":163},"バリューストリーム管理",{"href":164,"dataGaLocation":44,"dataGaName":165},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":167,"config":168},"分析とインサイト",{"href":169,"dataGaLocation":44,"dataGaName":170},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":172,"type":95,"items":173},"GitLabが活躍する場所",[174,180,186],{"text":175,"config":176},"エンタープライズ",{"icon":177,"href":178,"dataGaLocation":44,"dataGaName":179},"Building","/ja-jp/enterprise/","enterprise",{"text":181,"config":182},"スモールビジネス",{"icon":183,"href":184,"dataGaLocation":44,"dataGaName":185},"Work","/ja-jp/small-business/","small business",{"text":187,"config":188},"公共部門",{"icon":189,"href":190,"dataGaLocation":44,"dataGaName":191},"Organization","/ja-jp/solutions/public-sector/","public sector",{"text":193,"config":194},"価格",{"href":195,"dataGaName":196,"dataGaLocation":44,"dataNavLevelOne":196},"/ja-jp/pricing/","pricing",{"text":198,"config":199,"menu":201},"リソース",{"dataNavLevelOne":200},"resources",{"type":95,"link":202,"columns":206,"feature":285},{"text":203,"config":204},"すべてのリソースを表示",{"href":205,"dataGaName":200,"dataGaLocation":44},"/ja-jp/resources/",[207,240,258],{"title":208,"items":209},"はじめに",[210,215,220,225,230,235],{"text":211,"config":212},"インストール",{"href":213,"dataGaName":214,"dataGaLocation":44},"/ja-jp/install/","install",{"text":216,"config":217},"クイックスタートガイド",{"href":218,"dataGaName":219,"dataGaLocation":44},"/ja-jp/get-started/","quick setup checklists",{"text":221,"config":222},"学ぶ",{"href":223,"dataGaLocation":44,"dataGaName":224},"https://university.gitlab.com/","learn",{"text":226,"config":227},"製品ドキュメント",{"href":228,"dataGaName":229,"dataGaLocation":44},"https://docs.gitlab.com/ja-jp/","product documentation",{"text":231,"config":232},"ベストプラクティスビデオ",{"href":233,"dataGaName":234,"dataGaLocation":44},"/ja-jp/getting-started-videos/","best practice videos",{"text":236,"config":237},"インテグレーション",{"href":238,"dataGaName":239,"dataGaLocation":44},"/ja-jp/integrations/","integrations",{"title":241,"items":242},"検索する",[243,248,253],{"text":244,"config":245},"お客様成功事例",{"href":246,"dataGaName":247,"dataGaLocation":44},"/ja-jp/customers/","customer success stories",{"text":249,"config":250},"ブログ",{"href":251,"dataGaName":252,"dataGaLocation":44},"/ja-jp/blog/","blog",{"text":254,"config":255},"リモート",{"href":256,"dataGaName":257,"dataGaLocation":44},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":259,"items":260},"つなげる",[261,266,270,275,280],{"text":262,"config":263},"GitLabサービス",{"href":264,"dataGaName":265,"dataGaLocation":44},"/ja-jp/services/","services",{"text":267,"config":268},"コミュニティ",{"href":269,"dataGaName":22,"dataGaLocation":44},"/community/",{"text":271,"config":272},"フォーラム",{"href":273,"dataGaName":274,"dataGaLocation":44},"https://forum.gitlab.com/","forum",{"text":276,"config":277},"イベント",{"href":278,"dataGaName":279,"dataGaLocation":44},"/events/","events",{"text":281,"config":282},"パートナー",{"href":283,"dataGaName":284,"dataGaLocation":44},"/ja-jp/partners/","partners",{"config":286,"text":289,"image":290,"link":294},{"background":287,"textColor":288},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":291,"config":292},"ソースプロモカード",{"src":293},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":295,"config":296},"最新情報を読む",{"href":297,"dataGaName":298,"dataGaLocation":44},"/ja-jp/the-source/","the source",{"text":300,"config":301,"menu":303},"会社情報",{"dataNavLevelOne":302},"company",{"type":95,"columns":304},[305],{"items":306},[307,312,318,320,325,330,335,340,345,350,355],{"text":308,"config":309},"GitLabについて",{"href":310,"dataGaName":311,"dataGaLocation":44},"/ja-jp/company/","about",{"text":313,"config":314,"footerGa":317},"採用情報",{"href":315,"dataGaName":316,"dataGaLocation":44},"/jobs/","jobs",{"dataGaName":316},{"text":276,"config":319},{"href":278,"dataGaName":279,"dataGaLocation":44},{"text":321,"config":322},"経営陣",{"href":323,"dataGaName":324,"dataGaLocation":44},"/company/team/e-group/","leadership",{"text":326,"config":327},"チーム",{"href":328,"dataGaName":329,"dataGaLocation":44},"/company/team/","team",{"text":331,"config":332},"ハンドブック",{"href":333,"dataGaName":334,"dataGaLocation":44},"https://handbook.gitlab.com/","handbook",{"text":336,"config":337},"投資家向け情報",{"href":338,"dataGaName":339,"dataGaLocation":44},"https://ir.gitlab.com/","investor relations",{"text":341,"config":342},"トラストセンター",{"href":343,"dataGaName":344,"dataGaLocation":44},"/ja-jp/security/","trust center",{"text":346,"config":347},"AI Transparency Center",{"href":348,"dataGaName":349,"dataGaLocation":44},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":351,"config":352},"ニュースレター",{"href":353,"dataGaName":354,"dataGaLocation":44},"/company/contact/#contact-forms","newsletter",{"text":356,"config":357},"プレス",{"href":358,"dataGaName":359,"dataGaLocation":44},"/press/","press",{"text":51,"config":361,"menu":362},{"dataNavLevelOne":302},{"type":95,"columns":363},[364],{"items":365},[366,369,374],{"text":51,"config":367},{"href":53,"dataGaName":368,"dataGaLocation":44},"talk to sales",{"text":370,"config":371},"サポートを受ける",{"href":372,"dataGaName":373,"dataGaLocation":44},"https://support.gitlab.com","support portal",{"text":375,"config":376},"カスタマーポータル",{"href":377,"dataGaName":378,"dataGaLocation":44},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":380,"login":381,"suggestions":388},"閉じる",{"text":382,"link":383},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":384,"config":385},"GitLab.com",{"href":58,"dataGaName":386,"dataGaLocation":387},"search login","search",{"text":389,"default":390},"提案",[391,393,398,400,404,408],{"text":75,"config":392},{"href":80,"dataGaName":75,"dataGaLocation":387},{"text":394,"config":395},"コード提案（AI）",{"href":396,"dataGaName":397,"dataGaLocation":387},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":111,"config":399},{"href":113,"dataGaName":111,"dataGaLocation":387},{"text":401,"config":402},"GitLab on AWS",{"href":403,"dataGaName":401,"dataGaLocation":387},"/ja-jp/partners/technology-partners/aws/",{"text":405,"config":406},"GitLab on Google Cloud",{"href":407,"dataGaName":405,"dataGaLocation":387},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":409,"config":410},"GitLabを選ぶ理由",{"href":88,"dataGaName":411,"dataGaLocation":387},"Why GitLab?",{"freeTrial":413,"mobileIcon":417,"desktopIcon":422,"secondaryButton":425},{"text":46,"config":414},{"href":415,"dataGaName":49,"dataGaLocation":416},"https://gitlab.com/-/trials/new/","nav",{"altText":418,"config":419},"GitLabアイコン",{"src":420,"dataGaName":421,"dataGaLocation":416},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":418,"config":423},{"src":424,"dataGaName":421,"dataGaLocation":416},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":208,"config":426},{"href":427,"dataGaName":428,"dataGaLocation":416},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/get-started/","get started",{"freeTrial":430,"mobileIcon":434,"desktopIcon":436},{"text":431,"config":432},"GitLab Duoの詳細について",{"href":80,"dataGaName":433,"dataGaLocation":416},"gitlab duo",{"altText":418,"config":435},{"src":420,"dataGaName":421,"dataGaLocation":416},{"altText":418,"config":437},{"src":424,"dataGaName":421,"dataGaLocation":416},{"button":439,"mobileIcon":444,"desktopIcon":446},{"text":440,"config":441},"/switch",{"href":442,"dataGaName":443,"dataGaLocation":416},"#contact","switch",{"altText":418,"config":445},{"src":420,"dataGaName":421,"dataGaLocation":416},{"altText":418,"config":447},{"src":448,"dataGaName":421,"dataGaLocation":416},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":450,"mobileIcon":455,"desktopIcon":457},{"text":451,"config":452},"価格ページに戻る",{"href":195,"dataGaName":453,"dataGaLocation":416,"icon":454},"back to pricing","GoBack",{"altText":418,"config":456},{"src":420,"dataGaName":421,"dataGaLocation":416},{"altText":418,"config":458},{"src":424,"dataGaName":421,"dataGaLocation":416},{"title":460,"button":461,"config":466},"エージェント型AIがソフトウェア配信をどのように変革するかをご覧ください",{"text":462,"config":463},"6月10日のGitLab Transcendに申し込む",{"href":464,"dataGaName":465,"dataGaLocation":44},"/ja-jp/releases/whats-new/#sign-up","transcend event",{"layout":467,"icon":468,"disabled":15},"release","AiStar",{"data":470},{"text":471,"source":472,"edit":478,"contribute":483,"config":488,"items":493,"minimal":696},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":473,"config":474},"ページのソースを表示",{"href":475,"dataGaName":476,"dataGaLocation":477},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":479,"config":480},"このページを編集",{"href":481,"dataGaName":482,"dataGaLocation":477},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":484,"config":485},"ご協力をお願いします",{"href":486,"dataGaName":487,"dataGaLocation":477},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":489,"facebook":490,"youtube":491,"linkedin":492},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[494,539,592,635,662],{"title":193,"links":495,"subMenu":510},[496,500,505],{"text":497,"config":498},"プランの表示",{"href":195,"dataGaName":499,"dataGaLocation":477},"view plans",{"text":501,"config":502},"Premiumを選ぶ理由",{"href":503,"dataGaName":504,"dataGaLocation":477},"/ja-jp/pricing/premium/","why premium",{"text":506,"config":507},"Ultimateを選ぶ理由",{"href":508,"dataGaName":509,"dataGaLocation":477},"/ja-jp/pricing/ultimate/","why ultimate",[511],{"title":51,"links":512},[513,515,517,519,524,529,534],{"text":51,"config":514},{"href":53,"dataGaName":54,"dataGaLocation":477},{"text":370,"config":516},{"href":372,"dataGaName":373,"dataGaLocation":477},{"text":375,"config":518},{"href":377,"dataGaName":378,"dataGaLocation":477},{"text":520,"config":521},"ステータス",{"href":522,"dataGaName":523,"dataGaLocation":477},"https://status.gitlab.com/","status",{"text":525,"config":526},"利用規約",{"href":527,"dataGaName":528,"dataGaLocation":477},"/terms/","terms of use",{"text":530,"config":531},"プライバシーに関する声明",{"href":532,"dataGaName":533,"dataGaLocation":477},"/ja-jp/privacy/","privacy statement",{"text":535,"config":536},"Cookie 優先設定",{"dataGaName":537,"dataGaLocation":477,"id":538,"isOneTrustButton":28},"cookie preferences","ot-sdk-btn",{"title":91,"links":540,"subMenu":549},[541,545],{"text":542,"config":543},"DevSecOpsプラットフォーム",{"href":73,"dataGaName":544,"dataGaLocation":477},"devsecops platform",{"text":546,"config":547},"AI支援開発",{"href":80,"dataGaName":548,"dataGaLocation":477},"ai-assisted development",[550],{"title":551,"links":552},"トピック",[553,557,562,567,572,577,582,587],{"text":111,"config":554},{"href":555,"dataGaName":556,"dataGaLocation":477},"/ja-jp/topics/ci-cd/","cicd",{"text":558,"config":559},"GitOps",{"href":560,"dataGaName":561,"dataGaLocation":477},"/ja-jp/topics/gitops/","gitops",{"text":563,"config":564},"DevOps",{"href":565,"dataGaName":566,"dataGaLocation":477},"/ja-jp/topics/devops/","devops",{"text":568,"config":569},"バージョン管理",{"href":570,"dataGaName":571,"dataGaLocation":477},"/ja-jp/topics/version-control/","version control",{"text":573,"config":574},"DevSecOps",{"href":575,"dataGaName":576,"dataGaLocation":477},"/ja-jp/topics/devsecops/","devsecops",{"text":578,"config":579},"クラウドネイティブ",{"href":580,"dataGaName":581,"dataGaLocation":477},"/ja-jp/topics/cloud-native/","cloud native",{"text":583,"config":584},"コーディングのためのAI",{"href":585,"dataGaName":586,"dataGaLocation":477},"/ja-jp/topics/devops/ai-for-coding/","ai for coding",{"text":588,"config":589},"エージェント型AI",{"href":590,"dataGaName":591,"dataGaLocation":477},"/ja-jp/topics/agentic-ai/","agentic ai",{"title":593,"links":594},"ソリューション",[595,598,600,605,609,612,615,618,620,622,625,630],{"text":136,"config":596},{"href":131,"dataGaName":597,"dataGaLocation":477},"Application Security Testing",{"text":123,"config":599},{"href":107,"dataGaName":108,"dataGaLocation":477},{"text":601,"config":602},"アジャイル開発",{"href":603,"dataGaName":604,"dataGaLocation":477},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":606,"config":607},"SCM",{"href":120,"dataGaName":608,"dataGaLocation":477},"source code management",{"text":111,"config":610},{"href":113,"dataGaName":611,"dataGaLocation":477},"continuous integration & delivery",{"text":162,"config":613},{"href":164,"dataGaName":614,"dataGaLocation":477},"value stream management",{"text":558,"config":616},{"href":617,"dataGaName":561,"dataGaLocation":477},"/ja-jp/solutions/gitops/",{"text":175,"config":619},{"href":178,"dataGaName":179,"dataGaLocation":477},{"text":181,"config":621},{"href":184,"dataGaName":185,"dataGaLocation":477},{"text":623,"config":624},"公共機関",{"href":190,"dataGaName":191,"dataGaLocation":477},{"text":626,"config":627},"教育",{"href":628,"dataGaName":629,"dataGaLocation":477},"/ja-jp/solutions/education/","education",{"text":631,"config":632},"金融サービス",{"href":633,"dataGaName":634,"dataGaLocation":477},"/ja-jp/solutions/finance/","financial services",{"title":198,"links":636},[637,639,641,643,646,648,650,652,654,656,658,660],{"text":211,"config":638},{"href":213,"dataGaName":214,"dataGaLocation":477},{"text":216,"config":640},{"href":218,"dataGaName":219,"dataGaLocation":477},{"text":221,"config":642},{"href":223,"dataGaName":224,"dataGaLocation":477},{"text":226,"config":644},{"href":228,"dataGaName":645,"dataGaLocation":477},"docs",{"text":249,"config":647},{"href":251,"dataGaName":252,"dataGaLocation":477},{"text":244,"config":649},{"href":246,"dataGaName":247,"dataGaLocation":477},{"text":254,"config":651},{"href":256,"dataGaName":257,"dataGaLocation":477},{"text":262,"config":653},{"href":264,"dataGaName":265,"dataGaLocation":477},{"text":267,"config":655},{"href":269,"dataGaName":22,"dataGaLocation":477},{"text":271,"config":657},{"href":273,"dataGaName":274,"dataGaLocation":477},{"text":276,"config":659},{"href":278,"dataGaName":279,"dataGaLocation":477},{"text":281,"config":661},{"href":283,"dataGaName":284,"dataGaLocation":477},{"title":300,"links":663},[664,666,668,670,672,674,676,680,685,687,689,691],{"text":308,"config":665},{"href":310,"dataGaName":302,"dataGaLocation":477},{"text":313,"config":667},{"href":315,"dataGaName":316,"dataGaLocation":477},{"text":321,"config":669},{"href":323,"dataGaName":324,"dataGaLocation":477},{"text":326,"config":671},{"href":328,"dataGaName":329,"dataGaLocation":477},{"text":331,"config":673},{"href":333,"dataGaName":334,"dataGaLocation":477},{"text":336,"config":675},{"href":338,"dataGaName":339,"dataGaLocation":477},{"text":677,"config":678},"Sustainability",{"href":679,"dataGaName":677,"dataGaLocation":477},"/sustainability/",{"text":681,"config":682},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":683,"dataGaName":684,"dataGaLocation":477},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":341,"config":686},{"href":343,"dataGaName":344,"dataGaLocation":477},{"text":351,"config":688},{"href":353,"dataGaName":354,"dataGaLocation":477},{"text":356,"config":690},{"href":358,"dataGaName":359,"dataGaLocation":477},{"text":692,"config":693},"現代奴隷制の透明性に関する声明",{"href":694,"dataGaName":695,"dataGaLocation":477},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":697},[698,700,703],{"text":525,"config":699},{"href":527,"dataGaName":528,"dataGaLocation":477},{"text":701,"config":702},"Cookieの設定",{"dataGaName":537,"dataGaLocation":477,"id":538,"isOneTrustButton":28},{"text":530,"config":704},{"href":532,"dataGaName":533,"dataGaLocation":477},[706],{"id":707,"title":9,"body":26,"config":708,"content":710,"description":26,"extension":714,"meta":715,"navigation":28,"path":716,"seo":717,"stem":718,"__hash__":719},"blogAuthors/en-us/blog/authors/patrick-steinhardt.yml",{"template":709},"BlogAuthor",{"name":9,"config":711},{"headshot":712,"ctfId":713},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661952/Blog/Author%20Headshots/pks-gitlab-headshot.png","pksgitlab","yml",{},"/en-us/blog/authors/patrick-steinhardt",{},"en-us/blog/authors/patrick-steinhardt","SV9Yd_vW69UbvntDP-SEOV9NKT_VwUAj5nfftf2ElSw",[721,735,750],{"content":722,"config":733},{"heroImage":723,"body":724,"authors":725,"updatedDate":727,"date":728,"title":729,"tags":730,"description":732,"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",[726],"Nick Veenhof","2026-04-23","2026-04-22","GitLab AIハッカソン2026：受賞者発表",[731,22],"AI/ML","約7,000人の開発者がGitLab Duo Agent Platform上で600以上のAIエージェントとフローを構築したハッカソンの結果をご紹介。",{"featured":15,"template":13,"slug":734},"gitlab-ai-hackathon-2026-meet-the-winners",{"content":736,"config":748},{"title":737,"description":738,"authors":739,"heroImage":741,"tags":742,"category":11,"date":746,"body":747},"git mergeコマンドの基本を徹底解説","この記事では、git mergeコマンドについてコマンドの基本的な使い方からリクエストコードまで解説します。",[740],"GitLab Team","https://res.cloudinary.com/about-gitlab-com/image/upload/v1754287290/averr2ecwl01q2f9lknf.jpg",[743,21,744,745],"collaboration","tutorial","workflow","2025-08-04","## 目次\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合同会社 カスタマーサクセス本部 カスタマーサクセスエンジニア）*",{"template":13,"slug":749,"featured":28},"git-merge-command-overview",{"content":751,"config":761},{"title":752,"description":753,"authors":754,"heroImage":755,"tags":756,"category":11,"date":759,"body":760},"オープンソースソフトウェア（OSS）とは？詳しく解説​","オープンソースの意味や、メリットとデメリットについて、分かりやすく解説します。",[740],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752720740/g9x8oi988xuhioglpczi.jpg",[743,22,757,758],"open source","security","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合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",{"template":13,"slug":762,"featured":28},"what-is-open-source",{"promotions":764},[765,779,791,802],{"id":766,"categories":767,"header":769,"text":770,"button":771,"image":776},"ai-modernization",[768],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":772,"config":773},"Get your AI maturity score",{"href":774,"dataGaName":775,"dataGaLocation":252},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":777},{"src":778},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":780,"categories":781,"header":783,"text":770,"button":784,"image":788},"devops-modernization",[782,576],"product","Are you just managing tools or shipping innovation?",{"text":785,"config":786},"Get your DevOps maturity score",{"href":787,"dataGaName":775,"dataGaLocation":252},"/assessments/devops-modernization-assessment/",{"config":789},{"src":790},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":792,"categories":793,"header":794,"text":770,"button":795,"image":799},"security-modernization",[758],"Are you trading speed for security?",{"text":796,"config":797},"Get your security maturity score",{"href":798,"dataGaName":775,"dataGaLocation":252},"/assessments/security-modernization-assessment/",{"config":800},{"src":801},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":803,"paths":804,"header":807,"text":808,"button":809,"image":814},"github-azure-migration",[805,806],"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":810,"config":811},"See how GitLab compares to GitHub",{"href":812,"dataGaName":813,"dataGaLocation":252},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":815},{"src":790},{"header":817,"blurb":818,"button":819,"secondaryButton":823},"今すぐ開発をスピードアップ","DevSecOpsに特化したインテリジェントオーケストレーションプラットフォームで実現できることをご確認ください。\n",{"text":46,"config":820},{"href":821,"dataGaName":49,"dataGaLocation":822},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/ja-jp/","feature",{"text":51,"config":824},{"href":53,"dataGaName":54,"dataGaLocation":822},1777934848197]