[{"data":1,"prerenderedAt":757},["ShallowReactive",2],{"/ja-jp/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery":3,"navigation-ja-jp":42,"banner-ja-jp":441,"footer-ja-jp":451,"blog-post-authors-ja-jp-Daniel Helfand":655,"blog-related-posts-ja-jp-how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery":669,"assessment-promotions-ja-jp":708,"next-steps-ja-jp":748},{"id":4,"title":5,"authorSlugs":6,"body":8,"categorySlug":9,"config":10,"content":14,"description":8,"extension":29,"isFeatured":12,"meta":30,"navigation":31,"path":32,"publishedDate":20,"seo":33,"stem":37,"tagSlugs":38,"__hash__":41},"blogPosts/ja-jp/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery.yml","How To Use Oci Images As The Source Of Truth For Continuous Delivery",[7],"daniel-helfand",null,"open-source",{"slug":11,"featured":12,"template":13},"how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery",false,"BlogPost",{"title":15,"description":16,"authors":17,"heroImage":19,"date":20,"body":21,"category":9,"tags":22},"継続的デリバリーにおける信頼できる情報源としてOCIイメージを活用する方法","GitOpsワークフローの一環としてOpen Container Initiative（OCI）イメージを活用する利点、およびKubernetesへのデプロイを簡素化するためにGitLabが提供する多くの機能について詳しくご紹介します。",[18],"Daniel Helfand","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097601/Blog/Hero%20Images/Blog/Hero%20Images/REFERENCE%20-%20Use%20this%20page%20as%20a%20reference%20for%20thumbnail%20sizes_76Tn5jFmEHY5LFj8RdDjNY_1750097600692.png","2025-02-19","gitリポジトリをデプロイメントアーティファクトとして使用しない場合でも、それを[GitOps](https://about.gitlab.com/ja-jp/topics/gitops/)と呼ぶのは適切なのでしょうか？gitは依然としてGitOpsワークフローの中心的な要素ですが、近年では、インフラ定義をOpen Container Initiative（OCI）アーティファクトとしてコンテナレジストリに保存し、それをGitOpsデプロイのソース（情報源）とする手法が広まりつつあります。この記事では、この傾向の背後にある考え方、およびGitLabの機能がどのようにGitOpsワークフローの進化を支えているのかについて詳しくご説明します。\n\n## GitOpsとは？\n\n[OpenGitOps](https://opengitops.dev/)プロジェクトでは、GitOpsの実践に関する以下の[4つの原則](https://opengitops.dev/#principles)を定義しています。\n- [GitOpsで管理されるシステム](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#software-system)は、[望ましい状態が宣言的に表現](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#declarative-description)されていること。\n- 望ましい状態は、不変性とバージョン管理が保証される形で保存され、完全なバージョン履歴が保持されていること。\n- ソフトウェアエージェントは、望ましい状態の宣言をソースから自動的にプルすること。\n- ソフトウェアエージェントは、実際のシステム状態を[継続的](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#continuous)に監視し、[望ましい状態の適用を試みる](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#continuous)こと。\n\nGitOpsの一例として、マイクロサービスのKubernetesマニフェストをGitLabプロジェクトに保存することが挙げられます。これらのKubernetesリソースは、マイクロサービスがデプロイされたKubernetesクラスター上で実行されている[コントローラー](https://kubernetes.io/docs/concepts/architecture/controller/)によって継続的に調整されます。これにより、エンジニアは通常のコード作業と同じワークフローを使用してインフラを管理できます。たとえば、マージリクエストを作成し、変更を加えてレビューしたり、変更にバージョン管理を適用することができます。GitOpsは、[構成ドリフトを防ぐ](https://about.gitlab.com/topics/gitops/#cicd)といった運用上の利点もあり、エンジニアが特定の展開結果に至った変更を監査するのにも役立ちます。\n\n## GitOpsワークフローにおけるgitの利点と制限\n\ngitはGitOpsワークフローにおいて不可欠な要素ではありますが、もともとgitリポジトリはGitOpsコントローラによってデプロイされることを前提に設計されたものではありません。gitによってエンジニア同士が連携しながらインフラに変更を加えたり、その後変更を監査したりすることはできます。しかし、コントローラーが正常にデプロイを実行するために、gitリポジトリ全体をダウンロードする必要はありません。GitOpsコントローラーが必要とするのは、特定の環境のインフラ定義だけです。\n\nさらに、デプロイプロセスにおいて重要なのは、デプロイの変更が信頼できるソースから行われたものであることを確認するために、[デプロイに署名して検証](https://docs.sigstore.dev/about/overview/#why-cryptographic-signing)することです。Gitのコミットは、GitOpsコントローラーによって署名・検証することが可能ですが、コミットはデプロイに関連しない他の詳細（ドキュメントの変更、他の環境の更新、Gitリポジトリの再構成など）を含むこともあります。また、1回のデプロイが複数のコミットにまたがる場合があるため、デプロイ全体が十分に反映しきれないこともあります。これもまた、このgit機能が設計されていないケースのように感じます。\n\nGitOpsワークフローにおけるgitのもう一つの課題は、想定以上に自動化が進んでしまう可能性があることです。監視しているブランチに変更をマージすると、すぐにデプロイされてしまいます。これは、gitの外側にプロセスを制御する仕組みがないためです。たとえば、金曜日の午後遅くにデプロイが行われないようにするにはどうすればよいでしょうか？あるいは、デプロイ担当のチームが特定のGitLabプロジェクトで変更をマージする権限を持っていない場合、どう対処すればよいのでしょうか？OCIイメージを使用することで、プロセスにパイプラインが追加され、[承認やデプロイの停止](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)といったデリバリー制御の機能を活用できるようになります。\n\n## OCIイメージ\n\n[Open Container Initiative](https://opencontainers.org/)は、コンテナ形式に関する標準を定義するために貢献してきました。多くのエンジニアは、Dockerfileを使用してコンテナイメージを作成することに慣れていますが、Kubernetesマニフェストをコンテナレジストリに保存することにはあまり馴染みがないかもしれません。[GitLabのコンテナレジストリ](https://docs.gitlab.com/ee/user/packages/container_registry/)はOCI準拠であるため、特定の環境向けのKubernetesマニフェストをコンテナレジストリにプッシュすることができます。これにより、[Flux CD](https://about.gitlab.com/blog/why-did-we-choose-to-integrate-fluxcd-with-gitlab/)のようなGitOpsコントローラーは、gitリポジトリ全体をクローンすることなく、このOCIアーティファクトに保存されたマニフェストを利用してデプロイを実行できます。\n\nGitOpsワークフローでは、gitリポジトリにマイクロサービスがデプロイされるすべての環境のインフラ定義が含まれていることがよくあります。特定の環境向けのKubernetesマニフェストをパッケージ化することで、Flux CDはデプロイに必要な最小限のファイルだけをダウンロードして、特定の環境へのデプロイを実行できます。\n\n### OCIアーティファクトのセキュリティ上の利点\n\n前述のとおり、環境にデプロイされるアーティファクトに署名し、検証することで、ソフトウェアプロジェクトのセキュリティが一層強化されます。Kubernetesマニフェストがコンテナレジストリにプッシュされた後、[Sigstore Cosign](https://docs.sigstore.dev/quickstart/quickstart-cosign/)のようなツールを使用してOCIイメージに秘密鍵で署名できます。この秘密鍵は、GitLabプロジェクト内の[CI/CD変数](https://docs.gitlab.com/ee/ci/variables/)として安全に保存できます。その後、Flux CDはKubernetesクラスターに保存された公開鍵を使用して、デプロイが信頼できるソースから来ていることを確認できます。\n\n## GitLabを使ってOCIイメージをプッシュして署名する方法\n\nGitLabは、OCIイメージのパッケージ化、署名、デプロイのプロセスを簡素化する多くの機能を提供しています。GitOpsワークフローにおけるGitLabプロジェクト構成の一般的な方法は、各マイクロサービスのコード用に個別のGitLabプロジェクトを用意し、すべてのマイクロサービスに共通する単一のインフラリポジトリを持つというものです。アプリケーションが`n`個のマイクロサービスで構成されている場合、アプリケーションには`n + 1`個のGitLabプロジェクトが必要になります。\n\nコードプロジェクトで作成されるアーティファクトは、通常、アプリケーションをパッケージ化するために使用されるコンテナイメージです。インフラプロジェクトまたはデリバリープロジェクトには、各マイクロサービスをスケールさせ、トラフィックを提供するために必要なリソースを定義したKubernetesマニフェストが含まれます。このプロジェクトで作成されるアーティファクトは通常、アプリケーションと他のマニフェストをKubernetesにデプロイするために使用されるOCIイメージです。\n\nこの構成では、環境の分離はKubernetesマニフェストを別々のフォルダに定義することで行われます。これらのフォルダは、アプリケーションをホストする環境（開発、ステージング、本番など）を表します。コードプロジェクトに変更が加えられ、新しいコンテナイメージがプッシュされた場合、その変更をGitLabのFlux CDとのインテグレーションを使ってデプロイするために必要なのは、環境フォルダ内のマニフェストを編集して新しいイメージ参照を追加し、マージリクエストを作成することだけです。マージリクエストのレビュー、承認、マージが実行されると、デリバリープロジェクトのCI/CDジョブが新しいOCIイメージをプッシュし、Flux CDがそれを受け取って新しい環境にデプロイします。\n\n![OCIイメージ - フローチャート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097611/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097611046.png)\n\nOCIイメージへの署名は、CosignをプロジェクトのCI/CDジョブに組み込むだけで簡単に行えます。以下のコマンドをローカルで実行することで、Cosignを使って新しい公開鍵と秘密鍵を生成できます。その際は、[glab CLI](https://gitlab.com/gitlab-org/cli/#installation)を使ってGitLabインスタンスにログインし、Cosignコマンド内の[`PROJECT_ID`]を[デリバリープロジェクトのID](https://docs.gitlab.com/ee/user/project/working_with_projects.html#access-a-project-by-using-the-project-id)に置き換えてください。\n\n```shell\nglab auth login\ncosign generate-key-pair gitlab://[PROJECT_ID]\n```\n\ncosignコマンドが正常に実行されると、`COSIGN_PUBLIC_KEY`と`COSIGN_PRIVATE_KEY`という名前で、プロジェクトのCI/CD変数セクションにCosignキーが追加されていることが確認できます。\n\n### CI/CDジョブの例\n\nOCIイメージをプッシュするためのGitLab CI/CDジョブは、以下のような形になります。\n\n```yaml\nfrontend-deploy:\n  rules:\n  - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    changes:\n      paths: \n      - manifests/dev/frontend-dev.yaml\n  trigger:\n    include:\n      - component: gitlab.com/components/fluxcd/oci-artifact@0.3.1\n        inputs:\n          version: 0.3.1\n          kubernetes_agent_reference: gitlab-da/projects/tanuki-bank/flux-config:dev\n          registry_image_url: \"oci://$CI_REGISTRY_IMAGE/frontend\"\n          image_tag: dev\n          manifest_path: ./manifests/dev/frontend-dev.yaml\n          flux_oci_repo_name: frontend\n          flux_oci_namespace_name: frontend-dev\n          signing_private_key: \"$COSIGN_PRIVATE_KEY\" \n\n```\n\n[GitLab CI/CDカタログ](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/)には、GitLabが管理する[CI/CDコンポーネント（OCIアーティファクトおよびFlux CD向け）](https://gitlab.com/explore/catalog/components/fluxcd)が用意されています。このコンポーネントにより、開発チームはKubernetesマニフェストをOCIイメージとしてGitLabのコンテナレジストリや外部コンテナレジストリにプッシュし、Cosignを使用してOCIイメージに署名を行い、Flux CDを通じて新しくプッシュされたイメージをすぐに環境に同期することができます。 \n\n上記の例では、Flux CD `component`がGitLabプロジェクトの`.gitlab-ci.yml`ファイル内に含まれています。コンポーネントの入力パラメータを使って、ユーザーはイメージのプッシュ先レジストリ（すなわち`registry_image_url`と`image tag`）、プッシュ対象となるKubernetesマニフェストのファイルパス（すなわち`manifest_path`）、イメージの署名に使用するCosignの秘密鍵（すなわち`signing_private_key`）、そして環境への更新同期に必要なKubernetes名前空間とFlux CDの [OCIRepository](https://fluxcd.io/flux/components/source/ocirepositories/)名（すなわち`flux_oci_namespace_name`と`flux_oci_repo_name`）を定義できます。\n\n`kubernetes_agent_reference`を使用することで、各GitLabプロジェクトに`kubeconfig` CI/CD変数を個別に保存することなく、GitLab CI/CDジョブがKubernetesクラスターへアクセスするために必要な`kubeconfig`の権限を継承できるようになります。[Kubernetes向けGitLabエージェント](https://docs.gitlab.com/ee/user/clusters/agent/)をセットアップすることで、同じ[GitLabグループ](https://docs.gitlab.com/ee/user/group/)内のすべてのプロジェクトのCI/CDジョブに、Kubernetesクラスターへのデプロイ権限を継承させるように設定できます。\n\nKubernetesエージェントのコンテキストは、通常、GitLabグループ内でKubernetes向けGitLabエージェントを設定している場所で構成されます。この設定は、通常、Flux CDを管理しているプロジェクトで行うことが推奨されています。CI/CDアクセス向けのエージェント設定について詳しくは、[CI/CDワークフローのドキュメント](https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html)をご覧ください。\n\n`$COSIGN_PRIVATE_KEY`、`$FLUX_OCI_REPO_NAME`、`$FRONTEND_DEV_NAMESPACE`といった変数は、機密性の高い情報をCI/CDログ上でマスキングしつつ、簡単にアクセスできるようにするためにCI/CD変数として保存されています。`$CI_REGISTRY_IMAGE`は、GitLabジョブでデフォルトで利用可能な変数で、対象のGitLabプロジェクトのコンテナレジストリを示します。\n\n### OCIイメージのデプロイ\n\n[Flux CDをGitLabプロジェクトと組み合わせて使用する](https://docs.gitlab.com/ee/user/clusters/agent/gitops/flux_tutorial.html)ことで、マイクロサービスの各環境へのデプロイと署名の検証を自動化できます。Flux CDをGitLabプロジェクトと連携するように設定したら、プッシュしたOCIイメージを同期するために、以下のKubernetesカスタムリソース定義 [CRD](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)をプロジェクトに追加できます。\n\n```yaml\napiVersion: v1\nkind: Namespace\nmetadata:\n  name: frontend-dev\n  labels:\n    name: frontend-dev\n---\napiVersion: bitnami.com/v1alpha1\nkind: SealedSecret\nmetadata:\n  name: cosign-public-key\n  namespace: frontend-dev\nspec:\n  encryptedData:\n    cosign.pub: AgAKgLf4VbVzJOmr6++k81LlFayx88AELaUQFNOaXmBF4G+fBfBYeABl0skNvMAa1UrPVNSfMIHgFoYHoO96g576a+epk6V6glOI+++XvYbfsygof3GGxe0nL5Qh2b3ge0fNpyd0kTPSjTj0YUhRhKtMGMRSRw1jrwhNcGxCHK+Byibs52v8Np49KsIkeZKbzLdgYABkrv+k0j7hQM+jR180NpG+2UiRvaXpPuogxkbj61FEqWGrJHk8IVyfl3eh+YhoXxOHGDqko6SUC+bUZPDBlU6yKegO0/8Zq3hwulrSEsEjzRZNK+RFVMOLWWuC6h+WGpYhAMcsZPwjjJ/y29KLNa/YeqkN/cdk488QyEFc6ehCxzhH67HxIn2PDa+KkEOTv2TuycGF+Q00jKIizXF+IwLx/oRb3pTCF0AoAY8D8N3Ey+KfkOjsBON7gGID8GbQiJqX2IgIZxFMk0JRzxbRKOEqn+guLd5Shj7CD1a1Mkk0DxBdbqrGv2XNYUaFPI7xd3rZXUJZlnv+fsmwswsiGWRuXwim45HScWzQnfgLAe7tv3spVEGeaO5apl6d89uN21PBQnfE/zyugB//7ZW9tSp6+CSMyc5HynxI8diafqiwKPgvzLmVWRnkvxJijoXicRr3sCo5RudZPSlnjfd7CKdhwEVvLl7dRR4e/XBMdxCzk1p52Pl+3/kJR+LJii5+iwOpYrpVltSZdzc/3qRd19yMpc9PWpXYi7HxTb24EOQ25i21eDJY1ceplDN6bRtop2quzkjlwVeE2i4cEsX/YG8QBtQbop/3fjiAjKaED3QH3Ul0PECS9ARTScSkcOL3I00Xpp8DyD+xH0/i9wCBRDmH3yKX18C8VrMq02ALSnlP7WCVVjCPzubqKx2LPZRxK9EG0fylwv/vWQzTUUwfbPQZsd4c75bSTsTvxqp/UcFaXA==\n  template:\n    metadata:\n      name: cosign-public-key\n      namespace: frontend-dev\n---\napiVersion: source.toolkit.fluxcd.io/v1beta2\nkind: OCIRepository\nmetadata:\n    name: frontend\n    namespace: frontend-dev\nspec:\n    interval: 1m\n    url: oci://registry.gitlab.com/gitlab-da/projects/tanuki-bank/tanuki-bank-delivery/frontend\n    ref:\n        tag: dev\n    verify:\n      provider: cosign\n      secretRef:\n        name: cosign-public-key\n---\napiVersion: kustomize.toolkit.fluxcd.io/v1\nkind: Kustomization\nmetadata:\n    name: frontend\n    namespace: frontend-dev\nspec:\n    interval: 1m\n    targetNamespace: frontend-dev\n    path: \".\"\n    sourceRef:\n        kind: OCIRepository\n        name: frontend\n    prune: true\n\n``` \n \n[`Kustomization`](https://fluxcd.io/flux/components/kustomize/kustomizations/)リソースを使用することで、Kubernetesマニフェストをさらにカスタマイズできるほか、リソースをデプロイする対象のネームスペースも指定することができます。Flux CDの`OCIRepository`リソースでは、定期的に同期する対象となるOCIイメージのリポジトリ参照およびタグを指定できます。また、`verify.provider`と`verify.secretRef`というプロパティがあることに気づくでしょう。これらのフィールドを使うことで、クラスターにデプロイされるOCIイメージが、先ほどのCI/CDジョブで使用されたCosignの秘密鍵によって署名されたものであることを検証できます。\n\n公開鍵は、`OCIRepository`リソースと同じネームスペース内に格納する必要がある、[Kubernetesシークレット](https://kubernetes.io/docs/concepts/configuration/secret/)に保存しなければなりません。このシークレットをFlux CDによって管理し、平文で保存しないようにするには、値を暗号化してクラスター側のコントローラーで復号させるために、[SealedSecrets](https://fluxcd.io/flux/guides/sealed-secrets/)の使用を検討しましょう。\n\nSealedSecretsを使わないより簡単な方法としては、[`kubectl CLI`](https://kubernetes.io/docs/reference/kubectl/)を使用して[GitLab CI/CDジョブでシークレットをデプロイする](https://docs.gitlab.com/ee/user/clusters/agent/getting_started_deployments.html)方法があります。SealedSecretを使用しない方法では、上記で使用していたSealedSecretを削除し、新しいOCIイメージをプッシュするジョブを実行する前に、公開鍵のシークレットをデプロイするジョブを実行するだけです。これにより、シークレットがGitLab上で安全に管理され、クラスター内でOCIRepositoryから正常にアクセスできるようになります。このアプローチは比較的シンプルですが、本番環境でのシークレット管理には適していないことにご留意ください。 \n\n## OCI、GitLab、およびGitOpsの利点\n\nOCIアーティファクトを活用することで、GitOpsチームはセキュリティ面での利点を得ながら、デプロイを最小限に抑えることができます。ユーザーは、インフラの信頼できる情報源としてgitを活用できる点や、プロジェクトでのコラボレーションが可能になる点など、gitがもたらすあらゆる利点を引き続き享受できます。OCIイメージは、GitOpsにおけるデプロイの側面を強化する新たなパッケージ化手法を提供します。\n\nGitLab は、GitOpsワークフローをよりシンプルにするための利用体験を提供できるよう、ユーザーやクラウドネイティブコミュニティから継続的に学び続けています。このブログでご紹介した機能をお使いになるには、[GitLab Ultimateの無料トライアル](https://about.gitlab.com/free-trial/)にお申込みください。これらのツールに関する皆さまのご利用体験についても、ぜひお聞かせください。フィードバックは[コミュニティフォーラム](https://forum.gitlab.com/t/oci-images-as-source-of-truth-for-gitops-with-gitlab/120965)にて受け付けています。\n",[23,24,25,26,27,28],"CI/CD","open source","kubernetes","GitOps","git","tutorial","yml",{},true,"/ja-jp/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery",{"title":15,"description":16,"ogTitle":15,"ogDescription":16,"noIndex":12,"ogImage":19,"ogUrl":34,"ogSiteName":35,"ogType":36,"canonicalUrls":34},"https://about.gitlab.com/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery","https://about.gitlab.com","article","ja-jp/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery",[39,9,25,40,27,28],"cicd","gitops","um4z7qEXCRXAeugUtrGvHl6Xeh1jmSj64IihVWtWnHA",{"data":43},{"logo":44,"freeTrial":49,"sales":54,"login":59,"items":64,"search":371,"minimal":404,"duo":421,"pricingDeployment":431},{"config":45},{"href":46,"dataGaName":47,"dataGaLocation":48},"/ja-jp/","gitlab logo","header",{"text":50,"config":51},"無料トライアルを開始",{"href":52,"dataGaName":53,"dataGaLocation":48},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":55,"config":56},"お問い合わせ",{"href":57,"dataGaName":58,"dataGaLocation":48},"/ja-jp/sales/","sales",{"text":60,"config":61},"サインイン",{"href":62,"dataGaName":63,"dataGaLocation":48},"https://gitlab.com/users/sign_in/","sign in",[65,92,187,192,293,353],{"text":66,"config":67,"cards":69},"プラットフォーム",{"dataNavLevelOne":68},"platform",[70,76,84],{"title":66,"description":71,"link":72},"DevSecOpsに特化したインテリジェントオーケストレーションプラットフォーム",{"text":73,"config":74},"プラットフォームを詳しく見る",{"href":75,"dataGaName":68,"dataGaLocation":48},"/ja-jp/platform/",{"title":77,"description":78,"link":79},"GitLab Duo Agent Platform","ソフトウェアライフサイクル全体を支えるエージェント型AI",{"text":80,"config":81},"GitLab Duoのご紹介",{"href":82,"dataGaName":83,"dataGaLocation":48},"/ja-jp/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":85,"description":86,"link":87},"GitLabが選ばれる理由","エンタープライズがGitLabを選ぶ主な理由をご覧ください",{"text":88,"config":89},"詳細はこちら",{"href":90,"dataGaName":91,"dataGaLocation":48},"/ja-jp/why-gitlab/","why gitlab",{"text":93,"left":31,"config":94,"link":96,"lists":100,"footer":169},"製品",{"dataNavLevelOne":95},"solutions",{"text":97,"config":98},"すべてのソリューションを表示",{"href":99,"dataGaName":95,"dataGaLocation":48},"/ja-jp/solutions/",[101,125,147],{"title":102,"description":103,"link":104,"items":109},"自動化","CI/CDと自動化でデプロイを加速",{"config":105},{"icon":106,"href":107,"dataGaName":108,"dataGaLocation":48},"AutomatedCodeAlt","/ja-jp/solutions/delivery-automation/","automated software delivery",[110,113,116,121],{"text":23,"config":111},{"href":112,"dataGaLocation":48,"dataGaName":23},"/ja-jp/solutions/continuous-integration/",{"text":77,"config":114},{"href":82,"dataGaLocation":48,"dataGaName":115},"gitlab duo agent platform - product menu",{"text":117,"config":118},"ソースコード管理",{"href":119,"dataGaLocation":48,"dataGaName":120},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":122,"config":123},"自動化されたソフトウェアデリバリー",{"href":107,"dataGaLocation":48,"dataGaName":124},"Automated software delivery",{"title":126,"description":127,"link":128,"items":133},"セキュリティ","セキュリティを犠牲にすることなくコード作成を高速化",{"config":129},{"href":130,"dataGaName":131,"dataGaLocation":48,"icon":132},"/ja-jp/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[134,138,143],{"text":135,"config":136},"Application Security Testing",{"href":130,"dataGaName":137,"dataGaLocation":48},"Application security testing",{"text":139,"config":140},"ソフトウェアサプライチェーンの安全性",{"href":141,"dataGaLocation":48,"dataGaName":142},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":144,"config":145},"Software Compliance",{"href":146,"dataGaName":144,"dataGaLocation":48},"/ja-jp/solutions/software-compliance/",{"title":148,"link":149,"items":154},"測定",{"config":150},{"icon":151,"href":152,"dataGaName":153,"dataGaLocation":48},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[155,159,164],{"text":156,"config":157},"可視性と測定",{"href":152,"dataGaLocation":48,"dataGaName":158},"Visibility and Measurement",{"text":160,"config":161},"バリューストリーム管理",{"href":162,"dataGaLocation":48,"dataGaName":163},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":165,"config":166},"分析とインサイト",{"href":167,"dataGaLocation":48,"dataGaName":168},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":170,"items":171},"GitLabが活躍する場所",[172,177,182],{"text":173,"config":174},"Enterprise",{"href":175,"dataGaLocation":48,"dataGaName":176},"/ja-jp/enterprise/","enterprise",{"text":178,"config":179},"スモールビジネス",{"href":180,"dataGaLocation":48,"dataGaName":181},"/ja-jp/small-business/","small business",{"text":183,"config":184},"公共機関",{"href":185,"dataGaLocation":48,"dataGaName":186},"/ja-jp/solutions/public-sector/","public sector",{"text":188,"config":189},"価格",{"href":190,"dataGaName":191,"dataGaLocation":48,"dataNavLevelOne":191},"/ja-jp/pricing/","pricing",{"text":193,"config":194,"link":196,"lists":200,"feature":280},"関連リソース",{"dataNavLevelOne":195},"resources",{"text":197,"config":198},"すべてのリソースを表示",{"href":199,"dataGaName":195,"dataGaLocation":48},"/ja-jp/resources/",[201,234,252],{"title":202,"items":203},"はじめに",[204,209,214,219,224,229],{"text":205,"config":206},"インストール",{"href":207,"dataGaName":208,"dataGaLocation":48},"/ja-jp/install/","install",{"text":210,"config":211},"クイックスタートガイド",{"href":212,"dataGaName":213,"dataGaLocation":48},"/ja-jp/get-started/","quick setup checklists",{"text":215,"config":216},"学ぶ",{"href":217,"dataGaLocation":48,"dataGaName":218},"https://university.gitlab.com/","learn",{"text":220,"config":221},"製品ドキュメント",{"href":222,"dataGaName":223,"dataGaLocation":48},"https://docs.gitlab.com/","product documentation",{"text":225,"config":226},"ベストプラクティスビデオ",{"href":227,"dataGaName":228,"dataGaLocation":48},"/ja-jp/getting-started-videos/","best practice videos",{"text":230,"config":231},"インテグレーション",{"href":232,"dataGaName":233,"dataGaLocation":48},"/ja-jp/integrations/","integrations",{"title":235,"items":236},"検索する",[237,242,247],{"text":238,"config":239},"お客様成功事例",{"href":240,"dataGaName":241,"dataGaLocation":48},"/ja-jp/customers/","customer success stories",{"text":243,"config":244},"ブログ",{"href":245,"dataGaName":246,"dataGaLocation":48},"/ja-jp/blog/","blog",{"text":248,"config":249},"リモート",{"href":250,"dataGaName":251,"dataGaLocation":48},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":253,"items":254},"つなげる",[255,260,265,270,275],{"text":256,"config":257},"GitLabサービス",{"href":258,"dataGaName":259,"dataGaLocation":48},"/ja-jp/services/","services",{"text":261,"config":262},"コミュニティ",{"href":263,"dataGaName":264,"dataGaLocation":48},"/community/","community",{"text":266,"config":267},"フォーラム",{"href":268,"dataGaName":269,"dataGaLocation":48},"https://forum.gitlab.com/","forum",{"text":271,"config":272},"イベント",{"href":273,"dataGaName":274,"dataGaLocation":48},"/events/","events",{"text":276,"config":277},"パートナー",{"href":278,"dataGaName":279,"dataGaLocation":48},"/ja-jp/partners/","partners",{"backgroundColor":281,"textColor":282,"text":283,"image":284,"link":288},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":285,"config":286},"ソースプロモカード",{"src":287},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":289,"config":290},"最新情報を読む",{"href":291,"dataGaName":292,"dataGaLocation":48},"/ja-jp/the-source/","the source",{"text":294,"config":295,"lists":297},"会社情報",{"dataNavLevelOne":296},"company",[298],{"items":299},[300,305,311,313,318,323,328,333,338,343,348],{"text":301,"config":302},"GitLabについて",{"href":303,"dataGaName":304,"dataGaLocation":48},"/ja-jp/company/","about",{"text":306,"config":307,"footerGa":310},"採用情報",{"href":308,"dataGaName":309,"dataGaLocation":48},"/jobs/","jobs",{"dataGaName":309},{"text":271,"config":312},{"href":273,"dataGaName":274,"dataGaLocation":48},{"text":314,"config":315},"経営陣",{"href":316,"dataGaName":317,"dataGaLocation":48},"/company/team/e-group/","leadership",{"text":319,"config":320},"チーム",{"href":321,"dataGaName":322,"dataGaLocation":48},"/company/team/","team",{"text":324,"config":325},"ハンドブック",{"href":326,"dataGaName":327,"dataGaLocation":48},"https://handbook.gitlab.com/","handbook",{"text":329,"config":330},"投資家向け情報",{"href":331,"dataGaName":332,"dataGaLocation":48},"https://ir.gitlab.com/","investor relations",{"text":334,"config":335},"トラストセンター",{"href":336,"dataGaName":337,"dataGaLocation":48},"/ja-jp/security/","trust center",{"text":339,"config":340},"AI Transparency Center",{"href":341,"dataGaName":342,"dataGaLocation":48},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":344,"config":345},"ニュースレター",{"href":346,"dataGaName":347,"dataGaLocation":48},"/company/contact/#contact-forms","newsletter",{"text":349,"config":350},"プレス",{"href":351,"dataGaName":352,"dataGaLocation":48},"/press/","press",{"text":55,"config":354,"lists":355},{"dataNavLevelOne":296},[356],{"items":357},[358,361,366],{"text":55,"config":359},{"href":57,"dataGaName":360,"dataGaLocation":48},"talk to sales",{"text":362,"config":363},"サポートポータル",{"href":364,"dataGaName":365,"dataGaLocation":48},"https://support.gitlab.com","support portal",{"text":367,"config":368},"カスタマーポータル",{"href":369,"dataGaName":370,"dataGaLocation":48},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":372,"login":373,"suggestions":380},"閉じる",{"text":374,"link":375},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":376,"config":377},"GitLab.com",{"href":62,"dataGaName":378,"dataGaLocation":379},"search login","search",{"text":381,"default":382},"提案",[383,385,390,392,396,400],{"text":77,"config":384},{"href":82,"dataGaName":77,"dataGaLocation":379},{"text":386,"config":387},"コード提案（AI）",{"href":388,"dataGaName":389,"dataGaLocation":379},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":23,"config":391},{"href":112,"dataGaName":23,"dataGaLocation":379},{"text":393,"config":394},"GitLab on AWS",{"href":395,"dataGaName":393,"dataGaLocation":379},"/ja-jp/partners/technology-partners/aws/",{"text":397,"config":398},"GitLab on Google Cloud",{"href":399,"dataGaName":397,"dataGaLocation":379},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":401,"config":402},"GitLabを選ぶ理由",{"href":90,"dataGaName":403,"dataGaLocation":379},"Why GitLab?",{"freeTrial":405,"mobileIcon":409,"desktopIcon":414,"secondaryButton":417},{"text":50,"config":406},{"href":407,"dataGaName":53,"dataGaLocation":408},"https://gitlab.com/-/trials/new/","nav",{"altText":410,"config":411},"GitLabアイコン",{"src":412,"dataGaName":413,"dataGaLocation":408},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":410,"config":415},{"src":416,"dataGaName":413,"dataGaLocation":408},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":202,"config":418},{"href":419,"dataGaName":420,"dataGaLocation":408},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/compare/gitlab-vs-github/","get started",{"freeTrial":422,"mobileIcon":427,"desktopIcon":429},{"text":423,"config":424},"GitLab Duoの詳細について",{"href":425,"dataGaName":426,"dataGaLocation":408},"/ja-jp/gitlab-duo/","gitlab duo",{"altText":410,"config":428},{"src":412,"dataGaName":413,"dataGaLocation":408},{"altText":410,"config":430},{"src":416,"dataGaName":413,"dataGaLocation":408},{"freeTrial":432,"mobileIcon":437,"desktopIcon":439},{"text":433,"config":434},"料金ページに戻る",{"href":190,"dataGaName":435,"dataGaLocation":408,"icon":436},"back to pricing","GoBack",{"altText":410,"config":438},{"src":412,"dataGaName":413,"dataGaLocation":408},{"altText":410,"config":440},{"src":416,"dataGaName":413,"dataGaLocation":408},{"title":442,"button":443,"config":448},"エージェント型AIがソフトウェア配信をどのように変革するかをご覧ください",{"text":444,"config":445},"GitLab Transcendを今すぐ視聴",{"href":446,"dataGaName":447,"dataGaLocation":48},"/ja-jp/events/transcend/virtual/","transcend event",{"layout":449,"icon":450},"release","AiStar",{"data":452},{"text":453,"source":454,"edit":460,"contribute":465,"config":470,"items":475,"minimal":647},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":455,"config":456},"ページのソースを表示",{"href":457,"dataGaName":458,"dataGaLocation":459},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":461,"config":462},"このページを編集",{"href":463,"dataGaName":464,"dataGaLocation":459},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":466,"config":467},"ご協力をお願いします",{"href":468,"dataGaName":469,"dataGaLocation":459},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":471,"facebook":472,"youtube":473,"linkedin":474},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[476,499,551,581,616],{"title":66,"links":477,"subMenu":482},[478],{"text":479,"config":480},"DevSecOpsプラットフォーム",{"href":75,"dataGaName":481,"dataGaLocation":459},"devsecops platform",[483],{"title":188,"links":484},[485,489,494],{"text":486,"config":487},"プランの表示",{"href":190,"dataGaName":488,"dataGaLocation":459},"view plans",{"text":490,"config":491},"Premiumを選ぶ理由",{"href":492,"dataGaName":493,"dataGaLocation":459},"/ja-jp/pricing/premium/","why premium",{"text":495,"config":496},"Ultimateを選ぶ理由",{"href":497,"dataGaName":498,"dataGaLocation":459},"/ja-jp/pricing/ultimate/","why ultimate",{"title":500,"links":501},"ソリューション",[502,507,510,512,517,522,526,529,532,535,537,539,541,546],{"text":503,"config":504},"デジタルトランスフォーメーション",{"href":505,"dataGaName":506,"dataGaLocation":459},"/ja-jp/topics/digital-transformation/","digital transformation",{"text":508,"config":509},"セキュリティとコンプライアンス",{"href":130,"dataGaName":137,"dataGaLocation":459},{"text":122,"config":511},{"href":107,"dataGaName":108,"dataGaLocation":459},{"text":513,"config":514},"アジャイル開発",{"href":515,"dataGaName":516,"dataGaLocation":459},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":518,"config":519},"クラウドトランスフォーメーション",{"href":520,"dataGaName":521,"dataGaLocation":459},"/ja-jp/topics/cloud-native/","cloud transformation",{"text":523,"config":524},"SCM",{"href":119,"dataGaName":525,"dataGaLocation":459},"source code management",{"text":23,"config":527},{"href":112,"dataGaName":528,"dataGaLocation":459},"continuous integration & delivery",{"text":160,"config":530},{"href":162,"dataGaName":531,"dataGaLocation":459},"value stream management",{"text":26,"config":533},{"href":534,"dataGaName":40,"dataGaLocation":459},"/ja-jp/solutions/gitops/",{"text":173,"config":536},{"href":175,"dataGaName":176,"dataGaLocation":459},{"text":178,"config":538},{"href":180,"dataGaName":181,"dataGaLocation":459},{"text":183,"config":540},{"href":185,"dataGaName":186,"dataGaLocation":459},{"text":542,"config":543},"教育",{"href":544,"dataGaName":545,"dataGaLocation":459},"/ja-jp/solutions/education/","education",{"text":547,"config":548},"金融サービス",{"href":549,"dataGaName":550,"dataGaLocation":459},"/ja-jp/solutions/finance/","financial services",{"title":193,"links":552},[553,555,557,559,562,564,567,569,571,573,575,577,579],{"text":205,"config":554},{"href":207,"dataGaName":208,"dataGaLocation":459},{"text":210,"config":556},{"href":212,"dataGaName":213,"dataGaLocation":459},{"text":215,"config":558},{"href":217,"dataGaName":218,"dataGaLocation":459},{"text":220,"config":560},{"href":222,"dataGaName":561,"dataGaLocation":459},"docs",{"text":243,"config":563},{"href":245,"dataGaName":246},{"text":565,"config":566},"お客様の成功事例",{"href":240,"dataGaLocation":459},{"text":238,"config":568},{"href":240,"dataGaName":241,"dataGaLocation":459},{"text":248,"config":570},{"href":250,"dataGaName":251,"dataGaLocation":459},{"text":256,"config":572},{"href":258,"dataGaName":259,"dataGaLocation":459},{"text":261,"config":574},{"href":263,"dataGaName":264,"dataGaLocation":459},{"text":266,"config":576},{"href":268,"dataGaName":269,"dataGaLocation":459},{"text":271,"config":578},{"href":273,"dataGaName":274,"dataGaLocation":459},{"text":276,"config":580},{"href":278,"dataGaName":279,"dataGaLocation":459},{"title":582,"links":583},"Company",[584,586,588,590,592,594,596,600,605,607,609,611],{"text":301,"config":585},{"href":303,"dataGaName":296,"dataGaLocation":459},{"text":306,"config":587},{"href":308,"dataGaName":309,"dataGaLocation":459},{"text":314,"config":589},{"href":316,"dataGaName":317,"dataGaLocation":459},{"text":319,"config":591},{"href":321,"dataGaName":322,"dataGaLocation":459},{"text":324,"config":593},{"href":326,"dataGaName":327,"dataGaLocation":459},{"text":329,"config":595},{"href":331,"dataGaName":332,"dataGaLocation":459},{"text":597,"config":598},"Sustainability",{"href":599,"dataGaName":597,"dataGaLocation":459},"/sustainability/",{"text":601,"config":602},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":603,"dataGaName":604,"dataGaLocation":459},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":334,"config":606},{"href":336,"dataGaName":337,"dataGaLocation":459},{"text":344,"config":608},{"href":346,"dataGaName":347,"dataGaLocation":459},{"text":349,"config":610},{"href":351,"dataGaName":352,"dataGaLocation":459},{"text":612,"config":613},"現代奴隷制の透明性に関する声明",{"href":614,"dataGaName":615,"dataGaLocation":459},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":55,"links":617},[618,620,625,627,632,637,642],{"text":55,"config":619},{"href":57,"dataGaName":58,"dataGaLocation":459},{"text":621,"config":622},"サポートを受ける",{"href":623,"dataGaName":624,"dataGaLocation":459},"/support/","get help",{"text":367,"config":626},{"href":369,"dataGaName":370,"dataGaLocation":459},{"text":628,"config":629},"ステータス",{"href":630,"dataGaName":631,"dataGaLocation":459},"https://status.gitlab.com/","status",{"text":633,"config":634},"利用規約",{"href":635,"dataGaName":636,"dataGaLocation":459},"/terms/","terms of use",{"text":638,"config":639},"プライバシーに関する声明",{"href":640,"dataGaName":641,"dataGaLocation":459},"/ja-jp/privacy/","privacy statement",{"text":643,"config":644},"Cookieの設定",{"dataGaName":645,"dataGaLocation":459,"id":646,"isOneTrustButton":31},"cookie preferences","ot-sdk-btn",{"items":648},[649,651,653],{"text":633,"config":650},{"href":635,"dataGaName":636,"dataGaLocation":459},{"text":638,"config":652},{"href":640,"dataGaName":641,"dataGaLocation":459},{"text":643,"config":654},{"dataGaName":645,"dataGaLocation":459,"id":646,"isOneTrustButton":31},[656],{"id":657,"title":18,"body":8,"config":658,"content":660,"description":8,"extension":29,"meta":664,"navigation":31,"path":665,"seo":666,"stem":667,"__hash__":668},"blogAuthors/en-us/blog/authors/daniel-helfand.yml",{"template":659},"BlogAuthor",{"name":18,"config":661},{"headshot":662,"ctfId":663},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662418/Blog/Author%20Headshots/dhelfand.png","b9sRP0HJhdPsOEruWUfih",{},"/en-us/blog/authors/daniel-helfand",{},"en-us/blog/authors/daniel-helfand","U_csW5bNItyLp5wX6zV8xvC4yi-USG4wFxbnBMasIFw",[670,684,696],{"content":671,"config":682},{"date":672,"heroImage":673,"title":674,"authors":675,"category":9,"body":677,"description":678,"tags":679},"2025-08-04","https://res.cloudinary.com/about-gitlab-com/image/upload/v1754287290/averr2ecwl01q2f9lknf.jpg","git mergeコマンドの基本を徹底解説",[676],"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コマンドについてコマンドの基本的な使い方からリクエストコードまで解説します。",[680,27,28,681],"collaboration","workflow",{"featured":31,"template":13,"slug":683},"git-merge-command-overview",{"content":685,"config":694},{"title":686,"description":687,"authors":688,"heroImage":689,"date":690,"body":691,"category":9,"tags":692},"オープンソースソフトウェア（OSS）とは？詳しく解説​","オープンソースの意味や、メリットとデメリットについて、分かりやすく解説します。",[676],"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合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[680,264,24,693],"security",{"featured":31,"template":13,"slug":695},"what-is-open-source",{"content":697,"config":706},{"title":698,"description":699,"authors":700,"heroImage":702,"body":703,"date":704,"category":9,"tags":705},"Git 2.50.0の新機能","git-diff-pairs(1)コマンドや、参照の一括更新を行うためのgit-rev-list(1)オプションなど、GitLabのGitチームとGitコミュニティによるコントリビュートをご紹介します。",[701],"Justin Tobler","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",[27,24,264],{"featured":31,"template":13,"slug":707},"what-s-new-in-git-2-50-0",{"promotions":709},[710,724,737],{"id":711,"categories":712,"header":714,"text":715,"button":716,"image":721},"ai-modernization",[713],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":717,"config":718},"Get your AI maturity score",{"href":719,"dataGaName":720,"dataGaLocation":246},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":722},{"src":723},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":725,"categories":726,"header":729,"text":715,"button":730,"image":734},"devops-modernization",[727,728],"product","devsecops","Are you just managing tools or shipping innovation?",{"text":731,"config":732},"Get your DevOps maturity score",{"href":733,"dataGaName":720,"dataGaLocation":246},"/assessments/devops-modernization-assessment/",{"config":735},{"src":736},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":738,"categories":739,"header":740,"text":715,"button":741,"image":745},"security-modernization",[693],"Are you trading speed for security?",{"text":742,"config":743},"Get your security maturity score",{"href":744,"dataGaName":720,"dataGaLocation":246},"/assessments/security-modernization-assessment/",{"config":746},{"src":747},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"header":749,"blurb":750,"button":751,"secondaryButton":755},"今すぐ開発をスピードアップ","DevSecOpsに特化したインテリジェントオーケストレーションプラットフォームで実現できることをご確認ください。\n",{"text":50,"config":752},{"href":753,"dataGaName":53,"dataGaLocation":754},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":55,"config":756},{"href":57,"dataGaName":58,"dataGaLocation":754},1772652101980]