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