[{"data":1,"prerenderedAt":1036},["ShallowReactive",2],{"/en-us/blog/tags/git/":3,"navigation-ja-jp":19,"banner-ja-jp":436,"footer-ja-jp":449,"git-tag-page-ja-jp":658},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"content":8,"config":10,"_id":12,"_type":13,"title":14,"_source":15,"_file":16,"_stem":17,"_extension":18},"/en-us/blog/tags/git","tags",false,"",{"tag":9,"tagSlug":9},"git",{"template":11},"BlogTag","content:en-us:blog:tags:git.yml","yaml","Git","content","en-us/blog/tags/git.yml","en-us/blog/tags/git","yml",{"_path":20,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"data":22,"_id":432,"_type":13,"title":433,"_source":15,"_file":434,"_stem":435,"_extension":18},"/shared/ja-jp/main-navigation","ja-jp",{"logo":23,"freeTrial":28,"sales":33,"login":38,"items":43,"search":376,"minimal":410,"duo":423},{"config":24},{"href":25,"dataGaName":26,"dataGaLocation":27},"/ja-jp/","gitlab logo","header",{"text":29,"config":30},"無料トライアルを開始",{"href":31,"dataGaName":32,"dataGaLocation":27},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":34,"config":35},"お問い合わせ",{"href":36,"dataGaName":37,"dataGaLocation":27},"/ja-jp/sales/","sales",{"text":39,"config":40},"サインイン",{"href":41,"dataGaName":42,"dataGaLocation":27},"https://gitlab.com/users/sign_in/","sign in",[44,88,187,192,298,358],{"text":45,"config":46,"cards":48,"footer":71},"プラットフォーム",{"dataNavLevelOne":47},"platform",[49,55,63],{"title":45,"description":50,"link":51},"最も包括的かつAIで強化されたDevSecOpsプラットフォーム",{"text":52,"config":53},"プラットフォームを詳しく見る",{"href":54,"dataGaName":47,"dataGaLocation":27},"/ja-jp/platform/",{"title":56,"description":57,"link":58},"GitLab Duo（AI）","開発のすべてのステージでAIを活用し、ソフトウェアをより迅速にビルド",{"text":59,"config":60},"GitLab Duoのご紹介",{"href":61,"dataGaName":62,"dataGaLocation":27},"/ja-jp/gitlab-duo/","gitlab duo ai",{"title":64,"description":65,"link":66},"GitLabが選ばれる理由","GitLabが大企業に選ばれる理由10選",{"text":67,"config":68},"詳細はこちら",{"href":69,"dataGaName":70,"dataGaLocation":27},"/ja-jp/why-gitlab/","why gitlab",{"title":72,"items":73},"利用を開始：",[74,79,84],{"text":75,"config":76},"プラットフォームエンジニアリング",{"href":77,"dataGaName":78,"dataGaLocation":27},"/ja-jp/solutions/platform-engineering/","platform engineering",{"text":80,"config":81},"開発者の経験",{"href":82,"dataGaName":83,"dataGaLocation":27},"/ja-jp/developer-experience/","Developer experience",{"text":85,"config":86},"MLOps",{"href":87,"dataGaName":85,"dataGaLocation":27},"/ja-jp/topics/devops/the-role-of-ai-in-devops/",{"text":89,"left":90,"config":91,"link":93,"lists":97,"footer":169},"製品",true,{"dataNavLevelOne":92},"solutions",{"text":94,"config":95},"すべてのソリューションを表示",{"href":96,"dataGaName":92,"dataGaLocation":27},"/ja-jp/solutions/",[98,124,147],{"title":99,"description":100,"link":101,"items":106},"自動化","CI/CDと自動化でデプロイを加速",{"config":102},{"icon":103,"href":104,"dataGaName":105,"dataGaLocation":27},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[107,111,115,120],{"text":108,"config":109},"CI/CD",{"href":110,"dataGaLocation":27,"dataGaName":108},"/ja-jp/solutions/continuous-integration/",{"text":112,"config":113},"AIアシストによる開発",{"href":61,"dataGaLocation":27,"dataGaName":114},"AI assisted development",{"text":116,"config":117},"ソースコード管理",{"href":118,"dataGaLocation":27,"dataGaName":119},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":121,"config":122},"自動化されたソフトウェアデリバリー",{"href":104,"dataGaLocation":27,"dataGaName":123},"Automated software delivery",{"title":125,"description":126,"link":127,"items":132},"セキュリティ","セキュリティを損なうことなくコードをより迅速に完成",{"config":128},{"href":129,"dataGaName":130,"dataGaLocation":27,"icon":131},"/ja-jp/solutions/security-compliance/","security and compliance","ShieldCheckLight",[133,138,143],{"text":134,"config":135},"Application Security Testing",{"href":136,"dataGaName":137,"dataGaLocation":27},"/solutions/application-security-testing/","Application security testing",{"text":139,"config":140},"ソフトウェアサプライチェーンの安全性",{"href":141,"dataGaLocation":27,"dataGaName":142},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":144,"config":145},"Software Compliance",{"href":146,"dataGaName":144,"dataGaLocation":27},"/solutions/software-compliance/",{"title":148,"link":149,"items":154},"測定",{"config":150},{"icon":151,"href":152,"dataGaName":153,"dataGaLocation":27},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[155,159,164],{"text":156,"config":157},"可視性と測定",{"href":152,"dataGaLocation":27,"dataGaName":158},"Visibility and Measurement",{"text":160,"config":161},"バリューストリーム管理",{"href":162,"dataGaLocation":27,"dataGaName":163},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":165,"config":166},"分析とインサイト",{"href":167,"dataGaLocation":27,"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":27,"dataGaName":176},"/ja-jp/enterprise/","enterprise",{"text":178,"config":179},"スモールビジネス",{"href":180,"dataGaLocation":27,"dataGaName":181},"/ja-jp/small-business/","small business",{"text":183,"config":184},"公共機関",{"href":185,"dataGaLocation":27,"dataGaName":186},"/ja-jp/solutions/public-sector/","public sector",{"text":188,"config":189},"価格",{"href":190,"dataGaName":191,"dataGaLocation":27,"dataNavLevelOne":191},"/ja-jp/pricing/","pricing",{"text":193,"config":194,"link":196,"lists":200,"feature":285},"関連リソース",{"dataNavLevelOne":195},"resources",{"text":197,"config":198},"すべてのリソースを表示",{"href":199,"dataGaName":195,"dataGaLocation":27},"/ja-jp/resources/",[201,234,257],{"title":202,"items":203},"はじめに",[204,209,214,219,224,229],{"text":205,"config":206},"インストール",{"href":207,"dataGaName":208,"dataGaLocation":27},"/ja-jp/install/","install",{"text":210,"config":211},"クイックスタートガイド",{"href":212,"dataGaName":213,"dataGaLocation":27},"/ja-jp/get-started/","quick setup checklists",{"text":215,"config":216},"学ぶ",{"href":217,"dataGaLocation":27,"dataGaName":218},"https://university.gitlab.com/","learn",{"text":220,"config":221},"製品ドキュメント",{"href":222,"dataGaName":223,"dataGaLocation":27},"https://docs.gitlab.com/","product documentation",{"text":225,"config":226},"ベストプラクティスビデオ",{"href":227,"dataGaName":228,"dataGaLocation":27},"/ja-jp/getting-started-videos/","best practice videos",{"text":230,"config":231},"インテグレーション",{"href":232,"dataGaName":233,"dataGaLocation":27},"/ja-jp/integrations/","integrations",{"title":235,"items":236},"検索する",[237,242,247,252],{"text":238,"config":239},"お客様成功事例",{"href":240,"dataGaName":241,"dataGaLocation":27},"/ja-jp/customers/","customer success stories",{"text":243,"config":244},"ブログ",{"href":245,"dataGaName":246,"dataGaLocation":27},"/ja-jp/blog/","blog",{"text":248,"config":249},"リモート",{"href":250,"dataGaName":251,"dataGaLocation":27},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":253,"config":254},"TeamOps",{"href":255,"dataGaName":256,"dataGaLocation":27},"/ja-jp/teamops/","teamops",{"title":258,"items":259},"つなげる",[260,265,270,275,280],{"text":261,"config":262},"GitLabサービス",{"href":263,"dataGaName":264,"dataGaLocation":27},"/ja-jp/services/","services",{"text":266,"config":267},"コミュニティ",{"href":268,"dataGaName":269,"dataGaLocation":27},"/community/","community",{"text":271,"config":272},"フォーラム",{"href":273,"dataGaName":274,"dataGaLocation":27},"https://forum.gitlab.com/","forum",{"text":276,"config":277},"イベント",{"href":278,"dataGaName":279,"dataGaLocation":27},"/events/","events",{"text":281,"config":282},"パートナー",{"href":283,"dataGaName":284,"dataGaLocation":27},"/partners/","partners",{"backgroundColor":286,"textColor":287,"text":288,"image":289,"link":293},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":290,"config":291},"ソースプロモカード",{"src":292},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":294,"config":295},"最新情報を読む",{"href":296,"dataGaName":297,"dataGaLocation":27},"/ja-jp/the-source/","the source",{"text":299,"config":300,"lists":302},"Company",{"dataNavLevelOne":301},"company",[303],{"items":304},[305,310,316,318,323,328,333,338,343,348,353],{"text":306,"config":307},"GitLabについて",{"href":308,"dataGaName":309,"dataGaLocation":27},"/ja-jp/company/","about",{"text":311,"config":312,"footerGa":315},"採用情報",{"href":313,"dataGaName":314,"dataGaLocation":27},"/jobs/","jobs",{"dataGaName":314},{"text":276,"config":317},{"href":278,"dataGaName":279,"dataGaLocation":27},{"text":319,"config":320},"経営陣",{"href":321,"dataGaName":322,"dataGaLocation":27},"/company/team/e-group/","leadership",{"text":324,"config":325},"チーム",{"href":326,"dataGaName":327,"dataGaLocation":27},"/company/team/","team",{"text":329,"config":330},"ハンドブック",{"href":331,"dataGaName":332,"dataGaLocation":27},"https://handbook.gitlab.com/","handbook",{"text":334,"config":335},"投資家向け情報",{"href":336,"dataGaName":337,"dataGaLocation":27},"https://ir.gitlab.com/","investor relations",{"text":339,"config":340},"トラストセンター",{"href":341,"dataGaName":342,"dataGaLocation":27},"/ja-jp/security/","trust center",{"text":344,"config":345},"AI Transparency Center",{"href":346,"dataGaName":347,"dataGaLocation":27},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":349,"config":350},"ニュースレター",{"href":351,"dataGaName":352,"dataGaLocation":27},"/company/contact/","newsletter",{"text":354,"config":355},"プレス",{"href":356,"dataGaName":357,"dataGaLocation":27},"/press/","press",{"text":34,"config":359,"lists":360},{"dataNavLevelOne":301},[361],{"items":362},[363,366,371],{"text":34,"config":364},{"href":36,"dataGaName":365,"dataGaLocation":27},"talk to sales",{"text":367,"config":368},"サポートを受ける",{"href":369,"dataGaName":370,"dataGaLocation":27},"/support/","get help",{"text":372,"config":373},"カスタマーポータル",{"href":374,"dataGaName":375,"dataGaLocation":27},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":377,"login":378,"suggestions":385},"閉じる",{"text":379,"link":380},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":381,"config":382},"GitLab.com",{"href":41,"dataGaName":383,"dataGaLocation":384},"search login","search",{"text":386,"default":387},"提案",[388,391,396,398,402,406],{"text":56,"config":389},{"href":61,"dataGaName":390,"dataGaLocation":384},"GitLab Duo (AI)",{"text":392,"config":393},"コード提案（AI）",{"href":394,"dataGaName":395,"dataGaLocation":384},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":108,"config":397},{"href":110,"dataGaName":108,"dataGaLocation":384},{"text":399,"config":400},"GitLab on AWS",{"href":401,"dataGaName":399,"dataGaLocation":384},"/ja-jp/partners/technology-partners/aws/",{"text":403,"config":404},"GitLab on Google Cloud",{"href":405,"dataGaName":403,"dataGaLocation":384},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":407,"config":408},"GitLabを選ぶ理由",{"href":69,"dataGaName":409,"dataGaLocation":384},"Why GitLab?",{"freeTrial":411,"mobileIcon":415,"desktopIcon":420},{"text":29,"config":412},{"href":413,"dataGaName":32,"dataGaLocation":414},"https://gitlab.com/-/trials/new/","nav",{"altText":416,"config":417},"GitLabアイコン",{"src":418,"dataGaName":419,"dataGaLocation":414},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":416,"config":421},{"src":422,"dataGaName":419,"dataGaLocation":414},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"freeTrial":424,"mobileIcon":428,"desktopIcon":430},{"text":425,"config":426},"GitLab Duoの詳細について",{"href":61,"dataGaName":427,"dataGaLocation":414},"gitlab duo",{"altText":416,"config":429},{"src":418,"dataGaName":419,"dataGaLocation":414},{"altText":416,"config":431},{"src":422,"dataGaName":419,"dataGaLocation":414},"content:shared:ja-jp:main-navigation.yml","Main Navigation","shared/ja-jp/main-navigation.yml","shared/ja-jp/main-navigation",{"_path":437,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"title":438,"button":439,"config":444,"_id":446,"_type":13,"_source":15,"_file":447,"_stem":448,"_extension":18},"/shared/ja-jp/banner","GitLab Duo Agent Platformがパブリックベータ版で利用可能になりました！",{"text":440,"config":441},"ベータ版を試す",{"href":442,"dataGaName":443,"dataGaLocation":27},"/ja-jp/gitlab-duo/agent-platform/","duo banner",{"layout":445},"release","content:shared:ja-jp:banner.yml","shared/ja-jp/banner.yml","shared/ja-jp/banner",{"_path":450,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"data":451,"_id":654,"_type":13,"title":655,"_source":15,"_file":656,"_stem":657,"_extension":18},"/shared/ja-jp/main-footer",{"text":452,"source":453,"edit":459,"contribute":464,"config":469,"items":474,"minimal":646},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":454,"config":455},"ページのソースを表示",{"href":456,"dataGaName":457,"dataGaLocation":458},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":460,"config":461},"このページを編集",{"href":462,"dataGaName":463,"dataGaLocation":458},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":465,"config":466},"ご協力をお願いします",{"href":467,"dataGaName":468,"dataGaLocation":458},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":470,"facebook":471,"youtube":472,"linkedin":473},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[475,498,552,584,618],{"title":45,"links":476,"subMenu":481},[477],{"text":478,"config":479},"DevSecOpsプラットフォーム",{"href":54,"dataGaName":480,"dataGaLocation":458},"devsecops platform",[482],{"title":188,"links":483},[484,488,493],{"text":485,"config":486},"プランの表示",{"href":190,"dataGaName":487,"dataGaLocation":458},"view plans",{"text":489,"config":490},"Premiumを選ぶ理由",{"href":491,"dataGaName":492,"dataGaLocation":458},"/ja-jp/pricing/premium/","why premium",{"text":494,"config":495},"Ultimateを選ぶ理由",{"href":496,"dataGaName":497,"dataGaLocation":458},"/ja-jp/pricing/ultimate/","why ultimate",{"title":499,"links":500},"ソリューション",[501,506,509,511,516,521,525,528,531,536,538,540,542,547],{"text":502,"config":503},"デジタルトランスフォーメーション",{"href":504,"dataGaName":505,"dataGaLocation":458},"/ja-jp/topics/digital-transformation/","digital transformation",{"text":507,"config":508},"セキュリティとコンプライアンス",{"href":136,"dataGaName":137,"dataGaLocation":458},{"text":121,"config":510},{"href":104,"dataGaName":105,"dataGaLocation":458},{"text":512,"config":513},"アジャイル開発",{"href":514,"dataGaName":515,"dataGaLocation":458},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":517,"config":518},"クラウドトランスフォーメーション",{"href":519,"dataGaName":520,"dataGaLocation":458},"/ja-jp/topics/cloud-native/","cloud transformation",{"text":522,"config":523},"SCM",{"href":118,"dataGaName":524,"dataGaLocation":458},"source code management",{"text":108,"config":526},{"href":110,"dataGaName":527,"dataGaLocation":458},"continuous integration & delivery",{"text":160,"config":529},{"href":162,"dataGaName":530,"dataGaLocation":458},"value stream management",{"text":532,"config":533},"GitOps",{"href":534,"dataGaName":535,"dataGaLocation":458},"/ja-jp/solutions/gitops/","gitops",{"text":173,"config":537},{"href":175,"dataGaName":176,"dataGaLocation":458},{"text":178,"config":539},{"href":180,"dataGaName":181,"dataGaLocation":458},{"text":183,"config":541},{"href":185,"dataGaName":186,"dataGaLocation":458},{"text":543,"config":544},"教育",{"href":545,"dataGaName":546,"dataGaLocation":458},"/ja-jp/solutions/education/","education",{"text":548,"config":549},"金融サービス",{"href":550,"dataGaName":551,"dataGaLocation":458},"/ja-jp/solutions/finance/","financial services",{"title":193,"links":553},[554,556,558,560,563,565,568,570,572,574,576,578,580,582],{"text":205,"config":555},{"href":207,"dataGaName":208,"dataGaLocation":458},{"text":210,"config":557},{"href":212,"dataGaName":213,"dataGaLocation":458},{"text":215,"config":559},{"href":217,"dataGaName":218,"dataGaLocation":458},{"text":220,"config":561},{"href":222,"dataGaName":562,"dataGaLocation":458},"docs",{"text":243,"config":564},{"href":245,"dataGaName":246},{"text":566,"config":567},"お客様の成功事例",{"href":240,"dataGaLocation":458},{"text":238,"config":569},{"href":240,"dataGaName":241,"dataGaLocation":458},{"text":248,"config":571},{"href":250,"dataGaName":251,"dataGaLocation":458},{"text":261,"config":573},{"href":263,"dataGaName":264,"dataGaLocation":458},{"text":253,"config":575},{"href":255,"dataGaName":256,"dataGaLocation":458},{"text":266,"config":577},{"href":268,"dataGaName":269,"dataGaLocation":458},{"text":271,"config":579},{"href":273,"dataGaName":274,"dataGaLocation":458},{"text":276,"config":581},{"href":278,"dataGaName":279,"dataGaLocation":458},{"text":281,"config":583},{"href":283,"dataGaName":284,"dataGaLocation":458},{"title":299,"links":585},[586,588,590,592,594,596,598,602,607,609,611,613],{"text":306,"config":587},{"href":308,"dataGaName":301,"dataGaLocation":458},{"text":311,"config":589},{"href":313,"dataGaName":314,"dataGaLocation":458},{"text":319,"config":591},{"href":321,"dataGaName":322,"dataGaLocation":458},{"text":324,"config":593},{"href":326,"dataGaName":327,"dataGaLocation":458},{"text":329,"config":595},{"href":331,"dataGaName":332,"dataGaLocation":458},{"text":334,"config":597},{"href":336,"dataGaName":337,"dataGaLocation":458},{"text":599,"config":600},"Sustainability",{"href":601,"dataGaName":599,"dataGaLocation":458},"/sustainability/",{"text":603,"config":604},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":605,"dataGaName":606,"dataGaLocation":458},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":339,"config":608},{"href":341,"dataGaName":342,"dataGaLocation":458},{"text":349,"config":610},{"href":351,"dataGaName":352,"dataGaLocation":458},{"text":354,"config":612},{"href":356,"dataGaName":357,"dataGaLocation":458},{"text":614,"config":615},"現代奴隷制の透明性に関する声明",{"href":616,"dataGaName":617,"dataGaLocation":458},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":34,"links":619},[620,622,624,626,631,636,641],{"text":34,"config":621},{"href":36,"dataGaName":37,"dataGaLocation":458},{"text":367,"config":623},{"href":369,"dataGaName":370,"dataGaLocation":458},{"text":372,"config":625},{"href":374,"dataGaName":375,"dataGaLocation":458},{"text":627,"config":628},"ステータス",{"href":629,"dataGaName":630,"dataGaLocation":458},"https://status.gitlab.com/","status",{"text":632,"config":633},"利用規約",{"href":634,"dataGaName":635,"dataGaLocation":458},"/terms/","terms of use",{"text":637,"config":638},"プライバシーに関する声明",{"href":639,"dataGaName":640,"dataGaLocation":458},"/ja-jp/privacy/","privacy statement",{"text":642,"config":643},"Cookieの設定",{"dataGaName":644,"dataGaLocation":458,"id":645,"isOneTrustButton":90},"cookie preferences","ot-sdk-btn",{"items":647},[648,650,652],{"text":632,"config":649},{"href":634,"dataGaName":635,"dataGaLocation":458},{"text":637,"config":651},{"href":639,"dataGaName":640,"dataGaLocation":458},{"text":642,"config":653},{"dataGaName":644,"dataGaLocation":458,"id":645,"isOneTrustButton":90},"content:shared:ja-jp:main-footer.yml","Main Footer","shared/ja-jp/main-footer.yml","shared/ja-jp/main-footer",{"allPosts":659,"featuredPost":1013,"totalPagesCount":1034,"initialPosts":1035},[660,685,709,730,749,771,791,819,839,858,878,898,916,936,955,974,994],{"_path":661,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":662,"content":670,"config":678,"_id":681,"_type":13,"title":682,"_source":15,"_file":683,"_stem":684,"_extension":18},"/ja-jp/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds",{"title":663,"description":664,"ogTitle":663,"ogDescription":664,"noIndex":6,"ogImage":665,"ogUrl":666,"ogSiteName":667,"ogType":668,"canonicalUrls":666,"schema":669},"Git誕生20周年を、生みの親リーナス・トーバルズ氏と一緒に祝う","トーバルズ氏がオープンソースのバージョン管理システムの開発にいたった経緯、数か月で手を引いた理由、そしてGitでの新しいプログラミング言語のサポートについてどう考えているかをご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662510/Blog/Hero%20Images/git-20-years-opt1.png","https://about.gitlab.com/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git誕生20周年を、生みの親リーナス・トーバルズ氏と一緒に祝う\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2025-04-07\",\n      }",{"title":663,"description":664,"authors":671,"heroImage":665,"date":673,"body":674,"category":675,"tags":676},[672],"Patrick Steinhardt","2025-04-07","バージョン管理システム「Git」の最初のバージョンは、Linuxカーネルの父であるリーナス・トーバルズ氏によって、2005年4月7日にリリースされました。現在ではほぼすべてのデベロッパーが使うようになったこの重要なプロジェクトの20周年を記念して、トーバルズ氏にインタビューし、Gitの歴史、Gitのメンテナーとしての役割を別の人物に引き継いだ理由、そしてもっとも重要なマイルストーンとは何かについてうかがいました。\n\n**Gitをリリースした2005年には、すでに人気のLinuxカーネルのメンテナーを務めていらっしゃいました。それなのに、なぜ新しいバージョン管理システムの開発を始めようと思ったのですか？**\n\nバージョン管理を行うのが、すごく嫌になっていたんです。\n\n従来型のバージョン管理システム（CVS／RCS／SCCS）はエンドユーザーとしても（例：[GCC](https://gcc.gnu.org/)などのオープンソースプロジェクトの追跡に使用）、デベロッパーとしても（トランスメタ社では何にでもCVSを使用していたため）使用していましたが、非常に嫌な体験でした。\n\n\u003Cimg src=\"https://about.gitlab.com/images/blogimages/linustorvalds.png\" align=\"left\" width=\"200px\" style=\"padding-right: 20px; padding-bottom: 10px\"/>\n\nその当時、CVSを使用していたプロジェクトはほとんど、[SVN](https://subversion.apache.org/)に移行したと思いますが、正直なところ、SVNは単に表面的な部分だけを変更した「ブタに真珠」だと感じていました。CVSを単に別のソフトにしただけのもので、ある程度UIが改善されていたものの、基本的な問題は一切修正されておらず、代わりに新たな問題を内包していました。\n\nCVSや類似のソフトウェアの問題は、数えきれないほどあります。幸いなことに、それらの問題はもはや重要でなくなっており、若いデベロッパーは対処しなくて済んでいるはずです。90年代にはいくつかのサブシステム（特にネットワーク側）で実際にCVSを使ってコードを追跡していましたが、カーネルでCVSを使うことは断固として拒否しました。\n\nその当時、私はサンフランシスコ・ベイエリアに住んでいました。別のプロジェクト（主に[lmbench](https://www.usenix.org/legacy/publications/library/proceedings/sd96/full_papers/mcvoy.pdf)）で知り合ったラリー・マクボイがBitMoverを立ち上げ、BitKeeper（略称「BK」）と呼ばれる新たなバージョン管理モデルを開発しました。\n\nBitKeeperはオープンソースではなかったものの、ラリー自身はオープンソースプロジェクトを好んでおり、バージョン管理の欠如がカーネルの足かせになっていると強く感じていました。ラリーの考えには同意していたものの、従来のソースコード管理ツール（SCM）の導入にはまったく賛成できませんでした。ラリーは時間をかけて、デイヴィッド・ミラー（ネットワーク機能のメンテナーで既存のCVSユーザー）と私に、BitKeeperでできることを説明してくれました。\n\nBitKeeperは完璧ではありませんでした。また、他の多くの従来型SCMと同様、ソースコード管理システム（SCCS）をベースにしていたため、うまく機能しない「ファイルごとの履歴」モデルが使用されていました。そのため、ファイルの名前変更や削除の際に根本的かつ重大な問題が生じるという欠点がありました。\n\nしかしながら、BitKeeperは単なる「ブタに真珠」ではありませんでした。下層レベルではSCCSが用いられていたかもしれませんが、それより上のレベルでは非常に根本的な部分がいくつか修正されており、適切に分散型開発が行われていました。また、ファイルごとではなく、全体的に履歴が管理されていたため、別のツリーからのコードのマージも実際に行えました。\n\nCVSでは、ブランチを作成してマージする場合、事前に計画して関係者と話し合う必要があり、一大イベントでした。一方、BitKeeperではすべてのリポジトリがブランチでした。これは今となっては当たり前のことです。もちろんGitではこれをさらに推し進め、リポジトリ*ごと*に複数のブランチを持てるようになっています。それと比べると、BitKeeperモデルははるかに制限されたものでしたが、当時は大きな前進でした。\n\nもう一度言いますが、BitKeeperは完璧ではありませんでした。先ほどもお話ししたように、ファイルごとに履歴を保持していたため、名前変更やファイルのマージが確実ではないという根本的かつ重大な問題がありました。そのため、どうしても混乱と手間が苦痛が生じていました（CVSを使っていた方は、Atticを思い出してみてください）。さらに、スケーラビリティの問題もいくつかありましたが、当時はまだ大きな問題ではありませんでした。\n\nしかしながら、BitKeeperの最大の問題はライセンスでした。数年かけて（2002年から2005年までBitKeeperを使用）、多くのカーネルメンテナーがBitKeeperに移行しましたが、毎回ライセンスの面で摩擦が生じていました。2004年後半にはそれが大問題となり、カーネルにBitKeeperを使用することは、数か月後には基本的に不可能という事態となりました。\n\n当時の私は、ようやく機能するソース管理ツールを使用できるようになってから3年間経っており、おかげで非常に多くの問題を解決できていました。ソース管理を行っていなかった時代に戻るのはお断りでしたが、BitKeeperを使用していた数年の間、それよりも良いツールはオープンソースコミュニティから出てこなかったのです。\n\nCVSやSVNがうまく機能しないことは周知の事実であり、別のアプローチを試したプロジェクトもありました。それらのアプローチの中には、さらにひどいもの（多くは「手の込んだパッチ追跡」に相当するもの）や、アイデア自体は良かったのに、その過程で新しい重大なデザインミスが起きたもの（[Monotone](https://www.monotone.ca/)）もありました。\n\nそのため、しばらく探し回ってから、他に選択肢はないから自分で開発しなければ、と決断しました。\n\n技術的には、Gitの最初のバージョンの作成には数日しかかかりませんでした。それはすべて、Gitのコミット履歴に残っています。ほぼ何もなかった状態から、1週間後には他の人から提供されたパッチを適用し始める（さらにその数日後には、カーネルに積極的に使用されるようになった）ほど使える状態になった様子は簡単に見て取れます。\n\nしかしながら、コミット履歴からは、それまでに私がこの問題についてしばらく*考えていた*という事実はわかりません。コードを書くこと自体は簡単です。重要なのは、良いデザインを行うことです。ですので、あの数日間の前にかなり長い準備期間がありました。その部分は、コミット履歴には反映されていません。\n\n最初のバージョンはとても粗削りなもので、後から登場する機能はほとんど備わっていませんでした。しかしながら、この最初のバージョンには、核となるデザインの大部分がすでに含まれていました。\n\n**Gitプロジェクトがどのように始まったか、最初の数日間と数週間について簡単に説明していただけますか？**\n\n私は基本的には、満足できる代替ツールができあがるまで、カーネルの開発を中断すると決めていました。主な目標は、分散型かつ高性能であること、そしてどんな破損でも確実に検出可能と信頼できるものを開発することでした。\n\nただし、お伝えしておきたいのは、SCM自体には興味がなかったということです。私が興味があったのは、プロセスではなく、最終的に得られる結果でした。そのため、私にとって、Gitはカーネルと同じではありませんでした。Linux開発はカーネルに興味があるから行っていますが、Gitは必要性に迫られて取り組みました。\n\nこれが、次の質問の回答にも直接つながります。\n\n**数か月後に、Gitのメンテナーの役割を濱野純氏に引き継がれました。今でも引き続き濱野氏がメンテナーを務めています。メンテナーを退いた理由、そして濱野氏を選んだ理由についてお聞かせください。**\n\nメンテナーの役割を引き継ぐことは、難しい決断ではありませんでした。「Gitのメンテナンスを任せられると思える相手が見つかったら、すぐにカーネルのメンテナーに戻ろう」と考えていたためです。\n\nもちろん、責任だけを押し付けて、成功を祈ったというわけではありません。メンテナンスを長期間にわたって担当してくれる、「センスが良い」人を探す必要があると考えていたため、結局、Gitのメンテナーを4か月ほど務めることになりました。\n\n濱野さんは、初期から参加したメンバーの1人でした（文字どおり、開発の最初の週から参加）。でも、すぐに「次のメンテナーになってください」と言ったわけではありません。誰が長期にわたって担当してくれるか、また誰がコードを書いて、適切な決定を下せるかを見極めるには、ある程度の時間がかかります。\n\n濱野さんはまさにぴったりでした。私がGitに費やしたのはわずか数か月間ですが、特に20周年を迎えるにあたり、賞賛を受けすぎていると感じています。適切に核となるデザインを行い、プロジェクトを立ち上げたことは私の実績ですが、（もちろん他の何百人もの関係者も重要ですが）実際にプロジェクトを主導してきたのは濱野さんです。\n\n**バージョン管理システムであるMercurialの最初のバージョンは、Gitの最初のバージョンがリリースされてからわずか12日後（2005年4月19日）にリリースされました。MercurialのユーザーエクスペリエンスはGitよりも優れていたと多くの人々が主張していますが、今では圧倒的にGitの方が人気があります。GitがMercurialに勝った理由は何だとお考えですか？**\n\n主な理由は、明らかにネットワーク効果だと思います。SCMには、非常に強力なネットワーク効果があります。制限が多いにもかかわらず、CVSがあれほど長く生き残った理由もそれです。\n\nつまり、カーネルでGitを使用していたためです（その後、ある時点でRuby on RailsコミュニティでGitが大人気となり、それからさまざまな場所で普及しました）。\n\nでも、Gitのデザインは本当に優れていると思います。コアモデルは非常にシンプルかつ強力です。そのおかげで、他の環境に簡単に移植できたと考えています。JGitは初期の移植例ですが、他にもMSgit仮想ファイルシステムなどの実装があります。\n\nたしかに当初はGitが使いにくいという評判がありましたが、その理由の一部は、Gitでは「正しく」処理を行っていたことが原因だと思います。Gitでは、従来のSCMでは決して行わなかったような、難しい判断をいくつか行っていたため、他の環境から移行したユーザーはGitを直感的ではないと感じたのでしょう。\n\n**Gitプロジェクトは、あなたが濱野氏にメンテナーの役割を引き継いだ後も、一度も停止せずに、コミュニティメンバーによる新機能の開発が常に進行中です。プロジェクトを離れた後、もっとも重要なマイルストーンは何だったとお考えですか？**\n\nそれは非常に答えにくい質問です。というのも、自分が満足するようにGitを開発したため、*私自身*が活用している機能は、開発当初から使えたためです。わかりやすい例としては、GitがWindowsに対応したことことは、他のユーザーにとっては間違いなく大きなステップでしたが、*私*にとってはまったく関係のないことでした。\n\nもちろんGit自体に、使いやすさを向上するためのインフラがすべて備わっていますが、大きなマイルストーンの大半は、Gitのインフラを利用して、それを中心に何かを構築してきた人たちによって成し遂げられたものだと思います。当然ながら、これらは最終的にはGitの機能に反映されがちです。しかしながら、本当のマイルストーンは外部に関するものです。\n\nわかりやすい例を挙げると、Gitのホスティングサイトはすべて大きなマイルストーンです。ホスティングサイトによって、より簡単にGitを配信できるようになったものの、*本当のマイルストーン*は、ホスティングによってユーザーがさまざまなプロジェクトでGitを非常に簡単に使えるようになったことです。\n\n**もし、またGitにフルタイムで携わることができるとしたら、実装したい機能はありますか？**\n\n一切ないですね。Gitではかなり初期の段階から、本当に必要としていたことをすべて実現できました。実のところ、私の使い方はかなり限定的で、本当に重視しているのは1つのプロジェクトだけなんです。\n\nそして、「一切ない」とお答えしたのは、先ほどお伝えしたとおり、私は当初からSCMにまったく興味がなかったためです。Gitが他のSCMとこれほど違うものになった（おおむね良い意味で）主な理由は、私が従来のSCMというより、分散型ジャーナリングファイルシステムに対してのように取り組んだからだと思います。\n\n**Gitの機能やデザイン上の決定で、後悔していることはありますか？**\n\nデザイン上の決定ですか？後悔していることはありません。今でも基本デザインは非常に優れていると思っています。実際の実装の複雑な詳細に一切触れることなく、さまざまなGitのコンセプトについて話し合えます。\n\nプロジェクトにおいては、それが重要だと思います。プロジェクトのコンセプトの方向性を指示するには、基本的なデザイン方針がある程度必要です。\n\nときにはこれが行き過ぎて、実装時に、基本デザインの核となる方針に盲目的に従うべきだと考える人もいます。これも間違っています。現実はややこしく、人々は変わったものを求めるため、*実装時*には複雑な多数のコーナーケースが生じます。なので、厄介な現実に対処しなくて済むように、参考になり、高度なレベルで検討できるような、ある種の基本デザインが必要となります。\n\nGitはそう言った面でバランスが取れていると思います。非常にわかりやすいオブジェクトストアデザインが採用されています（CS分野の方にとっては「マークル木構造」、ファイルシステム担当者には「内容アドレス記憶装置」という呼び方がピンとくるかもしれません）。コアデザインは存在しますが、一方でそれは実際のところ、実コードのほんの一部にすぎません。*コード*の大半はコアデザインに沿った内容です。根本的にデザインがわかりやすいため、プロジェクトにある種の基本構造が生まれます。\n\nこれは、かつてのUNIX自体の基本構造（すべてがファイルから構成されている仕組みや、プロセス処理方法）と同じようなものです。デザインのベースとなる「コンセプト」はいくつかあるものの、コードの99%は、それを実世界に適用するために、その上に構築される非常に細かな内容です。\n\n私には、技術に関する信念が2つあります。それは「私がかなたを見渡せたのだとしたら、それは巨人の肩の上に立っていたからです」（ニュートン）と「天才とは、1%のひらめきと99%の努力である」（エジソン）です。\n\n99%の努力について考えてみると、大まかなデザインには非常に満足していますが、細かい点については、もし今Gitに携わるなら違う風にしていただろうなと思うところは、確かに多々あります。\n\nでも正直なところ、そういった点はあまり重要でありません。それよりも、過去20年間に行われたすべての*良い*実装こそがはるかに重要です。\n\n**Linuxカーネルにおいて、一部のサブシステムのプログラミング言語としてRustの使用が開始されました。Gitの場合、このような新しいプログラミング言語を使い始めることは妥当だとお考えですか？**\n\nGitに関して言えば、新たな言語を使い始めることにあまり意味はないと思います。大抵の場合、苦労することになります。\n\nカーネルの場合、最終的な成果物は単一のカーネルバイナリです。その大半はモジュールとして動的に読み込むことはできるものの、実質的には単一のバイナリにリンクされています。\n\nそのため、複数の言語を使用すると、より複雑になります。しかしその一方で、カーネルではメモリ安全性についてさらに気を付けなければならないため、新しい言語に目を向ける必要性があります。\n\nGitの場合は、もしその一部をRustや他の言語で書きたいのであれば、複数の言語で1つのバイナリを開発するよりも、個別に実装する方がはるかに理にかなっていると思います。\n\nGitの核となるアイデアの多くはシンプルなので、中核となる部分の並列実装だけならそれほど難しくないはずです。そうすれば、別の言語での開発がより適切な問題領域に、個別に取り組めます。\n\nもちろん、このやり方はすでにGitでも行われています。まさにこの方法で開発されているのがJGitです。別の言語を使用したのは、Gitとは異なるウェブベースの環境であるため、より自然な選択だったからです。\n\nGitの主要機能の一部に対応したRustの実装はすでにいくつかありますが、同様の状況だと思います。特定の状況においては、「すべてをRustに移植しよう」というよりも、このアプローチの方が適切だと思います。\n\nですので、Rustでの実装に興味がある方には、Rustを使用する利点がより明らかな箇所を探すことをおすすめします。標準的なGitのソースベースでは、C言語の使用はそれほど問題はなかったと思います。\n\n**数年ごとに、新しいバージョン管理システムが登場しています。Gitは今後も、重要なツールとしての地位を維持できるとお考えですか？** \n\nSCMにネットワーク効果があることは先ほどお話ししました。そのため、Gitに取って代わるには、少し優れているだけではなく、はるかに優れている必要があると思います。もしくは、互換性が高すぎると、実質的にGitの新しい実装となります。\n\nSCMを取り巻く状況は実際に変わったと思います。Gitには、Git以前のSCMが抱えていたような、深刻かつ根本的な問題はありません。したがって、「はるかに優れている」ツールを開発するのはかなり大変です。\n\nですので、当面の間、Gitが現在の地位を維持できると考えています。人々はGitに代わるツールではなく、Gitを*ベース*として改善に取り組んでいくでしょう。\n\n*注：このインタビューは、長さを調節し、文意を明確にするために編集されています。*\n\n## Gitの関連リンク\n\n- [Git 2.49.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-49-0/)  \n- [Git 2.48.0の新機能](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-48-0/)  \n- [初心者向けGit reftableフォーマットガイド](https://about.gitlab.com/ja-jp/blog/a-beginners-guide-to-the-git-reftable-format/)\n- [Gitプロジェクト](https://git-scm.com/)","open-source",[677,9],"open source",{"slug":679,"featured":90,"template":680},"celebrating-gits-20th-anniversary-with-creator-linus-torvalds","BlogPost","content:ja-jp:blog:celebrating-gits-20th-anniversary-with-creator-linus-torvalds.yml","Celebrating Gits 20th Anniversary With Creator Linus Torvalds","ja-jp/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds.yml","ja-jp/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds",{"_path":686,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":687,"content":692,"config":703,"_id":705,"_type":13,"title":706,"_source":15,"_file":707,"_stem":708,"_extension":18},"/ja-jp/blog/git-merge-command-overview",{"config":688,"title":689,"description":690,"ogImage":691},{"noIndex":6},"git mergeコマンドの基本を徹底解説 | GitLab","git merge コマンドについてコマンドの基本的な使い方からリクエストコードまで解説します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1754287290/averr2ecwl01q2f9lknf.jpg",{"date":693,"heroImage":691,"title":694,"authors":695,"category":675,"body":697,"description":698,"tags":699},"2025-08-04","git mergeコマンドの基本を徹底解説",[696],"GitLab Team","## 目次\n\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)\n\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)\n\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)\n\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)\n\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)\n\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)\n\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)\n\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)\n\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\n## git mergeとは？\n\n\ngit mergeとは、分岐したブランチをmerge（マージ、統合すること）するコマンドのことです。別のリポジトリからの変更を組み込む際にも使われ、git pull（git fetchとgit mergeを組み合わせたもの）の一部としても機能します。チームで開発を実施するときなどにmainブランチから作業用ブランチを作り、テストをしてからマージ、プッシュすることも多いでしょう。\n\n\nたとえば、main ブランチに基づいて作成された新しいブランチ’feature’があるとします。この feature ブランチを main にマージするのに使われるのがgit mergeコマンドです。\n\n\n## git mergeコマンドの基本\n\n\ngit mergeの基本的なコードは次のようになります。\n\n\n```\n\ngit merge BRANCH_NAME\n\n```\n\n\nブランチ名は、取り込みたいブランチの名前を入力します。\n\n\n一見簡単そうですが、マージをスムーズに実行するにはいくつか準備が必要となりますので、次の章で確認しましょう。\n\n\n## マージ先のブランチを準備する\n\n\ngit status を実行して、HEAD が取り込む先のブランチであることを確認します。必要に応じて\n\n\n```\n\ngit checkout BRANCH_NAME\n\n```\n\n\nを実行して、マージする先のブランチに切り替えます。\n\n\n## 最新のリモートコミットをフェッチする\n\n\nリモートで変更を加えたら、マージ先ブランチとマージ元ブランチに最新の変更内容を反映させます。その際は、[git fetchとgit pull](https://about.gitlab.com/ja-jp/blog/2024/07/25/what-is-the-difference-between-git-fetch-and-git-pull/)を使います。その後、リモートで加えた変更内容がmainブランチに反映されていることを確認します。\n\n\n## 早送りマージと３ウェイマージ\n\n\n早送りマージは、ブランチが分岐していない場合にのみ使えるコマンドです。早送りマージでは、マージ自体は行われませんが、ブランチの先頭とブランチの末尾の履歴を結合することで、旧ブランチからアクセスできたコミットが、新ブランチからも利用できるようになります。\n\n\n強制的に早送りマージを実施する場合は以下のコードを使います（分岐がある場合など早送りマージができない場合にはエラーとなりマージはできません） \n\n\n```\n\ngit merge --ff-only\n\n```\n\n\n一方、ブランチが分岐している場合には、早送りマージを適用することはできず、マージする手段は３ウェイマージに限られます。３ウェイマージは、3 つのコミット （2 つのブランチのそれぞれ先端のコミットと履歴を統合するために生成される専用のコミット）を使用してマージコミットを生成することから来ています。\n\n\n```\n\ngit checkout BRANCH_NAME\n\n```\n\n\nを使うと、早送りマージが可能な時は早送りマージを実施し、できない時に３ウェイマージを実施します。\n\n\n## git mergeによるコンフリクトの解決\n\n\nマージの基本を理解すると、同じ箇所を同時に更新してしまったらどうなるのか、という疑問を持たれる方もいるのではないでしょうか。この場合、Git側ではどちらを優先すべきか判断ができず、手作業でコンフリクトを解決することを求めます。\n\n\nエラーメッセージは次のように表示されます。\n\n\n```\n\ngit merge BRANCH_NAME\n\nAuto-merging index.html\n\nCONFLICT (content): Merge conflict in index.html\n\nAutomatic merge failed; fix conflicts and then commit the result.\n\n```\n\n\nコンフリクトを解決するまで、処理は中断されます。どのファイルでコンフリクトが発生してマージできなかったのを確認するにはgit status を実行します。\n\n\n```\n\ngit status\n\n```\n\n\n未解決のコンフリクトについては unmerged として表示されます。標準的なコンフリクトマーカーがファイルに追加されるため、該当ファイルから修正できます。git addを実行して、コンフリクトが解決したことを Git に通知します。続いて通常の git commit を実行してマージ コミットを生成します。\n\n\n## git mergeコマンドのベストプラクティス\n\n\ngit mergeコマンドでよく起こる問題として、他のデベロッパーが加えた変更を破棄してしまうことが挙げられます。個々人がこまめにgit mergeを実行することで、変更を破棄してしまう問題は避けることができますが、マージそのもののコストが膨れ上がる可能性があります。複雑なコンフリクトが出ない場合に自動マージしてくれるようなツールの導入は、git mergeを使うチームの大きな手助けになるはずです。\n\n\n## GitLabでgit mergeを使う\n\n\ngit mergeのベストプラクティスとしてツールの使用をおすすめしましたが、[GitLab](https://about.gitlab.com/ja-jp/)なら自動マージ機能のほかにもリモートリポジトリのホスティング、インターフェースの提供、変更内容のコードレビュー、プッシュされたコードの自動ビルド、テスト、デプロイまでを一括で管理できます。\n\n\ngit mergeで起きるコンフリクトを自動で解決できるGitLabの無料トライアルは[こちら](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/&glm_content=default-saas-trial)からお申し込みいただけます。\n\n\n## git mergeコマンド のFAQ\n\n\n### git mergeコマンドとは何ですか？\n\n\ngit mergeとは、分岐したブランチをmerge（マージ、統合すること）するコマンドのことです。\n\n\n### mainブランチにマージするにはどうしたらいいですか？\n\n\nまず、\u003Ccode>git checkout BRANCH_NAME\u003C/code>を使ってmainブランチに移動します。\n\n\n次に\u003Ccode>git merge BRANCH_NAME\u003C/code>を使ってマージしたいブランチを指定します。\n\n\nマージ先ブランチ名）master\\\n\nマージするブランチ名）feature1の場合には\n\n\n```\n\n\u003Ccode>git checkout master\u003C/code>\n\n\u003Ccode>git merge feature1\u003C/code>\n\n```\n\n\n\\\n\nとなります。\n\n\n### git mergeとgit rebaseの違いは何ですか？\n\n\ngit mergeとgit rebaseはどちらもブランチを結合するコマンドです。mergeが新しいコミットを生成してコミット履歴が分散してしまうのに対し、rebaseはコミット履歴をひとつのブランチにまとめます。rebaseはログを整理する目的で使われることが多いですが、別のブランチで他のメンバーが加えた変更の履歴を消してしまう可能性などがあるので、上級者向けのコマンドといえます。\n\n\n*監修：知念 梨果* *[@rikachinen](https://gitlab.com/rikachinen)（GitLab合同会社 カスタマーサクセス本部 カスタマーサクセスエンジニア）*\n","この記事では、git mergeコマンドについてコマンドの基本的な使い方からリクエストコードまで解説します。",[700,9,701,702],"collaboration","tutorial","workflow",{"featured":90,"template":680,"slug":704},"git-merge-command-overview","content:ja-jp:blog:git-merge-command-overview.yml","Git Merge Command Overview","ja-jp/blog/git-merge-command-overview.yml","ja-jp/blog/git-merge-command-overview",{"_path":710,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":711,"content":717,"config":724,"_id":726,"_type":13,"title":727,"_source":15,"_file":728,"_stem":729,"_extension":18},"/ja-jp/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery",{"title":712,"description":713,"ogTitle":712,"ogDescription":713,"noIndex":6,"ogImage":714,"ogUrl":715,"ogSiteName":667,"ogType":668,"canonicalUrls":715,"schema":716},"継続的デリバリーにおける信頼できる情報源としてOCIイメージを活用する方法","GitOpsワークフローの一環としてOpen Container Initiative（OCI）イメージを活用する利点、およびKubernetesへのデプロイを簡素化するためにGitLabが提供する多くの機能について詳しくご紹介します。","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","https://about.gitlab.com/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"継続的デリバリーにおける信頼できる情報源としてOCIイメージを活用する方法\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Daniel Helfand\"}],\n        \"datePublished\": \"2025-02-19\",\n      }",{"title":712,"description":713,"authors":718,"heroImage":714,"date":720,"body":721,"category":675,"tags":722},[719],"Daniel Helfand","2025-02-19","gitリポジトリをデプロイメントアーティファクトとして使用しない場合でも、それを[GitOps](https://about.gitlab.com/ja-jp/topics/gitops/)と呼ぶのは適切なのでしょうか？gitは依然としてGitOpsワークフローの中心的な要素ですが、近年では、インフラ定義をOpen\nContainer\nInitiative（OCI）アーティファクトとしてコンテナレジストリに保存し、それをGitOpsデプロイのソース（情報源）とする手法が広まりつつあります。この記事では、この傾向の背後にある考え方、およびGitLabの機能がどのようにGitOpsワークフローの進化を支えているのかについて詳しくご説明します。\n\n\n## GitOpsとは？\n\n\n[OpenGitOps](https://opengitops.dev/)プロジェクトでは、GitOpsの実践に関する以下の[4つの原則](https://opengitops.dev/#principles)を定義しています。\n\n-\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\n- ソフトウェアエージェントは、望ましい状態の宣言をソースから自動的にプルすること。\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\n\nGitOpsの一例として、マイクロサービスのKubernetesマニフェストをGitLabプロジェクトに保存することが挙げられます。これらのKubernetesリソースは、マイクロサービスがデプロイされたKubernetesクラスター上で実行されている[コントローラー](https://kubernetes.io/docs/concepts/architecture/controller/)によって継続的に調整されます。これにより、エンジニアは通常のコード作業と同じワークフローを使用してインフラを管理できます。たとえば、マージリクエストを作成し、変更を加えてレビューしたり、変更にバージョン管理を適用することができます。GitOpsは、[構成ドリフトを防ぐ](https://about.gitlab.com/topics/gitops/#cicd)といった運用上の利点もあり、エンジニアが特定の展開結果に至った変更を監査するのにも役立ちます。\n\n\n## GitOpsワークフローにおけるgitの利点と制限\n\n\ngitはGitOpsワークフローにおいて不可欠な要素ではありますが、もともとgitリポジトリはGitOpsコントローラによってデプロイされることを前提に設計されたものではありません。gitによってエンジニア同士が連携しながらインフラに変更を加えたり、その後変更を監査したりすることはできます。しかし、コントローラーが正常にデプロイを実行するために、gitリポジトリ全体をダウンロードする必要はありません。GitOpsコントローラーが必要とするのは、特定の環境のインフラ定義だけです。\n\n\nさらに、デプロイプロセスにおいて重要なのは、デプロイの変更が信頼できるソースから行われたものであることを確認するために、[デプロイに署名して検証](https://docs.sigstore.dev/about/overview/#why-cryptographic-signing)することです。Gitのコミットは、GitOpsコントローラーによって署名・検証することが可能ですが、コミットはデプロイに関連しない他の詳細（ドキュメントの変更、他の環境の更新、Gitリポジトリの再構成など）を含むこともあります。また、1回のデプロイが複数のコミットにまたがる場合があるため、デプロイ全体が十分に反映しきれないこともあります。これもまた、このgit機能が設計されていないケースのように感じます。\n\n\nGitOpsワークフローにおけるgitのもう一つの課題は、想定以上に自動化が進んでしまう可能性があることです。監視しているブランチに変更をマージすると、すぐにデプロイされてしまいます。これは、gitの外側にプロセスを制御する仕組みがないためです。たとえば、金曜日の午後遅くにデプロイが行われないようにするにはどうすればよいでしょうか？あるいは、デプロイ担当のチームが特定のGitLabプロジェクトで変更をマージする権限を持っていない場合、どう対処すればよいのでしょうか？OCIイメージを使用することで、プロセスにパイプラインが追加され、[承認やデプロイの停止](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)といったデリバリー制御の機能を活用できるようになります。\n\n\n## OCIイメージ\n\n\n[Open Container\nInitiative](https://opencontainers.org/)は、コンテナ形式に関する標準を定義するために貢献してきました。多くのエンジニアは、Dockerfileを使用してコンテナイメージを作成することに慣れていますが、Kubernetesマニフェストをコンテナレジストリに保存することにはあまり馴染みがないかもしれません。[GitLabのコンテナレジストリ](https://docs.gitlab.com/ee/user/packages/container_registry/)はOCI準拠であるため、特定の環境向けのKubernetesマニフェストをコンテナレジストリにプッシュすることができます。これにより、[Flux\nCD](https://about.gitlab.com/blog/why-did-we-choose-to-integrate-fluxcd-with-gitlab/)のようなGitOpsコントローラーは、gitリポジトリ全体をクローンすることなく、このOCIアーティファクトに保存されたマニフェストを利用してデプロイを実行できます。\n\n\nGitOpsワークフローでは、gitリポジトリにマイクロサービスがデプロイされるすべての環境のインフラ定義が含まれていることがよくあります。特定の環境向けのKubernetesマニフェストをパッケージ化することで、Flux\nCDはデプロイに必要な最小限のファイルだけをダウンロードして、特定の環境へのデプロイを実行できます。\n\n\n### OCIアーティファクトのセキュリティ上の利点\n\n\n前述のとおり、環境にデプロイされるアーティファクトに署名し、検証することで、ソフトウェアプロジェクトのセキュリティが一層強化されます。Kubernetesマニフェストがコンテナレジストリにプッシュされた後、[Sigstore\nCosign](https://docs.sigstore.dev/quickstart/quickstart-cosign/)のようなツールを使用してOCIイメージに秘密鍵で署名できます。この秘密鍵は、GitLabプロジェクト内の[CI/CD変数](https://docs.gitlab.com/ee/ci/variables/)として安全に保存できます。その後、Flux\nCDはKubernetesクラスターに保存された公開鍵を使用して、デプロイが信頼できるソースから来ていることを確認できます。\n\n\n## GitLabを使ってOCIイメージをプッシュして署名する方法\n\n\nGitLabは、OCIイメージのパッケージ化、署名、デプロイのプロセスを簡素化する多くの機能を提供しています。GitOpsワークフローにおけるGitLabプロジェクト構成の一般的な方法は、各マイクロサービスのコード用に個別のGitLabプロジェクトを用意し、すべてのマイクロサービスに共通する単一のインフラリポジトリを持つというものです。アプリケーションが`n`個のマイクロサービスで構成されている場合、アプリケーションには`n\n+ 1`個のGitLabプロジェクトが必要になります。\n\n\nコードプロジェクトで作成されるアーティファクトは、通常、アプリケーションをパッケージ化するために使用されるコンテナイメージです。インフラプロジェクトまたはデリバリープロジェクトには、各マイクロサービスをスケールさせ、トラフィックを提供するために必要なリソースを定義したKubernetesマニフェストが含まれます。このプロジェクトで作成されるアーティファクトは通常、アプリケーションと他のマニフェストをKubernetesにデプロイするために使用されるOCIイメージです。\n\n\nこの構成では、環境の分離はKubernetesマニフェストを別々のフォルダに定義することで行われます。これらのフォルダは、アプリケーションをホストする環境（開発、ステージング、本番など）を表します。コードプロジェクトに変更が加えられ、新しいコンテナイメージがプッシュされた場合、その変更をGitLabのFlux\nCDとのインテグレーションを使ってデプロイするために必要なのは、環境フォルダ内のマニフェストを編集して新しいイメージ参照を追加し、マージリクエストを作成することだけです。マージリクエストのレビュー、承認、マージが実行されると、デリバリープロジェクトのCI/CDジョブが新しいOCIイメージをプッシュし、Flux\nCDがそれを受け取って新しい環境にデプロイします。\n\n\n![OCIイメージ -\nフローチャート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097611/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097611046.png)\n\n\nOCIイメージへの署名は、CosignをプロジェクトのCI/CDジョブに組み込むだけで簡単に行えます。以下のコマンドをローカルで実行することで、Cosignを使って新しい公開鍵と秘密鍵を生成できます。その際は、[glab\nCLI](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\n```\n\nglab auth login\n\ncosign generate-key-pair gitlab://[PROJECT_ID]\n\n```\n\n\ncosignコマンドが正常に実行されると、`COSIGN_PUBLIC_KEY`と`COSIGN_PRIVATE_KEY`という名前で、プロジェクトのCI/CD変数セクションにCosignキーが追加されていることが確認できます。\n\n\n### CI/CDジョブの例\n\n\nOCIイメージをプッシュするためのGitLab CI/CDジョブは、以下のような形になります。\n\n\n```yaml\n\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\nCI/CDカタログ](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/)には、GitLabが管理する[CI/CDコンポーネント（OCIアーティファクトおよびFlux\nCD向け）](https://gitlab.com/explore/catalog/components/fluxcd)が用意されています。このコンポーネントにより、開発チームはKubernetesマニフェストをOCIイメージとしてGitLabのコンテナレジストリや外部コンテナレジストリにプッシュし、Cosignを使用してOCIイメージに署名を行い、Flux\nCDを通じて新しくプッシュされたイメージをすぐに環境に同期することができます。 \n\n\n上記の例では、Flux CD\n`component`がGitLabプロジェクトの`.gitlab-ci.yml`ファイル内に含まれています。コンポーネントの入力パラメータを使って、ユーザーはイメージのプッシュ先レジストリ（すなわち`registry_image_url`と`image\ntag`）、プッシュ対象となるKubernetesマニフェストのファイルパス（すなわち`manifest_path`）、イメージの署名に使用するCosignの秘密鍵（すなわち`signing_private_key`）、そして環境への更新同期に必要なKubernetes名前空間とFlux\nCDの\n[OCIRepository](https://fluxcd.io/flux/components/source/ocirepositories/)名（すなわち`flux_oci_namespace_name`と`flux_oci_repo_name`）を定義できます。\n\n\n`kubernetes_agent_reference`を使用することで、各GitLabプロジェクトに`kubeconfig`\nCI/CD変数を個別に保存することなく、GitLab\nCI/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\n\nKubernetesエージェントのコンテキストは、通常、GitLabグループ内でKubernetes向けGitLabエージェントを設定している場所で構成されます。この設定は、通常、Flux\nCDを管理しているプロジェクトで行うことが推奨されています。CI/CDアクセス向けのエージェント設定について詳しくは、[CI/CDワークフローのドキュメント](https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html)をご覧ください。\n\n\n`$COSIGN_PRIVATE_KEY`、`$FLUX_OCI_REPO_NAME`、`$FRONTEND_DEV_NAMESPACE`といった変数は、機密性の高い情報をCI/CDログ上でマスキングしつつ、簡単にアクセスできるようにするためにCI/CD変数として保存されています。`$CI_REGISTRY_IMAGE`は、GitLabジョブでデフォルトで利用可能な変数で、対象のGitLabプロジェクトのコンテナレジストリを示します。\n\n\n### OCIイメージのデプロイ\n\n\n[Flux\nCDをGitLabプロジェクトと組み合わせて使用する](https://docs.gitlab.com/ee/user/clusters/agent/gitops/flux_tutorial.html)ことで、マイクロサービスの各環境へのデプロイと署名の検証を自動化できます。Flux\nCDをGitLabプロジェクトと連携するように設定したら、プッシュしたOCIイメージを同期するために、以下のKubernetesカスタムリソース定義\n[CRD](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)をプロジェクトに追加できます。\n\n\n```yaml\n\napiVersion: v1\n\nkind: Namespace\n\nmetadata:\n  name: frontend-dev\n  labels:\n    name: frontend-dev\n---\n\napiVersion: bitnami.com/v1alpha1\n\nkind: SealedSecret\n\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---\n\napiVersion: source.toolkit.fluxcd.io/v1beta2\n\nkind: OCIRepository\n\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---\n\napiVersion: kustomize.toolkit.fluxcd.io/v1\n\nkind: Kustomization\n\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[`Kustomization`](https://fluxcd.io/flux/components/kustomize/kustomizations/)リソースを使用することで、Kubernetesマニフェストをさらにカスタマイズできるほか、リソースをデプロイする対象のネームスペースも指定することができます。Flux\nCDの`OCIRepository`リソースでは、定期的に同期する対象となるOCIイメージのリポジトリ参照およびタグを指定できます。また、`verify.provider`と`verify.secretRef`というプロパティがあることに気づくでしょう。これらのフィールドを使うことで、クラスターにデプロイされるOCIイメージが、先ほどのCI/CDジョブで使用されたCosignの秘密鍵によって署名されたものであることを検証できます。\n\n\n公開鍵は、`OCIRepository`リソースと同じネームスペース内に格納する必要がある、[Kubernetesシークレット](https://kubernetes.io/docs/concepts/configuration/secret/)に保存しなければなりません。このシークレットをFlux\nCDによって管理し、平文で保存しないようにするには、値を暗号化してクラスター側のコントローラーで復号させるために、[SealedSecrets](https://fluxcd.io/flux/guides/sealed-secrets/)の使用を検討しましょう。\n\n\nSealedSecretsを使わないより簡単な方法としては、[`kubectl\nCLI`](https://kubernetes.io/docs/reference/kubectl/)を使用して[GitLab\nCI/CDジョブでシークレットをデプロイする](https://docs.gitlab.com/ee/user/clusters/agent/getting_started_deployments.html)方法があります。SealedSecretを使用しない方法では、上記で使用していたSealedSecretを削除し、新しいOCIイメージをプッシュするジョブを実行する前に、公開鍵のシークレットをデプロイするジョブを実行するだけです。これにより、シークレットがGitLab上で安全に管理され、クラスター内でOCIRepositoryから正常にアクセスできるようになります。このアプローチは比較的シンプルですが、本番環境でのシークレット管理には適していないことにご留意ください。 \n\n\n## OCI、GitLab、およびGitOpsの利点\n\n\nOCIアーティファクトを活用することで、GitOpsチームはセキュリティ面での利点を得ながら、デプロイを最小限に抑えることができます。ユーザーは、インフラの信頼できる情報源としてgitを活用できる点や、プロジェクトでのコラボレーションが可能になる点など、gitがもたらすあらゆる利点を引き続き享受できます。OCIイメージは、GitOpsにおけるデプロイの側面を強化する新たなパッケージ化手法を提供します。\n\n\nGitLab\nは、GitOpsワークフローをよりシンプルにするための利用体験を提供できるよう、ユーザーやクラウドネイティブコミュニティから継続的に学び続けています。このブログでご紹介した機能をお使いになるには、[GitLab\nUltimateの無料トライアル](https://about.gitlab.com/free-trial/)にお申込みください。これらのツールに関する皆さまのご利用体験についても、ぜひお聞かせください。フィードバックは[コミュニティフォーラム](https://forum.gitlab.com/t/oci-images-as-source-of-truth-for-gitops-with-gitlab/120965)にて受け付けています。\n",[108,677,723,532,9,701],"kubernetes",{"slug":725,"featured":6,"template":680},"how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery","content: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","ja-jp/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery.yml","ja-jp/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery",{"_path":731,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":732,"content":738,"config":743,"_id":745,"_type":13,"title":746,"_source":15,"_file":747,"_stem":748,"_extension":18},"/ja-jp/blog/journey-through-gits-20-year-history",{"title":733,"description":734,"ogTitle":733,"ogDescription":734,"noIndex":6,"ogImage":735,"ogUrl":736,"ogSiteName":667,"ogType":668,"canonicalUrls":736,"schema":737},"20年にわたるGitの歴史をたどる","初めて行われたコミット、初期リリースのユニークな特徴、そしてgit-push(1)のデフォルト動作の変更によって生じた混乱について、一緒に振り返っていきましょう。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097380/Blog/Hero%20Images/Blog/Hero%20Images/git-20-years-opt2_TWNsNk8KH43b3jP0KLD0U_1750097380123.png","https://about.gitlab.com/blog/journey-through-gits-20-year-history","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"20年にわたるGitの歴史をたどる\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2025-04-14\",\n      }",{"title":733,"description":734,"authors":739,"heroImage":735,"date":740,"body":741,"category":675,"tags":742},[672],"2025-04-14","Gitプロジェクトはちょうど20周年を迎えました。20年の間にさまざまなことがありました。Gitの概念的なデザインは、その登場以来大きく変わってはいないものの、ユーザーによるGitの操作方法は大きく変化しました。GitLabは、この重要な技術をベースにサービスを構築し、その歴史の一部であることを誇りに思っています。\n\nそれでは、Gitの歴史をたどり、長年にわたってどのように進化を遂げてきたかを一緒に見ていきましょう。\n\n## 初めてのコミット\n\n初めてのコミットは、2005年4月7日にLinuxカーネルの生みの親であるLinus Torvalds氏によって行われました。`e83c5163316 (Initial revision of \"git\", the information manager from hell, 2005-04-07)`\n\nご覧のとおり、このコミットには多くのファイルは含まれていませんでした。\n\n```shell\n$ git ls-tree e83c5163316\n100644 blob a6bba79ba1f46a1bbf7773449c3bd2bb9bf48e8b\tMakefile\n100644 blob 27577f76849c09d3405397244eb3d8ae1d11b0f3\tREADME\n100644 blob 98a32a9ad39883c6d05a000a68511d4b1ee2b3c7\tcache.h\n100644 blob 74a0a234dd346fff51c773aa57d82fc4b83a8557\tcat-file.c\n100644 blob 840307af0cfaab31555795ce7175d5e9c9f981a0\tcommit-tree.c\n100644 blob 25dc13fe101b219f74007f3194b787dd99e863da\tinit-db.c\n100644 blob c924a6e0fc4c36bad6f23cb87ee59518c771f936\tread-cache.c\n100644 blob 1b47742d8cbc0d98903777758b7b519980e7499e\tread-tree.c\n100644 blob b8522886a15db861508fb6d03d4d88d6de912a4b\tshow-diff.c\n100644 blob 5085a5cb53ee52e1886ff6d46c609bdb2fc6d6cd\tupdate-cache.c\n100644 blob 921f981353229db0c56103a52609d35aff16f41b\twrite-tree.c\n```\n\nビルドインフラストラクチャに加え、最初のコミットでは以下の7つのトップレベルコマンドが提供されていました。\n\n- `init-db`：新たなGitリポジトリを初期化\n- `update-cache`：インデックスにファイルを追加\n- `write-tree`：インデックスの内容を取得し、それをもとに新たなツリーを作成\n- `read-tree`：ツリーオブジェクトを読み込む\n- `commit-tree`：ツリーからコミットを作成\n- `cat-file`：特定のオブジェクトを一時ファイルに読み込む\n\nなお、この時点では、`git`コマンド自体存在していませんでした。代わりに、上記のコマンドを直接実行する必要がありました。\n\nでは、試しにリポジトリを新規作成してみましょう。\n\n```shell\n$ mkdir repo\n$ cd repo\n$ init-db\ndefaulting to private storage area\n$ ls -a\n.  ..  .dircache\n```\n\nみなさんにはまったくなじみがないと思います。`.git`ディレクトリではなく、`.dircache`ディレクトリが使用されていました。では、プライベートストレージ領域はどこでしょうか？\n\n初期のGitのデザインでは、オブジェクトストレージ領域は「共有」と「プライベート」に分かれていました。このオブジェクトストレージ領域には、コミットやblobなども含め、あらゆるGitオブジェクトが格納されていました。\n\n`init-db`は、デフォルトではプライベートオブジェクトストレージ領域を作成します。これは、領域の作成先の管理ディレクトリ専用として使用されていました。一方、同じオブジェクトを二重に保存する必要がないように、「共有」オブジェクトストレージ領域を使用して、複数の管理ディレクトリ間でオブジェクトの内容を共有していました。\n\n### コミットを作成する\n\nリポジトリの作成後は、どのようにコミットを作成していたのでしょうか？作成方法は、現在利用可能な`git add . && git commit`ほどシンプルではありませんでした。その代わりに、以下の方法で行っていました。\n\n1. 追加するファイルごとに`update-cache`を呼び出してインデックスを更新する。\n1. `write-tree`を呼び出して新規ツリーを書き込む。インデックスに追加済みのすべての内容をもとに作成される。\n1. 環境変数を設定して、Gitにコミッターの情報を伝える。\n1. `commit-tree`を呼び出して、コミットオブジェクトを書き込む。\n\nそれでは、リポジトリにコミットを作成してみましょう。\n\n```shell\n$ echo content-1 >file-a\n$ update-cache file-a\n$ echo content-2 >file-b\n$ update-cache file-b\n$ write-tree\n3f143dfb48f2d84936626e2e5402e1f10c2050fb\n$ export COMMITTER_NAME=\"Patrick Steinhardt\"\n$ export COMMITER_EMAIL=ps@pks.im\n$ echo \"commit message\" | commit-tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\nCommitting initial tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\n5f8e928066c03cebe5fd0a0cc1b93d058155b969\n```\n\n人間工学的な方法とは言えないものの、コミットは作成されます。それでは、生成されたコミットを見てみましょう。\n\n```shell\n$ cat-file 5f8e928066c03cebe5fd0a0cc1b93d058155b969\ntemp_git_file_rlTXtE: commit\n$ cat temp_git_file_rlTXtE\ntree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\nauthor Patrick Steinhardt \u003Cps@pks.im> Wed Mar 26 13:10:16 2025\ncommitter Patrick Steinhardt \u003Cps@pks.im> Wed Mar 26 13:10:16 2025\n\ncommit message\n```\n\n注目していただきたいのは、`cat-file`は内容を直接表示せず、まずは一時ファイルに書き出す点です。しかしながら、ファイルの内容は、まさに現代的なコミットと同じように見えます。\n\n### 変更を加える\n\nファイルの作成後、どのようにステータスを確認していたのでしょうか？おそらくお察しのとおりで、`show-diff`を使用していました。\n\n```shell\n$ show-diff\nfile-a: ok\nfile-b: ok\n\n$ echo modified-content >file-a\n$ show-diff\n--- -\t2025-03-26 13:14:53.457611094 +0100\n+++ file-a\t2025-03-26 13:14:52.230085756 +0100\n@@ -1 +1 @@\n-content-1\n+modified-content\nfile-a:  46d8be14cdec97aac6a769fdbce4db340e888bf8\nfile-b: ok\n```\n\n驚くべきことに、すでに`show-diff`では、変更されたファイルの新旧の状態を比較して差分を取得していました。しかも面白いことに、GitではこれをUNIXのdiff(1)ツールを使用するという簡単な方法で実現していました。\n\nつまり、これらはすべて必要最低限の機能しか備えていなかったものの、履歴の追跡に必要なすべての役割を果たしていました。以下のように制限は多数ありました。\n\n- あるコミットから別のコミットへ簡単に切り替える方法がなかった。\n- ログを表示できなかった。\n- ブランチやtag、また参照すら存在しなかった。そのため、ユーザーは手動でオブジェクトIDを追跡しなければならなかった。\n- 2つのリポジトリを相互に同期させる方法がなかった。代わりに、ユーザーがrsync(1)を使用して、`.dircache`ディレクトリを同期させる必要があった。\n- マージの実行方法がなかった。\n\n## Git 0.99\n\nGitの最初のテストリリースは、バージョン0.99でした。バージョン0.99は、最初のコミットからわずか2か月後にリリースされたものの、すでに1,076件のコミットが追加されていました。約50人のデベロッパーが開発に携わっており、最も頻繁にコミットを行っていたのはTorvalds氏自身でした。トーバルズ氏に続く勢いで、コミット件数の多かったコミッターは、現在メンテナーを務めている濱野純氏でした。\n\n最初のコミット以降、多数の変更が加えられました。\n\n- Gitは参照を使って複数の開発ブランチを追跡するようになりました。その結果、大抵の場合、手作業でオブジェクトIDを追跡せずに済むようになりました。\n- 新たにリモートプロトコルが導入され、2つのリポジトリ間で相互にオブジェクトを交換できるようになりました。\n- `.dircache`ディレクトリの名前が`.git`に変更されました。\n- 個々のファイルを相互にマージできるようになりました。\n\nただし、最も重要かつ顕著な変化は、トップレベルの`git`コマンドとそのサブコマンドが導入されたことでした。興味深いことに、「配管（plumbing）」コマンドと「磁器（porcelain）」コマンドの概念が導入されたのも、このリリースです。\n\n- 「配管」ツールは、基盤となるGitリポジトリにアクセスして低レベルな処理を行うコマンドです。\n- 「磁器」ツールは、「配管」コマンドをラップして、高レベルでよりユーザーフレンドリーなユーザーインターフェイスを提供するShellスクリプトです。\n\nGitには現在でもこの分け方は採用されており、[`git(1)`](https://git-scm.com/docs/git#_high_level_commands_porcelain)にも概説されています。しかしながら、「磁器」ツールの大半はShellスクリプトからC言語に書き直されたため、これらの2つのカテゴリ間の境界線はかなり曖昧になってきています。\n\n## Torvalds氏、メンテナーの役割を濱野氏に引き継ぐ\n\nTorvalds氏がGitに取り掛かった理由は、バージョン管理システムが好きだったためではなく、Linuxカーネル開発のためにBitKeeperの代替ツールを必要としていたためです。そのため、Gitのメンテナンスをずっと続けるつもりはなく、信頼できる人が現れるまで、メンテナーを務めようと考えていました。\n\nその条件に当てはまったのが、濱野純氏でした。濱野氏は、Torvalds氏が最初のコミットを行った約1週間後にGitの開発に参加しました。Git 0.99のリリース後にはすでに数百件のコミットを行っていました。そのため、2005年7月26日に、[Torvalds氏は濱野氏をGitプロジェクトの新たなメンテナーに任命しました](https://lore.kernel.org/git/Pine.LNX.4.58.0507262004320.3227@g5.osdl.org/)。Torvalds氏は引き続きGitにコントリビュートしているものの、徐々にGitプロジェクトへの関わりは薄れていきました。これは、Linuxプロジェクトの責任者として多忙を極めているため、当然のことでした。\n\n現在でも、引き続き濱野氏がGitプロジェクトを率いています。\n\n## Git 1.0\n\n濱野氏は、2025年12月21日にGitの最初のメジャーリリースを行いました。興味深いことに、バージョン0.99から1.0の間には、34回もリリースが行われました（0.99.1～0.99.7、0.99.7a～0.99.7d、0.99.8～0.99.8g、0.99.9～0.99.9n）。\n\n0.99以降の特に重要なマイルストーンのひとつは、おそらく2つのツリーを相互にマージできる`git-merge(1)`コマンドの追加でしょう。それまでは基本的にファイルのマージを行う場合、ファイルごとにスクリプトを作成する必要があったことを考えると、非常に対照的です。\n\n### リモート\n\nもう1つの大きな変化は、リモートリポジトリの省略記法が導入されたことです。すでにGitからリモートリポジトリを操作することはできましたが、変更をフェッチする際に毎回、対象のリポジトリのURLを指定する必要がありました。通常は同じリモートリポジトリと何度もやり取りを行うため、これはユーザーにとってかなり使い勝手の悪い仕様でした。\n\n現在のremoteコマンドの仕組みはご存知だと思いますが、当時の仕組みはまだ大きく異なっていました。リモートリポジトリを管理するための`git-remote(1)`コマンドはまだ存在しておらず、リモートリポジトリの情報は`.git/config`ファイルに保存すらされていませんでした。実のところ、バージョン0.99.2でremoteコマンドが最初に導入された際、Gitにはconfigファイル自体*ありませんでした*。\n\n代わりに、`.git/branches`に直接ファイルを書き込んでリモートリポジトリの設定を行う必要がありました。今となってはあまり直感的な方法とは思えません。しかしながら、この仕組みは今でも動作します。\n\n```shell\n$ git init repo --\nInitialized empty Git repository in /tmp/repo/.git/\n$ cd repo\n$ mkdir .git/branches\n$ echo https://gitlab.com/git-scm/git.git >.git/branches/origin\n$ git fetch origin refs/heads/master\n```\n\nそれだけではなく、その直後にGitバージョン0.99.5でディレクトリ名が「remotes」に変更されたため、現在のGitクライアントではリモートリポジトリの設定方法が全部で3つあります。\n\nおそらく多くの方は、`.git/branches`も`.git/remotes`も使ったことがないと思います。これらはそれぞれ、2005年、および2011年以降、非推奨化されています。また、最終的にこれらのディレクトリは、Git 3.0で削除される予定です。\n\n## Gitのブランディング\n\n2007年に、Gitの最初のロゴが作成されました。これは、単に3つの緑のプラス記号の上に3つの赤いマイナス記号が配置された構成（`git diff`の出力がどのように見えるかを表していた）だったため、ロゴと呼べるかどうかについては、議論の余地があります。\n\n![`git diff`の出力がどのように見えるかを表し、3つの緑のプラス記号の上に3つの赤いマイナス記号が配置されている](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097387927.png)\n\nそれから少し経った2008年に、ウェブサイト[git-scm.com](https://git-scm.com)が公開されました。\n\n![2026年時点でのgit-scm.comのランディングページ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097387930.png)\n\n2012年に、Scott Chacon氏とJason Long氏によって、Gitのウェブサイトは[リニューアル](https://lore.kernel.org/git/CAP2yMaJy=1c3b4F72h6jL_454+0ydEQNXYiC6E-ZeQQgE0PcVA@mail.gmail.com/)されました。ご覧のように現在の外観にかなり近くなりました。\n\n![2012年にリニューアルされたGitウェブサイト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097387932.png)\n\n再デザインされたウェブサイトには、Jason Long氏がデザインし、今でも使用されている新しい赤橙色のロゴが目立つように掲載されていました。\n\n![Gitロゴ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097387934.png)\n\n## Git 2.0\n\nGit 1.0のリリース時点で、すでに現在のGitとかなり同じようになってきたため、ここでGitの歴史をたどる旅の歩みをGit 2.0まで進めます。Git 1.0の約10年後にリリースされたこのバージョンは、中央ワークフローに後方互換性のない変更を意図的に含めた最初のリリースでした。\n\n### `git-push(1)`のデフォルトの動作\n\nこのリリースで最も混乱を招いたのは、間違いなく`git-push(1)`のデフォルトの動作が変更されたことです。\n\nリモートリポジトリへのプッシュ時に何をプッシュするかを具体的に指定しなかった場合、Gitは以下のいずれかのアクションを取る可能性がありました。\n\n- Gitは何も実行せず、何をプッシュするか具体的な情報をユーザーに要求する。\n- その時点でチェックアウトされているブランチをプッシュする。\n- その時点でチェックアウトされているブランチをプッシュする（ただし、リモート側に対応するブランチがあることを確認できた場合に限る）。\n- リモート側に対応するブランチが存在する全ブランチをプッシュする。\n\n現在のGitは、いわゆる「シンプル」な手法を採用しており、上記の3番目のアクションを行います。しかしながら、Git 2.0より前のバージョンにおけるデフォルトの動作は、「マッチング」手法を使用した上記の最後のアクションでした。\n\n「マッチング」手法は、現在採用されている手法と比べて、はるかにリスクがありました。プッシュする前に毎回、リモート側に対応するブランチがあるすべてのローカルブランチをプッシュしても問題がないか確認する必要がありました。そうしないと、意図せずに変更がプッシュされてしまう可能性がありました。そこでリスクを軽減し、Gitを使い始めたばかりのユーザーにとって使い勝手をよくするために「シンプル」手法が採用されました。\n\n### `git-add(1)`\n\nもう1つの大きな変化は、削除された追跡済みファイルに対する`git-add(1)`のデフォルトの動作が変更されたことです。Git 2.0より前のバージョンでは、`git-add(1)`は削除済みのファイルを自動的にステージングしませんでした。そのため、コミットに含めるには、`git-rm(1)`を使用して削除済みのファイルを1つずつ手動で追加する必要がありました。Git 2.0ではこの動作が変更され、`git-add(1)`を実行すると、削除済みのファイルもインデックスに追加されるようになりました。\n\n## Gitコミュニティの業績を称えよう\n\nおそらくみなさんGitを日々活用しているかと思いますので、Gitの現在の仕組みについて細かくはここでは取り上げません。まだ活用していない方向けには、利用開始に役立つチュートリアルが多数用意されています。現在の仕組みについて説明する代わりに、Git誕生から20年経った今でも機能するように取り組んでくださったGitコミュニティの業績を称えたいと思います。\n\nGitは、その歴史の中で以下の実績を達成してきました。\n\n- Git 2.49のリリース時点での累計コミット件数、56,721件\n- 2,000人の個人のコントリビューターによるコントリビュート\n- 公開されたメジャーリリース件数、60件\n\nまた、Gitプロジェクトは[Google Summer of Code（GSOC）](https://summerofcode.withgoogle.com/)や[Outreachy](https://www.outreachy.org/)にも参加しており、新たなコントリビューターが着実に増えています。このような新たなコントリビューターのおかげで、Gitプロジェクトは長期的に健全な状態を保てます。\n\nこの場を借りて、すべてのコントリビューターに心からお礼申し上げます。みなさんのコントリビュートのおかげで、Gitが実現しました。\n\n## 今後の展開\n\nGitがバージョン管理システムの競争で事実上勝利を収めたと言っても、異論はほとんどないでしょう。Gitは大きな市場シェアを占めており、Git以外のバージョン管理システムを使用しているオープンソースプロジェクトはほとんどありません。そう考えると、Gitが多くのことを正しく成し遂げてきたことは明らかです。\n\nとは言っても、Gitの開発は完結したわけではなく、依存として多くの課題が残されています。その例が、以下のような技術的な課題です。\n- 古くなったコードベースのモダナイゼーション  \n- 拡大し続けるモノレポのサイズに合わせたスケーリング  \n- サイズの大きいバイナリファイルの処理の改善\n\nそれとは別に、以下のような社会的な課題もあります。\n- Gitの使いやすさの向上  \n- 長期にわたってプロジェクトの健全性を確保することを目的とした、Gitコミュニティの育成  \n\n取り組むべき作業は常にあります。次の20年もGitが素晴らしいバージョン管理システムであり続けられるよう、私たちGitLabもコントリビュートできることを誇りに思います。\n\n## Git関連のその他のリソース\n\n- [Gitの生みの親であるLinus Torvalds氏と20周年を祝う](https://about.gitlab.com/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds/)\n- [Git 2.49.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-49-0/)  \n- [Git 2.48.0の新機能](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-48-0/)  \n- [初心者向けGit reftableフォーマットガイド](https://about.gitlab.com/ja-jp/blog/a-beginners-guide-to-the-git-reftable-format/)",[677,9],{"slug":744,"featured":90,"template":680},"journey-through-gits-20-year-history","content:ja-jp:blog:journey-through-gits-20-year-history.yml","Journey Through Gits 20 Year History","ja-jp/blog/journey-through-gits-20-year-history.yml","ja-jp/blog/journey-through-gits-20-year-history",{"_path":750,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":751,"content":757,"config":765,"_id":767,"_type":13,"title":768,"_source":15,"_file":769,"_stem":770,"_extension":18},"/ja-jp/blog/keeping-git-commit-history-clean",{"title":752,"description":753,"ogTitle":752,"ogDescription":753,"noIndex":6,"ogImage":754,"ogUrl":755,"ogSiteName":667,"ogType":668,"canonicalUrls":755,"schema":756}," git Commit（コミット）の履歴が重要な理由とその整理方法","git コミット履歴は、煩雑になりがち。gitコミットのメッセージ履歴をクリーンに保ち、変更内容を把握する方法とその重要性をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659457/Blog/Hero%20Images/keep-git-commit-history-clean.jpg","https://about.gitlab.com/blog/keeping-git-commit-history-clean","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \" git Commit（コミット）の履歴が重要な理由とその整理方法\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kushal Pandya\"}],\n        \"datePublished\": \"2018-06-07\",\n      }",{"title":752,"description":753,"authors":758,"heroImage":754,"date":760,"body":761,"category":762,"tags":763,"updatedDate":764},[759],"Kushal Pandya","2018-06-07","## 目次\n\n\n- git コミットの履歴が重要な理由\n\n- 直前のgitコミットメッセージを変更する\n\n- ２つ以上前のgitコミットの内容を修正する\n\n- 修正用に作ったgitコマンドは元のコミットと組み合わせて履歴をクリーンに保つ\n\n- gitコミットのセーフティネット reflogs\n\n- gitコミットを整理して、未来の開発に備えよう\n\n\ngitコミットは、リポジトリの重要な要素のひとつであり、コミットメッセージはリポジトリの履歴ログでもあります。プロジェクトやリポジトリがチームメンバーに編集・更新（新機能の追加、バグ修正、アーキテクチャのリファクタリングなど）されていくなかで、コミットメッセージは何がどのように変更されたのかを知るための重要な手掛かりとなります。そのため、コミットメッセージは基本的な変更を、簡潔かつ正確に反映することが求められます。\n\n\n## git コミットの履歴が重要な理由\n\n\ngitコミットメッセージは、あなたが触れたコードに残す指紋のようなものです。あなたが今日コミットしたコードには、一年後に同じ変更を見たときにもすぐに理解できるよう、簡潔で正確なメッセージが添えてあるべきです。gitコミットがコンテキストに基づいて分割されていれば、該当のコミットで発生したバグを素早く見つけられ、バグの原因となるコミットを元通りに修正することができます。大規模なプロジェクトで作業していると、常に多数の更新、追加、削除が発生します。そのような場合に、適切なコミットメッセージの記載は不可欠になります。この記事では、gitリポジトリでの作業中に開発者がよく使うgitコミットについて解説していきます。\n\nこの記事では、git\nの基本的な知識、ブランチの仕組み、ブランチの未コミットの変更をステージングす方法、変更をコミットする方法について理解していることを前提としています。これらの流れがよくわからないという方は、こちらのGitLabドキュメントもご参照ください。\n\n\n- [Situation 1: I need to change the most recent\ncommit](#situation-1-i-need-to-change-the-most-recent-commit)\n\n- [Situation 2: I need to change a specific\ncommit](#situation-2-i-need-to-change-a-specific-commit)\n\n- [Situation 3: I need to add, remove, or combine\ncommits](#situation-3-i-need-to-add-remove-or-combine-commits)\n\n- [Situation 4: My commit history doesn't make sense, I need a fresh\nstart!](#situation-4-my-commit-history-doesnt-make-sense-i-need-a-fresh-start)\n\n\nBut before we dive in, let's quickly go through what a typical development\nworkflow looks like in our hypothetical Ruby application.\n\n\n**Note:** This article assumes that you are aware about basics of Git, how\nbranches work, how to add uncommitted changes of a branch to stage and how\nto commit the changes. If you're unsure of these flows, [our\ndocumentation](https://docs.gitlab.com/ee/topics/git/index.html) is a great\nstarting point.\n\n\n## A day in the life\n\n\nHere, we are working on a small Ruby on Rails project where we need to add a\nnavigation view on the homepage and that involves updating and adding\nseveral files. Following is a step by step breakdown of the entire flow:\n\n\n- You start working on a feature with updating a single file; let's call it\n`application_controller.rb`\n\n- This feature requires you to also update a view: `index.html.haml`\n\n- You added a partial which is used in index page: `_navigation.html.haml`\n\n- Styles for the page also need to be updated to reflect the partial we\nadded: `styles.css.scss`\n\n- Feature is now ready with the desired changes, time to also update tests;\nfiles to be updated are as follows:\n  - `application_controller_spec.rb`\n  - `navigation_spec.rb`\n- Tests are updated and passing as expected, now time to commit the changes!\n\n\nSince all the files belong to different territories of the architecture, we\ncommit the changes isolated of each other to ensure that each commit\nrepresents a certain context and is made in a certain order. I usually\nprefer backend -> frontend order where most backend-centric change is\ncommitted first, followed by the middle layer and then by frontend-centric\nchanges in the Git list commits.\n\n\n1.  `application_controller.rb` & `application_controller_spec.rb`; **Add\nroutes for navigation**.\n\n2.  `_navigation.html.haml` &  `navigation_spec.rb`; **Page Navigation\nView**.\n\n3.  `index.html.haml`; **Render navigation partial**.\n\n4.  `styles.css.scss`; **Add styles for navigation**.\n\n\nNow that we have our changes committed, we create a merge request with the\nbranch. Once you have merge request open, it typically gets reviewed by your\npeer before the changes are merged into repo's `master` branch. Now let's\nlearn what different situations we may end up with during code review.\n\n\n## Situation 1: How to change the most recent Git commit\n\n\nImagine a case where the reviewer looked at `styles.css.scss` and suggested\na change. In such a case, it is very simple to do the change as the\nstylesheet changes are part of **last** commit on your branch. Here's how we\ncan handle this;\n\n\n- You directly do the necessary changes to `styles.css.scss` in your current\nbranch.\n\n- Once you're done with the changes, add these changes to stage; run `git\nadd styles.css.scss`.\n\n- Once changes are staged, we need to _add_ these changes to our last\ncommit; run `git commit --amend`.\n  -  **Command breakdown**: Here, we're asking the `git commit` command to _amend_ whatever changes are present in stage to the most recent commit.\n- This will open your last commit in your Git-defined text editor which has\nthe commit message **Add styles for navigation**.\n\n- Since we only updated the CSS declaration, we don't need to alter the\ncommit message. At this point, you can just save and exit the text editor\nthat Git opened for you and your changes will be reflected in the commit.\n\n\nSince you modified an existing Git commit, these changes are required to be\n_force pushed_ to your remote repo using `git push --force-with-lease\n\u003Cremote_name> \u003Cbranch_name>`. This command will override the commit `Add\nstyles for navigation` on remote repo with updated commit that we just made\nin our local repo.\n\n\nOne thing to keep in mind while force pushing branches is that if you are\nworking on the same branch with multiple people, force pushing may cause\ntrouble for other users when they try to normally push their changes on a\nremote branch that has new commits force pushed. Hence, use this feature\nwisely. You can learn more about Git force push options\n[here](https://git-scm.com/docs/git-push#git-push---no-force-with-lease).\n\n\n## Situation 2: How to change a specific Git commit changes\n\n\nIn the previous situation, the Git commit change was rather simple as we had\nto modify only our last Git commit, but imagine if reviewer suggested to\nchange something in `_navigation.html.haml`. In this case, it is second\ncommit from the top, so changing it won't be as direct as it was in the\nfirst situation. Let's see how we can handle this:\n\n\nWhenever a commit is made in a branch, it is identified by a unique SHA-1\nhash string. Think of it as a unique ID that separates one commit from\nanother. You can view all the previous commits, along with their SHA-1\nhashes in a branch by running the `git log` command. With this, you would\nsee an output that looks somewhat as follows and is a list of commits, where\nthe most recent commits are at the top;\n\n\n```\n\ncommit aa0a35a867ed2094da60042062e8f3d6000e3952 (HEAD ->\nadd-page-navigation)\n\nAuthor: Kushal Pandya \u003Ckushal@gitlab.com>\n\nDate: Wed May 2 15:24:02 2018 +0530\n\n    Add styles for navigation\n\ncommit c22a3fa0c5cdc175f2b8232b9704079d27c619d0\n\nAuthor: Kushal Pandya \u003Ckushal@gitlab.com>\n\nDate: Wed May 2 08:42:52 2018 +0000\n\n    Render navigation partial\n\ncommit 4155df1cdc7be01c98b0773497ff65c22ba1549f\n\nAuthor: Kushal Pandya \u003Ckushal@gitlab.com>\n\nDate: Wed May 2 08:42:51 2018 +0000\n\n    Page Navigation View\n\ncommit 8d74af102941aa0b51e1a35b8ad731284e4b5a20\n\nAuthor: Kushal Pandya \u003Ckushal@gitlab.com>\n\nDate: Wed May 2 08:12:20 2018 +0000\n\n    Add routes for navigation\n```\n\n\nThis is where `git rebase` command comes into play. Whenever we wish to edit\na specific commit with `git rebase`, we need to first rebase our branch by\nmoving back HEAD to the point right _before_ the commit we wish to edit. In\nour case, we need to change the commit that reads `Page Navigation View`.\n\n\n![Commit\nLog](https://about.gitlab.com/images/blogimages/keeping-git-commit-history-clean/GitRebase.png){:\n.shadow.center.medium}\n\n\nHere, notice the hash of commit which is right before the commit we want to\nmodify; copy the hash and perform the following steps:\n\n\n- Rebase the branch to move to commit before our target commit; run `git\nrebase -i 8d74af102941aa0b51e1a35b8ad731284e4b5a20`\n  -  **Git command breakdown**: Here we're running Git's `rebase` command with _interactive_ mode with provided SHA-1 hash as commit to rebase to.\n- This will run rebase command for Git in interactive mode and will open\nyour text editor showing all of your commits that came _after_ the commit\nyou rebased to. It will look somewhat like this:\n\n\n```\n\npick 4155df1cdc7 Page Navigation View\n\npick c22a3fa0c5c Render navigation partial\n\npick aa0a35a867e Add styles for navigation\n\n\n# Rebase 8d74af10294..aa0a35a867e onto 8d74af10294 (3 commands)\n\n#\n\n# Commands:\n\n# p, pick = use commit\n\n# r, reword = use commit, but edit the commit message\n\n# e, edit = use commit, but stop for amending\n\n# s, squash = use commit, but meld into previous commit\n\n# f, fixup = like \"squash\", but discard this commit's log message\n\n# x, exec = run command (the rest of the line) using shell\n\n# d, drop = remove Git commit\n\n#\n\n# These lines can be re-ordered; they are executed from top to bottom.\n\n#\n\n# If you remove a line here THAT COMMIT WILL BE LOST.\n\n#\n\n# However, if you remove everything, the rebase will be aborted.\n\n#\n\n# Note that empty commits are commented out\n\n```\n\n\nNotice how each commit has a word `pick` in front of it, and in the contents\nbelow, there are all possible keywords we can use. Since we want to _edit_ a\ncommit, we need to change `pick 4155df1cdc7 Page Navigation View` to `edit\n4155df1cdc7 Page Navigation View`. Save the changes and exit editor.\n\n\nNow your branch is rebased to the point in time right before the commit you\nmade which included `_navigation.html.haml`. Open the file and perform\ndesired changes as per the review feedback. Once you're done with the\nchanges, stage them by running `git add _navigation.html.haml`.\n\n\nSince we have staged the changes, it is time to move branch HEAD back to the\ncommit we originally had (while also including the new changes we added),\nrun `git rebase --continue`, this will open your default editor in the\nterminal and show you the commit message that we edited during rebase; `Page\nNavigation View`. You can change this message if you wish, but we would\nleave it as it is for now, so save and exit the editor. At this point, Git\nwill replay all the commits that followed after the commit you just edited\nand now branch `HEAD` is back to the top commit we originally had, and it\nalso includes the new changes you made to one of the commits.\n\n\nSince we again modified a commit that's already present in remote repo, we\nneed force push this branch again using `git push --force-with-lease\n\u003Cremote_name> \u003Cbranch_name>`.\n\n\n## Situation 3: How to add, remove, or combine Git commits\n\n\nA common situation is when you've made several commits just to fix something\npreviously committed. Now let's reduce them as much as we can, combining\nthem with the original commits.\n\n\nAll you need to do is start the interactive rebase as you would in the other\nscenarios.\n\n\n```\n\npick 4155df1cdc7 Page Navigation View\n\npick c22a3fa0c5c Render navigation partial\n\npick aa0a35a867e Add styles for navigation\n\npick 62e858a322 Fix a typo\n\npick 5c25eb48c8 Ops another fix\n\npick 7f0718efe9 Fix 2\n\npick f0ffc19ef7 Argh Another fix!\n\n```\n\n\nNow imagine you want to combine all those fixes into `c22a3fa0c5c Render\nnavigation partial`. You just need to:\n\n\n1. Move the fixes up so that they are right below the commit you want to\nkeep in the end.\n\n2. Change `pick` to `squash` or `fixup` for each of the fixes.\n\n\n*Note:* `squash` keeps the git fix commit messages in the description.\n`fixup` will forget the commit messages of the fixes and keep the original.\n\n\nYou'll end up with something like this:\n\n\n```\n\npick 4155df1cdc7 Page Navigation View\n\npick c22a3fa0c5c Render navigation partial\n\nfixup 62e858a322 Fix a typo\n\nfixup 5c25eb48c8 Ops another fix\n\nfixup 7f0718efe9 Fix 2\n\nfixup f0ffc19ef7 Argh Another fix!\n\npick aa0a35a867e Add styles for navigation\n\n```\n\n\nSave the changes, exit the editor, and you're done! This is the resulting\nhistory:\n\n\n```\n\npick 4155df1cdc7 Page Navigation View\n\npick 96373c0bcf Render navigation partial\n\npick aa0a35a867e Add styles for navigation\n\n```\n\n\nAs before, all you need to do now is `git push --force-with-lease\n\u003Cremote_name> \u003Cbranch_name>` and the changes are up.\n\n\nIf you want to remove a Git commit from branch altogether, instead of\n`squash` or `fixup`, just write `drop` or simply delete that line.\n\n\n### How to avoid Git commit conflicts\n\n\nTo avoid conflicts, make sure the commits you're moving up the timeline\naren't touching the same files touched by the commits left after them.\n\n\n```\n\npick 4155df1cdc7 Page Navigation View\n\npick c22a3fa0c5c Render navigation partial\n\nfixup 62e858a322 Fix a typo                 # this changes styles.css\n\nfixup 5c25eb48c8 Ops another fix            # this changes image/logo.svg\n\nfixup 7f0718efe9 Fix 2                      # this changes styles.css\n\nfixup f0ffc19ef7 Argh Another fix!          # this changes styles.css\n\npick aa0a35a867e Add styles for navigation  # this changes index.html (no\nconflict)\n\n```\n\n\n### Pro-tip: Quick Git commit `fixup`s\n\n\nIf you know exactly which commit you want to fixup, when committing you\ndon't have to waste brain cycles thinking of good temporary names for \"Fix\n1\", \"Fix 2\", ..., \"Fix 42\".\n\n\n**Step 1: Meet `--fixup`**\n\n\nAfter you've staged the changes fixing whatever it is that needs fixing,\njust Git commit all the changes like this:\n\n\n```\n\ngit commit --fixup c22a3fa0c5c\n\n```\n\n(Note that this is the hash for the commit `c22a3fa0c5c Render navigation\npartial`)\n\n\nThis will generate this commit message: `fixup! Render navigation partial`.\n\n\n**Step 2: And the sidekick `--autosquash`**\n\n\nEasy interactive rebase. You can have `git` place the `fixup`s automatically\nin the right place.\n\n\n`git rebase -i 4155df1cdc7 --autosquash`\n\n\nHistory will be shown like so:\n\n```\n\npick 4155df1cdc7 Page Navigation View\n\npick c22a3fa0c5c Render navigation partial\n\nfixup 62e858a322 Fix a typo\n\nfixup 5c25eb48c8 Ops another fix\n\nfixup 7f0718efe9 Fix 2\n\nfixup f0ffc19ef7 Argh Another fix!\n\npick aa0a35a867e Add styles for navigation\n\n```\n\n\nReady for you to just review and proceed.\n\n\nIf you're feeling adventurous you can do a non-interactive rebase `git\nrebase --autosquash`, but only if you like living dangerously, as you'll\nhave no opportunity to review the squashes being made before they're\napplied.\n\n\n## Situation 4: My Git commit history doesn't make sense, I need a fresh\nstart!\n\n\nIf we're working on a large feature, it is common to have several fixup and\nreview-feedback changes that are being committed frequently. Instead of\nconstantly rebasing the branch, we can leave the cleaning up of Git commits\nuntil the end of development.\n\n\nThis is where creating patch files is extremely handy. In fact, patch files\nwere the primary way of sharing code over email while collaborating on large\nopen source projects before Git-based services like GitLab were available to\ndevelopers. Imagine you have one such branch (eg; `add-page-navigation`)\nwhere there are tons of commits that don't convey the underlying changes\nclearly. Here's how you can create a patch file for all the changes you made\nin this branch:\n\n\n- The first step to create the patch file is to make sure that your branch\nhas all the changes present from `master` branch and has no conflicts with\nthe same.\n\n- You can run `git rebase master` or `git merge master` while you're checked\nout in `add-page-navigation` branch to get all the changes from `master` on\nto your branch.\n\n- Now create the patch file; run `git diff master add-page-navigation >\n~/add_page_navigation.patch`.\n  -  **Command breakdown**: Here we're using Git's _diff_ feature, and asking for a diff between `master` branch and `add-page-navigation` branch, and _redirecting_ the output (via `>` symbol) to a file named `add_page_navigation.patch` in our user home directory (typically `~/` in *nix operating systems).\n- You can specify any path you wish to keep this file in and the file name\nand extension could be anything you want.\n\n- Once the command is run and you don't see any errors, the patch file is\ngenerated.\n\n- Now checkout `master` branch; run `git checkout master`.\n\n- Delete the branch `add-page-navigation` from local repo; run `git branch\n-D add-page-navigation`. Remember, we already have changes of this branch in\na created patch file.\n\n- Now create a new branch with the same name (while `master` is checked\nout); run `git checkout -b add-page-navigation`.\n\n- At this point, this is a fresh branch and doesn't have any of your\nchanges.\n\n- Finally, apply your changes from the patch file; `git apply\n~/add_page_navigation.patch`.\n\n- Here, all of your changes are applied in a branch and they will appear as\nuncommitted, as if all your modification where done, but none of the\nmodifications were actually committed in the branch.\n\n- Now you can go ahead and commit individual files or files grouped by area\nof impact in the order you want with concise commit messages.\n\n\nAs with previous situations, we basically modified the whole branch, so it\nis time to force push!\n\n\n## Git commit history: Conclusion\n\n\nWhile we have covered most common and basic situations that arise in a\nday-to-day workflow with Git, rewriting Git history is a vast topic and as\nyou get familiar with above tips, you can learn more advanced concepts\naround the subject in the [Git Official\nDocumentation](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History).\nHappy git'ing!\n\n\nPhoto by [pan\nxiaozhen](https://unsplash.com/photos/pj-BrFZ9eAA?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\non\n[Unsplash](https://unsplash.com/search/photos/clean?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n\n{: .note}\n\n> \n\n\n\u003Cbr>\u003Cbr>\n\n*監修：知念 梨果 [@rikachinen](https://gitlab.com/rikachinen)* \u003Cbr>\n\n*（GitLab合同会社 カスタマーサクセス本部 カスタマーサクセスエンジニア）*\n","engineering",[9,702],"2025-06-12",{"slug":766,"featured":6,"template":680},"keeping-git-commit-history-clean","content:ja-jp:blog:keeping-git-commit-history-clean.yml","Keeping Git Commit History Clean","ja-jp/blog/keeping-git-commit-history-clean.yml","ja-jp/blog/keeping-git-commit-history-clean",{"_path":772,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":773,"content":779,"config":785,"_id":787,"_type":13,"title":788,"_source":15,"_file":789,"_stem":790,"_extension":18},"/ja-jp/blog/mastering-the-basics-of-git-push-tag",{"title":774,"description":775,"ogTitle":774,"ogDescription":775,"noIndex":6,"ogImage":776,"ogUrl":777,"ogSiteName":667,"ogType":668,"canonicalUrls":777,"schema":778},"git pushタグの基本を徹底攻略","git pushコマンドで、他の開発者とバージョンやリリース情報、マイルストーンをタグを使用して共有する方法とコツをご紹介。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665200/Blog/Hero%20Images/gitpush.jpg","https://about.gitlab.com/blog/mastering-the-basics-of-git-push-tag","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"git pushタグの基本を徹底攻略\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2024-12-19\",\n      }",{"title":774,"description":775,"authors":780,"heroImage":776,"date":782,"body":783,"category":675,"tags":784},[781],"GitLab","2024-12-19","gitを使った開発で最もよく利用するコマンドのひとつ`git push`。ローカルリポジトリのオブジェクトをリモートリポジトリに送信して更新を行うコマンドです。タグ機能と組み合わせて開発途中の特定の時点に参照しやすいように名前をつけておくことで、後から遡って異なるバージョンを比較できます。この記事では`git push`コマンドの基本について解説していきます。\n\n- git pushタグとは？\n- gitタグを使うメリットとは？\n- gitタグの種類\n- よく使うgitタグ   \n- git pushコマンドでコミットやタグをプッシュする方法\n- git pushとgit pushタグを使うためのベストプラクティス\n- GitLabでgitタグを使う\n- git pushタグのFAQ\n\n## git pushタグとは？\n`git push` タグとは、リポジトリ内でタグづけされたコミットを、リモートリポジトリにプッシュするためのコマンドです。ローカルで作成したタグをリモートリポジトリに送信し、複数人で特定のバージョンやマイルストーンを共有するのに有用です。\n\n例えば、`v1.0`というタグを`origin`という名前のリモートリポジトリにプッシュするには下記のように記載します。\n\n    git push origin v1.0\n\n## gitタグを使うメリットとは\ngitタグとは、本のしおりのようにプロジェクト履歴の中で特定のコミットに名前をつけられる機能です。特定のタグをタグ名で簡単に参照できることが最大のメリットで、新バージョンのリリースや、大規模な変更を実施する前のコードベースなど、その時点まで戻って参照する可能性のあるコミットにタグをつけて管理します。\n\n## gitタグの種類\ngitのタグには、主に2つの種類があります。\u003Cbr>\u003Cbr>\n\n1. 軽量タグ（Lightweight Tags）:\n\n軽量タグは、コミットに名前をつけるだけの単純なタグです。基本的にはコミットの名前とポインターですが、関連するコミットへのクイックリンクの作成などに適しています。軽量タグの作成は下記の通りです。\n\n    git tag TAG_NAME\n\nバージョン管理のタグの場合は、次のように名付けます。\n\n    git tag v1.0\n\n2. アノテーション（注釈付）タグ：\n\nアノテーションタグは、タグの作成者、メールアドレス、作成した日やメッセージなど追加のメタデータも保存されます。アノテーションタグを作成するには、`-a`でタグを作成し、`-m`を指定するとコメントも同時に指定することができます。\n\n    git tag -a TAG_NAME -m \"Comments\"\n\nアノテーションタグは、チームで共有すべきリリースやバージョン管理に追加の情報を含めたいときに広く使われます。\n\n## よく使うgitタグ\n### タグを一覧で確認する\n\nリポジトリに保存されたタグを一覧表示します。\u003Cbr>\n\n    git tag\n\nワイルドカード表現を使って絞り込むこともできます。\n\n    git tag -l *SEARCH WORD*\n\n\u003CH3>タグの内容を確認する\u003C/H3>\n\nタグの内容を確認する場合は`git show`を使います。\u003Cbr>\n\n    git show TAG_NAME\n\nこれにより以下の情報が取得できます。\n- Commit：コミット番号\n- Author：実行したユーザー名\n- Date：実行した日時\n\n### 作ったタグを削除する\nタグを削除するには`git tag`コマンドのオプション`-d`を指定します。削除した後、一覧から消えているか確認しましょう。\u003Cbr>\u003Cbr>\n\n    git tag -d TAG_NAME\n\n## git pushコマンドでコミットやタグをプッシュする方法\n`git push` コマンドを使ってコミットやタグをプッシュする方法は以下の通りです。\n\u003CH3>コミットをリモートリポジトリにプッシュする\u003C/H3>\n\n    git push REMOTE_NAME BRANCH_NAME\n\nリモート名）origin\u003Cbr>\nブランチ名）mainの場合には\n\n    git push origin main\n\nとなります。\n\n\u003CH3>タグをプッシュする\u003C/H3>\n\n    git push REMOTE_NAME TAG_NAME\n\nリモート名）origin\u003Cbr>\nタグ名）v1.0の場合、\n\n    git push origin v1.0\n\nとなります。\n\n## git pushとgit pushタグを使うためのベストプラクティス\n `git push` と `git push` タグを使用する際、特にチームのバージョン管理に使われている場合に避けた方が良いことがあります。それは、一度プッシュしたタグの名前を変更することです。逆にまだプッシュしていないタグは、\u003Ccode>git tag -f TAG_NAME Commit#\u003C/code>で上書きして、正しい名前にしてからプッシュするようにしましょう。またチーム内で管理されるタグ名は、一意に決定されその存在が担保されることが何より重要になるので、プッシュする前にはタグ名を十分確認するようにしましょう。\n\n## GitLabでgitタグを使う\n簡単にgitタグを使う方法をお探しの方におすすめなのが、プラットフォームを使用することです。中でもGitLabはリモートリポジトリのホスティング、インターフェースの提供、変更内容のコードレビュー、[プッシュされたコードの自動ビルド、テスト、デプロイまで実施](https://about.gitlab.com/ja-jp/blog/how-to-keep-up-with-ci-cd-best-practices/) できます。また、プロジェクトやリポジトリごとにアクセス権を細かく管理することができるため、セキュリティの確保も可能です。\u003Cbr>\u003Cbr>\n\n[バージョン管理に使える](https://about.gitlab.com/ja-jp/solutions/source-code-management/)GitLabの無料トライアルは[こちら](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/&glm_content=default-saas-trial)からお申し込みいただけます。\u003Cbr>\u003Cbr>\n\n\u003CH2>git pushタグのFAQ\u003C/H2> \n\u003CH3>gitのタグを使うメリットは？\u003C/H3>\ngitタグの最大のメリットは特定のコミットをタグ名で簡単に参照できることです。新バージョンのリリースや、大規模な変更を実施する前のコードベースなど、その時点まで戻って参照する可能性のあるコミットにタグをつけて管理します。\n\n\u003CH3>gitタグのつけ方は？\u003C/H3>\nタグをつけるには下記の基本コードを使います。\n\n    git push REMOTE_NAME TAG_NAME\n\nリモート名）origin\u003Cbr>\nブランチ名）mainの場合には\n\n    git push origin main\n\nとなります。\n\n### プッシュしたタグを削除する方法は？\nプッシュしたタグを削除するコマンドは、\u003Cbr>\n\n    git push –delete REMOTE_NAME TAG_NAME\n\nリモート名）origin\u003Cbr>\nタグ名）v1.0の場合、\n\n    git push –delete origin v1.0\n\nとなります。\n\n### git pushタグを使うメリットは？\nコミットにタグをつけてリモートリポジトリに保存することで、ソフトウェアのリリース情報や作成者・作成日・コメントを保存できます。逆に、 [git fetchまたはgit pull](https://about.gitlab.com/ja-jp/blog/what-is-the-difference-between-git-fetch-and-git-pull/) を使用してリモートからタグを取得し、ローカルリポジトリに反映させることもできます。大幅な修正やベンチマークとなるリリースが行われた場合にも直近のバージョンや該当のリリースに戻って特定時点でのコミットを確認できます。\n\n\u003Cbr>\u003Cbr>\n\n*監修：佐々木 直晴 [@naosasaki](https://gitlab.com/naosasaki)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[9,677],{"slug":786,"featured":90,"template":680},"mastering-the-basics-of-git-push-tag","content:ja-jp:blog:mastering-the-basics-of-git-push-tag.yml","Mastering The Basics Of Git Push Tag","ja-jp/blog/mastering-the-basics-of-git-push-tag.yml","ja-jp/blog/mastering-the-basics-of-git-push-tag",{"_path":792,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":793,"content":801,"config":813,"_id":815,"_type":13,"title":816,"_source":15,"_file":817,"_stem":818,"_extension":18},"/ja-jp/blog/tutorial-automated-release-and-release-notes-with-gitlab",{"title":794,"description":795,"ogTitle":796,"ogDescription":795,"noIndex":6,"ogImage":797,"ogUrl":798,"ogSiteName":667,"ogType":799,"canonicalUrls":798,"schema":800},"チュートリアル：GitLabでリリースとリリースノートを自動化する","GitLabのChangelog APIを使用すると、リリースアーティファクト、リリースノートなどの変更をまとめた、包括的な変更履歴の生成を自動化できます。","チュートリアル：GitLabでリリース自動化とリリースノート自動生成","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659978/Blog/Hero%20Images/automation.png","https://about.gitlab.com/blog/tutorial-automated-release-and-release-notes-with-gitlab","記事","\n                        \n        {\"@context\": \" https://schema.org \",\n        \"@type\": \"Article\",\n        \"headline\": \"チュートリアル：GitLabでリリース自動化とリリースノート自動生成\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ben Ridley\"}],\n        \"datePublished\": \"2023-11-01\n      \",}",{"title":796,"description":795,"authors":802,"heroImage":797,"date":804,"body":805,"category":806,"tags":807,"updatedDate":812},[803],"Ben Ridley","2023-11-01","***2025年の更新情報**  GitLab Changelog APIは進化を続けており、今回のブログでは取り上げていない優れた新機能も追加されています。たとえば、コミット履歴からテンプレート化された値を使ってカスタムの変更履歴を提供できるようになっています。[詳しくは、変更履歴に関する公式ドキュメントをご覧ください。](https://docs.gitlab.com/user/project/changelogs/)*\n\nユーザーが頼りにしているソフトウェアを開発する際には、各リリースでの変更点を効果的に伝えることが不可欠です。新機能や変更点、削除された内容をきちんと伝えることで、ユーザーはソフトウェアを最大限に活用でき、アップグレード時の思わぬトラブルも回避できます。\n\nこれまで、リリースノートの作成や変更履歴の管理は手間のかかる作業でした。デベロッパーが外部ツールで変更を追跡したり、リリースマネージャーがマージ履歴を手作業で確認したりする必要があったためです。GitLabのChangelog APIを使うと、Gitリポジトリに記録された豊富な履歴情報を活用して、リリースノートの作成や変更履歴の管理を簡単に行うことができます。\n\nこのチュートリアルでは、GitLabを使ったリリースの自動化について詳しく説明します。リリースアーティファクトの生成、リリースノートの作成、そしてユーザーに関係する変更点をすべて網羅した包括的な変更履歴の生成方法について取り上げます。\n\n## GitLabにおけるリリース\nまずは、GitLabでリリースがどのように機能しているのかを見ていきましょう。\n\nGitLabにおけるリリースとは、Gitタグで識別される特定のコードバージョンのことを指します。このリリースには、前回のリリース以降に行われた変更内容（およびリリースノート）や、そのバージョンのコードからビルドされた関連アーティファクト（Dockerイメージ、インストールパッケージ、ドキュメントなど）が含まれます。\n\nリリースは、GitLabのUIを使って作成・管理することもできますし、Release APIを呼び出すか、CIパイプラインの中に特別な`release`ジョブを定義することでも実現できます。このチュートリアルでは、CI/CDパイプライン内の`release`ジョブを使用します。これにより、テストやコードスキャンなどに使っている自動化プロセスを、リリースの実行にも拡張できるようになります。\n\nリリースを自動化するために、まず確認しなければならないことがあります。「リリースノートや変更履歴を作成するための変更情報は、どこから取得するのか？」その答えは、Gitリポジトリです。コミットメッセージやマージコミットの履歴を通じて、豊富な開発履歴が得られます。この情報を活用して、リリースノートや変更履歴を自動生成できるか試してみましょう。\n\n## コミットトレーラーの導入\n[コミットトレーラー](https://git-scm.com/docs/git-interpret-trailers)とは、Gitのコミットメッセージの末尾に追加する、構造化されたエントリーのことです。書き方はシンプルで、`\u003CHEADER>:\u003CBODY>`という形式のメッセージをコミットの最後に追加するだけです。これにより、`git`のコマンドラインインターフェース（CLI）ツールがそれらを解析して、他のシステムで利用できるようになります。たとえば、すでに使ったことがあるかもしれませんが、`git commit --sign-off`でコミットに署名する機能もこの仕組みを使っています。これは、`Signed-off-by: \u003Cあなたの名前>`というトレーラーをコミットに追加することで実現されています。このトレーラーには、好きな構造化データを自由に追加できるので、変更履歴に役立つ情報を保存する場所として非常に便利です。\n\n実際に、コミットに`Changelog: \u003Cadded/changed/removed>`というトレーラーを使うと、GitLabのChangelog APIがそれを解析し、自動的に変更履歴を生成してくれます！\n\nそれでは、実際のコードベースに変更を加えてリリースを行い、リリースノートと変更履歴のエントリーを生成する手順を見ていきましょう。\n\n## サンプルプロジェクトについて\n今回のブログでは、シンプルなPythonのWebアプリのリポジトリを使っています。仮に、このアプリケーションのバージョン1.0.0がちょうどリリースされたばかりで、これが現在のコードのバージョンだとしましょう。また、GitLab上で1.0.0のリリースも作成してありますが、これはまだ自動化されたリリースパイプラインを作っていないため、手動で作成しました。\n\n![GitLabのUI上で、バージョン1.0.0のリリースが表示されているスクリーンショット](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/1-0-release.png)\n\n## 変更の実施\n現在は開発を急ピッチで進めている段階なので、今日はアプリケーションのバージョン2.0.0のリリース作業を進めていきます。2.0.0リリースでは、アプリに新機能の「チャットボット」を追加します。そして、量子ブロックチェーン機能は削除します。これは最初のベンチャーキャピタル向けに必要だっただけなので、もう不要です。さらに、2.0.0リリースに向けて、CI/CDパイプラインに自動リリースジョブも追加する予定です。\n\nまずは不要な機能の削除から始めましょう。不要な部分を削除したマージリクエストを作成しました。ここで重要なのは、コミットメッセージに`Changelog: removed`トレーラーを含めることです。これを行う方法はいくつかあります。たとえば、最初からコミットに直接含めたり、インタラクティブリベースを使ってCLIで後から追加したりもできます。しかし、今回の状況では、一番簡単な方法は最後にGitLabの`Edit commit message`ボタンを使って、マージコミットにトレーラーを追加する方法だと思います。\n\n![GitLabのUIに表示された、使われていない機能を削除するマージリクエストのスクリーンショット](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/remove-unused-features-mr.png)\n\nこの方法を使えば、マージコミットのタイトルをもっと簡潔なものに変更することもできます。ここでは、マージコミットのタイトルを'Remove Unused Features'に変更しました。これは変更履歴のエントリに表示されます。\n\n次に、2.0.0リリース用の新機能を追加しましょう。ここでも、新機能を含む別のマージリクエストを開き、マージコミットを編集して`Changelog: added`トレーラーを追加し、コミットのタイトルをより簡潔に編集するだけです。\n\n![GitLabのUIに表示された、新しい機能を追加するマージリクエストのスクリーンショット](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/add-chatbot-mr.png) \n\nこれで、バージョン2.0.0をリリースする準備はほとんど整いました。ただし、今回は手動でリリースを作成したくありません。そのため、リリースの前に`.gitlab-ci.yml`ファイルにいくつかのジョブを追加し、コードに`2.0.0`のような新しいバージョンのタグを付けた際に、自動でリリース処理を行い、対応するリリースノートや変更履歴のエントリを生成するようにします。\n\n**注：**変更履歴のトレーラーを強制したい場合は、[Dangerのようなツールを使用して、マージリクエストの規則を自動的にチェックする](https://docs.gitlab.com/ee/development/dangerbot.html)方法を検討してください。\n\n## 自動リリースパイプラインの構築\nパイプラインを機能させるには、プロジェクトアクセストークンを作成し、GitLabのAPIを呼び出して変更履歴のエントリーを生成できるようにする必要があります。[APIスコープを指定してプロジェクトアクセストークンを作成](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#create-a-project-access-token)し、それを`CI_API_TOKEN`という名前の[CI/CD変数として保存](https://docs.gitlab.com/ee/ci/variables/#define-a-cicd-variable-in-the-ui)します。この変数を参照して、APIの認証を行います。\n\n次に、`gitlab-ci.yml`ファイルに以下の2つの新しいジョブを追加します。\n```yaml\nprepare_job:\n  stage: prepare\n  image: alpine:latest\n  rules:\n  - if: '$CI_COMMIT_TAG =~ /^v?\\d+\\.\\d+\\.\\d+$/'\n  script:\n    - apk add curl jq\n    - 'curl -H \"PRIVATE-TOKEN: $CI_API_TOKEN\" \"$CI_API_V4_URL/projects/$CI_PROJECT_ID/repository/changelog?version=$CI_COMMIT_TAG\" | jq -r .notes > release_notes.md'\n  artifacts:\n    paths:\n    - release_notes.md\n\nrelease_job:\n  stage: release\n  image: registry.gitlab.com/gitlab-org/release-cli:latest\n  needs:\n    - job: prepare_job\n      artifacts: true\n  rules:\n  - if: '$CI_COMMIT_TAG =~ /^v?\\d+\\.\\d+\\.\\d+$/'\n  script:\n    - echo \"Creating release\"\n  release:\n    name: 'Release $CI_COMMIT_TAG'\n    description: release_notes.md\n    tag_name: '$CI_COMMIT_TAG'\n    ref: '$CI_COMMIT_SHA'\n    assets:\n      links:\n        - name: 'Container Image $CI_COMMIT_TAG'\n          url: \"https://$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA\"\n```\n\n上記の設定では、`prepare_job`が`curl`と`jq`を使ってGitLabのChangelog APIエンドポイントを呼び出し、その結果を`release_job`に渡して、リリースの作成を行います。詳しく見ていきましょう。\n- まず、先ほど作成したプロジェクトアクセストークンを使ってGitLabのChangelog APIを呼び出し、リリースノートを生成します。そして、その出力をアーティファクトとして保存します。\n- バージョンには`$CI_COMMIT_TAG`変数を使用しています。この仕組みが機能するには、タグにセマンティックバージョニング（たとえば`2.0.0`のような形式）を使用する必要があります。そのため、リリースジョブには、セマンティックバージョンのタグが付いているかどうかを確認する`rules`セクションを追加しています。\n\t- GitLabのChangelog APIを使うには、セマンティックバージョニングが必要です。この形式を用いて、現在のリリースとの比較対象となる最新リリースを特定します。\n- GitLabが提供する公式の`release-cli`イメージを使用しています。ジョブ内で`release`キーワードを使うには、この`release-cli`が必要です。\n- `release`キーワードを使用して、GitLab上にリリースを作成します。これは、リリースの作成と必須フィールドの入力のために確保されている特別なジョブキーワードです。\n- リリースの`description`には、ファイルを引数として渡すことができます。今回の例では、`prepare_job`で生成し、アーティファクトとしてこのジョブに渡されたファイルを使っています。\n- さらに、パイプラインの早い段階でビルドされているコンテナイメージも、リリースアセットとして追加しています。ビルドプロセスの中で作成したバイナリやドキュメントなども、パイプライン内でアップロード済みのURLを指定することで、リリースアセットとして添付できます。\n\n## 自動リリースの実行\nこの設定が完了すれば、リリースを実行するために必要なのは、バージョン付けのルールに従ったタグをリポジトリにプッシュすることだけです。CLIからタグをプッシュすることもできますが、ここではGitLabのUIを使って、mainブランチにタグを作成する例をご紹介します。タグを作成するには、サイドバーからコード > タグ > 新しいタグを選択します。\n![タグの作成方法を示すGitLabのUIのスクリーンショット](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/create-2-tag.png)\n\nタグの作成が完了すると、パイプラインの実行が開始されます。 GitLabのChangelog APIが、今回のリリースと前回のリリースの間に行われた変更をすべて含むリリースノートをMarkdown形式で自動的に生成します。 以下は、この例で生成されたMarkdownの出力結果です。\n\n```md\n## 2.0.0 (2023-08-25)\n\n### added (1 change)\n\n- [Add ChatBot](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo@0c3601a45af617c5481322bfce4d71db1f911b02) ([merge request](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo!4))\n\n### removed (1 change)\n\n- [Remove Unused Features](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo@463d453c5ae0f4fc611ea969e5442e3298bf0d8a) ([merge request](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo!3))\n```\n\nご覧のとおり、GitLabはgitのコミットトレーラーをもとに、リリースノートのエントリを自動で抽出しています。さらに、変更の詳細やディスカッションが確認できるよう、マージリクエストへのリンクも付けられています。\n\nそしてこちらが、最終的に作成されたリリースです。\n![GitLabのリリースUIに表示された、バージョン2.0.0のリリース画面](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/2-0-release.png)\n\n## 変更履歴の作成\n次に、変更履歴（すべてのリリースノートをまとめた履歴）を更新します。これを行うには、先ほど使用したChangelog APIエンドポイントに対して、`POST`リクエストを送ります。\n\n必要であれば、この処理をリリースパイプラインの一部として実行することも可能です。たとえば、prepareジョブの`script`セクションに以下の内容を追加します。\n```sh\n'curl -H \"PRIVATE-TOKEN: $CI_API_TOKEN\" -X POST \"$CI_API_V4_URL/projects/$CI_PROJECT_ID/repository/changelog?version=$CI_COMMIT_TAG\"\n```\n\n**この処理は実際にリポジトリを変更する点にご注意ください。** 具体的には、最新のリリースノートを`CHANGELOG.md`ファイルに追加するためのコミットが作成されます。\n![変更履歴ファイルを更新するコミットを示すリポジトリのスクリーンショット](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/changelog-api-commit.png)\n\nこれですべて完了です！`git`が提供する豊富な履歴情報と、便利なコミットトレーラーを活用することで、GitLabの強力なAPIとCI/CDパイプラインを使って、リリースプロセスとリリースノートの生成を自動化できます。\n\n> この記事で使用したプロジェクトを実際に確認したい場合は、[こちらのリンク](https://gitlab.com/gitlab-learn-labs/sample-projects/release-automation-demo)からご覧いただけます。\n","product",[808,809,108,810,811,9],"チュートリアル","CI","DevOps","DevSecOps","2025-06-05",{"slug":814,"featured":6,"template":680},"tutorial-automated-release-and-release-notes-with-gitlab","content:ja-jp:blog:tutorial-automated-release-and-release-notes-with-gitlab.yml","Tutorial Automated Release And Release Notes With Gitlab","ja-jp/blog/tutorial-automated-release-and-release-notes-with-gitlab.yml","ja-jp/blog/tutorial-automated-release-and-release-notes-with-gitlab",{"_path":820,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":821,"content":827,"config":833,"_id":835,"_type":13,"title":836,"_source":15,"_file":837,"_stem":838,"_extension":18},"/ja-jp/blog/what-is-git",{"title":822,"description":823,"ogTitle":822,"ogDescription":823,"noIndex":6,"ogImage":824,"ogUrl":825,"ogSiteName":667,"ogType":668,"canonicalUrls":825,"schema":826},"Gitとは？初心者に使い方、意味、機能、利点を徹底解説","Gitとは？管理部門やオペレーション部門、初心者には知られていないGitの基礎知識を、仕組みから利点、基礎用語、よくある質問まで徹底的に解説。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687231/Blog/Hero%20Images/Git.jpg","https://about.gitlab.com/blog/what-is-git","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Gitとは？初心者に使い方、意味、機能、利点を徹底解説\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Team\"}],\n        \"datePublished\": \"2024-10-08\",\n      }",{"title":822,"description":823,"authors":828,"heroImage":824,"date":829,"body":830,"category":675,"tags":831,"updatedDate":832},[696],"2024-10-08","## 目次\n- Gitとは何か？ \n- Gitの意味\n- Gitは何に使われている？\n- Gitの利点とは？\n- Gitの何がすごい？\n- 組織がGitを使ってできること \n- Gitの用語と使い方の初心者向け解説\n- Gitの弱点は？\n- Gitの管理はツールで手軽に \n- まとめ \n\nGit（ギット）という言葉をエンジニアや開発者が口にするのを耳にしたことがある方は多いはずです。プロジェクトを走らせながらツールやサービスの改善を行う[アジャイル手法](https://about.gitlab.com/ja-jp/topics/agile-delivery/agile-methodology/)が基本の今、業務効率化のためにGitを使用するのは当たり前となってきました。ただ、IT関連企業だったとしても、マネジメントやオペレーション部門などで働く非エンジニアや初心者は、Gitとは何か、なぜ世界で広く使われているのか、その理由を明確には理解していないかもしれません。\n\nしかし、Gitは開発部門だけではなく、チーム内の複数のメンバーが同時に作業を行う場合（たとえば人事部門で社外の専門家に相談しながら社則の見直しと刷新を行う、デザイン部門でブランドロゴのデザインを行うなど）にも、とても便利なツールです。また、プロジェクトの大きさや用途によっては、ノーコスト／ローコストで導入を[お試しできる点](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/&glm_content=default-saas-trial)も見逃せません。\n\nこの記事では、初めてGitに触れる方のために、Gitとは何か、組織にとってどんな利点があるのかを詳しく解説していきます。\n\n## Gitとは何か？\n\nGitとは、分散型バージョン管理システムで、ファイルのバージョン管理が簡単にできるツールです。「文書作成アプリケーションでも変更履歴を保存して表示できるし、それとどう違う？」「分散型バージョン管理システムっていったい何？」といった疑問も浮かぶことでしょう。この疑問については後ほど詳しく説明します。\n\n## Gitの意味\n\nそもそもGitとは「Global Information Tracker（グローバルインフォメーショントラッカー）」の頭文字を取っていると言われています。つまり、Gitは包括的（Global）に変更履歴情報（Information）の追跡（Tracker）を行うツールという意味です。\n\nここで注目しておきたいのは「包括的」という言葉です。文章作成ソフトの変更履歴と違い、ただ単にバージョン履歴を保存するだけではない点です。\n\n## Gitは何に使われている？\n\nGitはファイルやコードのバージョン管理に使われます。バージョン管理システムとは、その名のとおりファイルやコードなどの変更（バージョン）を管理するシステムであり、チーム全体での調整、共有、コラボレーションを容易にします。\n\nあるファイルを作成した後、時間が経つにつれ変更点が複雑になり、ファイルの本筋がどこにあるのかわかりにくくなることがあります。たとえば、ミーティングの議事録について考えてみましょう。議事録をプロジェクトチームに共有し、欠席者がその内容について質問コメントを残し、ある人が補足情報を足し、別の人が会議中生じた確認事項を追記し、また別のある人が補足情報の一部を削除する。このように複数の関係者が何度も編集することで各時点で実施された変更を正確に把握することは難しくなっていきます。\n\n![迷路化したバージョンの中心にGitLabのアイコン](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687243/Blog/Content%20Images/version-control.svg)\n\nバージョン管理システムは、ファイルのすべての変更を追跡し、以前のバージョンに戻ってシームレスに共同作業できるようにする非常に便利なツールです。\n\n### Gitの機能とは\n\nGitを含むバージョン管理システムには、主に次の3つの機能があります。\n\n1. ファイル共有：チーム内でファイルを共有\n2. ファイル同期：変更点を同期\n3. ファイルバックアップ：変更点を保存\n\nまた、バージョン管理システムの種類には、次の2つがあります。\n1. 中央集中型管理システム：Subversion（SVN）、Concurrent Version System（CVS）\n2. 分散型管理システム：Git、Mercurial、Bazaar、Fossil\n\n## Gitの利点とは？\n\nそれでは、Gitのような分散型管理システムの利点は何でしょうか？それを理解するために、まず2つのバージョン管理システムの仕組みを説明します。\n\n### 中央集中型バージョン管理システムの仕組み\n\n中央集中型バージョン管理システム（CVCS）では、すべてのバージョンを1つのサーバーに格納します。プロジェクトメンバーはそのサーバーにアクセスしてファイルを更新します。ある人が更新を行っている場合、他の人はそのファイルで作業できません。基本的に作業はオンラインで行い、変更点はサーバーによってきちんと保存およびカタログ化されます。このシステムはいたってシンプルであり、変更を管理する方法が簡単であるため、チームの規模が小さい場合に有効です。しかし、編集作業自体が複雑になってしまうため、更新を行ったメンバー同士の衝突が起こる場合もあります。\n\n### 分散型バージョン管理システムの仕組み\n\n一方、Gitのような分散型バージョン管理システム（DVCS）の利点は、柔軟性の高さです。分散型では、ファイルをサーバーで一元管理するだけに終わりません。 各プロジェクトメンバーはプロジェクト履歴全体をローカルに保持して、オフラインで作業できます。その作業結果を確認後、サーバーにアップすると、サーバー上でバージョンの保存およびカタログ化が行われます。したがって、中央集中型バージョン管理システムよりも、多様なバージョンの分岐ができ、またバージョンのマージ（結合）も容易になります。\n\n### 時代にフィットするGit\n\nハイブリッドやリモートなどさまざまな働き方が当たり前となった昨今、Gitのような分散型バージョン管理システムの柔軟性は、複数のプロジェクトを走らせたり織り交ぜたりするダイナミックなチームにとって不可欠な存在となっています。両者の違いを表で確認しましょう。\n\n| バージョン管理システム名 | 利点 |\n| :---- | ----- |\n| 中央集中型（CVCS） | ・小・中規模なチーム向き ・作業は基本的にオンラインで行う ・すべてのバージョンを1つのサーバーに ・管理がシンプル |\n| 分散型（DVCS） Gitほか | ・大規模のチームにも対応 ・プロジェクト履歴を各メンバーがローカルに保持 ・オフラインで作業できる ・より優れたアイディアが公平に取り入れられやすい ・柔軟性が高い ・バージョンの分岐やマージが簡単 |\n\n## Gitの何がすごい？  \n分散型バージョン管理システムの優れた点を説明してきましたが、Gitを使うメリットは、ずばり「開発業務の効率が上がること」です。プロジェクトメンバーが同時に作業でき、プログラムの共有を容易に行えるため、管理しやすいのです。また、開発過程で修正点やバグへの対処が必要となるのはよくあることですが、その際も管理されたバージョン履歴をたどって迅速に原因の特定ができます。そのため、迅速に対処できるのです。\n\n## 組織がGitを使ってできること\n\nここで改めてGitを導入してできることを具体的に挙げてみます。\n- 新旧のバージョンを一元管理できる\nGitを使うことで、ファイルの新旧を一元的に管理できます。変更をした際、いちいちファイル名に日時や「.V2」などの名前を付け、どのファイルが新しいのか見分けがつくようにする手間がなくなります。\n\n- 古いバージョンに簡単に戻ることができる\n作業途中に「前のほうが良かった」と旧バージョンに戻りたくなっても、Gitを使っていれば簡単に古いバージョンにさかのぼることができます。\n\n- ファイルや変更履歴をスムーズに共有できる\n作業者同士で直接ファイルをやりとりする必要がないため、バージョンの混乱も反映までの時差も発生しません。\n\n- チームでの共同開発を効率化できる\nGitなら、チームは変更を簡単に追跡できるため、さまざまなバージョンの追跡やマージに時間を費やすことなく、目の前のタスクに集中できます。また、オフラインで作業してローカルに保存するため、中央集中型よりも速いスピードで作業できます。\n\n- ノーコスト／ローコストで導入のお試しができる\nGitは世界で最も広く使用されているバージョン管理システムであり、事実上の業界標準です。したがって多くの人気開発者ツールでサポートされており、無料で利用できるリソースも多数あります。\n\n## gitの用語と使い方の初心者向け解説\n\nGitの使い方と、どのような用語を使用するか、初心者が理解しやすいように表組にまとめてみました。\n\n- 場所の名前\n\n| 場所 | 定義 |\n| :---- | :---- |\n| リポジトリ | ファイルや変更履歴を保存しておくデータベース。リポジトリには2種類ある。 ローカルリポジトリ（ローカル上）：ローカル環境で作業を行う際に使う。 リモートリポジトリ（ネットワーク上）：他のユーザーとファイルや変更履歴を共有する際に使う。 |\n| インデックス | リポジトリ（保存場所）とワークツリー（作業場所）の間の中間領域。ローカルで作業したファイルをリポジトリに保存するには、インデックスにいったん置く必要がある。 |\n| ワークツリー | ユーザーが編集している作業中のディレクトリのこと。 |\n\n- アクションとコマンド\n\n| アクション | 定義 | コマンド |\n| :---- | :---- | :---- |\n| クローン | リモートリポジトリのコミットを、ローカルリポジトリへ丸ごとコピーすること。 | git clone \\[リポジトリパス\\] |\n| コミット | リポジトリへファイルや変更履歴を登録することを指す。 | git commit \\[コミット名\\] |\n| プッシュ | 登録した変更（コミット）をローカルからリモートリポジトリへ反映させることを指す。 | git push |\n| ブランチ | 変更履歴を分岐することを指す。作成された分岐はブランチと呼ばれる。 | git branch |\n| マージ | 複数のブランチを一つにまとめること。 | git merge |\n| プル | リモートリポジトリのコミットをローカルリポジトリへと引っ張ってくることを指す。 |   git pull |\n| フェッチ | リモートリポジトリからファイルの最新情報を取得してくること。プルとは違い、ローカルのファイルは更新されない。 | git fetch \\[リポジトリ\\] |\n\n## Gitの弱点は？\n\nこのように便利でさまざまな利点があるGitですが、弱点もあります。\n\n- Gitの操作方法は非エンジニアにはなじみがない\n「Gitがそんなに便利なら、なぜマネジメントやオペレーション側にあまり浸透していないのだろう」という疑問も生まれるでしょう。しかしGitをそのまま使う場合、基本的にCUIという文字によるコマンドの打ち込みでコンピューターと対話する操作手法が必要です。PCが不調でシステムをセーフモードで起動した経験はないでしょうか（文字列だけの暗い画面が立ち上がります）。あるいはエンジニアが暗い画面にコードを表示して作業している様子を想像してみましょう。普段コマンドやコードに縁がない人にとってはハードルが高い操作方法と言えます。\n\n- Gitの学習には時間が必要\nGitを導入する際、プロジェクトチームは全員がGitを使えるようになる必要があります。用語も独特であり、また、各メンバーがローカルで作業するため、運用ルールを決めておかないと混乱する可能性があります。慣れるまでに学習時間が必要であるため、使用頻度がそこまで高くない場合、学習にかかる時間的コストの費用対効果が疑問視されることもあります。\n\n## Git管理はツールで手軽に\n\nこのようなGitの弱点を一挙に解決するのが、Gitにユーザーフレンドリーなインターフェイスを組み込んだ管理ツールです。管理ツールを使えば、コマンドを打ち込んで操作するのではなく、日常使っているアプリケーションのようにマウスでクリックして操作できるため、Gitの多数のメリットを組織にスムーズに取り入れられます。\n\nGit管理ツールを導入すると次のようなメリットがあります。\n\n- Gitを使うためにコマンドを覚える必要がない  \n- Gitを学習する時間が短縮できる  \n- エンジニア以外でもGitを使えるようになる\n\nGit管理ツールにはさまざまな種類がありますが、開発スピードを確保しつつセキュリティも高めたい組織が選んでいるのは、GitLabです。\n\nGitとGitLab。名前が似ているのは、GitLabが[Gitを使ったDevSecOpsプラットフォームサービス](https://about.gitlab.com/ja-jp/platform/)だからです。\n\n![GitLabのアイコンとロゴ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687243/Blog/Content%20Images/gitlab-logo-150.jpg)\n\nGitLabはバージョン管理システムであるGitを中心に、開発（Dev）セキュリティ（Sec） オペレーション（Ops）のすべてをこなせるプラットフォームであり、アイコンやボタンなどのグラフィックを使用して視覚的に操作できるグラフィカルユーザーインターフェイスを採用しているため、Gitの弱点を克服できます。\n\n当然、先ほど挙げたGit管理ツールのメリットを享受できますが、それだけではありません。計画から本番まで、DevSecOpsのあらゆる機能が1つのアプリケーションにまとまっているため、プロジェクトにかかわる各部署の連携が強化され、チームにまとまりが生まれます。\n\nGitLabの「非エンジニアを含む各部門がGitを使用でき、情報を統一的に集約して管理しやすいツール」という面は、他にはない特徴です。\n\nまとめると、GitLabには次のような特徴があります。\n\n* ツールチェーンを簡素化できる\n\n  重要な[DevSecOpsツール](https://about.gitlab.com/ja-jp/platform/)がすべて1つのプラットフォームに集約されています。\n\n* ソフトウェアデリバリーを高速化できる\n\n  オートメーション、[AIを活用したワークフロー](https://about.gitlab.com/ja-jp/gitlab-duo/)が提供されています。\n\n* セキュリティを統合できる\n\n  セキュリティは[デフォルトでビルトイン](https://about.gitlab.com/ja-jp/solutions/security-compliance/)されており、追加は不要です。\n\n* どこにでもデプロイできる\n\n  複数のクラウドにコンピューティングを分散するマルチクラウドアプローチが行えます。\n\n* Freeプランでノーコストでのお試し導入ができる\n\n  [無料試用版](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/devsecops/&glm_content=default-saas-trial)をクレジットカードの登録なしで使用開始できます。\n\n![AIの助けで時間短縮](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687243/Blog/Content%20Images/homepage-image.png)\n\n開発のスピード向上を計りたい＋包括的なセキュリティ対策を重要視したいという組織に、GitLabは最適です。\n\n[GitLab公式サイト](https://about.gitlab.com/ja-jp/)\n\n## まとめ \n\nここまで、組織のマネジメントやオペレーション部門などで働く非エンジニアや初心者向けに、Gitとは何か、おさえておくべき基礎知識、仕組み、用語をご紹介しました。Gitの概要を把握しておくことで、導入を検討する際の一助になれば幸いです。\n\nこれほど利便性が高いGitですが、開発（Dev）セキュリティ（Sec） オペレーション（Ops）プラットフォームであるGitLabの、ほんの一部の機能にすぎません。すべてをこなせるDevSecOpsプラットフォームの力強さに興味がある方は、ぜひ30日間無料トライアルでGitLabを体感してみてください。\n\n> [GitLab Ultimateの無料トライアル](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial)を始めましょう\n\n\u003Cbr>\u003Cbr>\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)\n（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*\n",[9,677],"2024-12-26",{"slug":834,"featured":90,"template":680},"what-is-git","content:ja-jp:blog:what-is-git.yml","What Is Git","ja-jp/blog/what-is-git.yml","ja-jp/blog/what-is-git",{"_path":840,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":841,"content":847,"config":852,"_id":854,"_type":13,"title":855,"_source":15,"_file":856,"_stem":857,"_extension":18},"/ja-jp/blog/what-is-gitflow",{"title":842,"description":843,"ogTitle":842,"ogDescription":843,"noIndex":6,"ogImage":844,"ogUrl":845,"ogSiteName":667,"ogType":668,"canonicalUrls":845,"schema":846},"GitFlowとは？GitLab Flowとの違いと開発フローを解説","GitFlowとGitLab Flowの違いや、GitFlowとは何なのか、GitFlowの仕組みや使うメリット、よくある質問などをご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659838/Blog/Hero%20Images/AdobeStock_662057734.jpg","https://about.gitlab.com/blog/what-is-gitflow","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitFlowとは？GitLab Flowとの違いと開発フローを解説\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Team\"}],\n        \"datePublished\": \"2024-09-27\",\n      }",{"title":842,"description":843,"authors":848,"heroImage":844,"date":849,"body":850,"category":675,"tags":851},[696],"2024-09-27","GitFlow では、開発者は「\u003Ccode>main\u003C/code>」（運用）ブランチの他に「\u003Ccode>develop\u003C/code>」（開発）ブランチを分けて作成しそれをデフォルトにしますが、[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)は\u003Ccode>main\u003C/code>ブランチでもすぐ作業を始められます。[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)にはプリプロダクションのブランチが組み込まれており、\u003Ccode>main\u003C/code> ブランチに変更点をマージして本番環境に移行する前にバグ修正を行うことができます。たとえば、\u003Ccode>main\u003C/code>からテストへ、テストから承認へ、または、承認からプロダクションへ、といったように、チームは必要に応じてプリプロダクションブランチを好きなだけ追加できます。\n\nここでは、GitFlowと[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)の違いや、GitFlowとは何なのか、GitFlowの仕組みやこれを使うメリット、よくある質問などをわかりやすく説明します。\n\n## 目次\n- GitFlowとは\n- GitFlowの仕組み\n- GitFlowと GitLab Flow はどう違うのか\n- GitFlowのワークフロー\n- GitLab Flowのワークフロー\n- GitFlowを使うメリットと各種機能\n- GitFlowの例\n- GitLab FlowとGitFlowのFAQ（よくある質問）\n\n## \u003CH2> GitFlowとは \u003C/H2>\n\nGitFlowとは、Git（分散型バージョン管理システム）ブランチを管理するGitワークフローのことで、Gitでのリポジトリの分岐（ブランチ）モデルです。複雑なソフトウェアリリース管理を簡素化するためにつくられ、Vincent Driessen氏によって2010年に利用が始まりました。規模の大きなチームの間で、特に人気があります。\n\n## \u003CH2> GitFlowの仕組み \u003C/H2>\n\nトランクベース開発と比較すると、GitFlowには永続的なブランチと大規模なコミットがあります。GitFlowは、リリースの周期が決まっているプロジェクトと、継続的なデリバリーを行なう [DevOps](https://about.gitlab.com/ja-jp/solutions/devops-platform/)ベストプラクティスに利用できます。\nGitFlowではワークフローが構造化されているため、たとえば、developブランチとmainブランチにfeatureブランチを追加し、次いでreleaseブランチを追加するなどして各ブランチを定義します。こうすると、チームがその構造を理解しやすく、変更点などを開発パイプラインのどこに加えるべきなのか、一目瞭然となります。\n## \u003CH2> GitFlowとGitLab Flowはどう違うのか \u003C/H2>\n\nGitFlowとは、Gitのブランチングモデルで、フィーチャーブランチの他に、複数の主要ブランチを使用します。[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)は、GitFlowが内包していた問題を解決し、チームメンバーがより効率よく作業できるようにしています。詳しいワークフローの違いを見てみましょう。\n\n### \u003CH3> GitFlowのワークフロー \u003C/H3>\n\nGitFlowのワークフローには、次の5つのブランチがあります。\n\n1. main\u003Cbr>\n2. develop\u003Cbr>\n3. feature\u003Cbr>\n4. release\u003Cbr>\n5. hotfix\u003Cbr>\n\nGitFlowをコード開発で使用するときは、mainブランチとそれ以外のサポートブランチを使用します。メインブランチには、製品としてリリースするためのmainブランチと、開発中のソースコードを管理するdevelopブランチの2つのブランチがあります。developブランチでコードの安定化を図り、リリースの準備ができたらmainブランチにマージします。サポートブランチには、feature、release、hotfixなどのブランチを作成し、それぞれの作業を進めます。\n\n### \u003CH3> GitLab Flow のワークフロー \u003C/H3>\n\n[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)は、リリース、タグ付け、マージなどで発生するオーバーヘッドを防ぎ、開発を効率化します。\n\n[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)はGitFlowを簡略化したもので、フィーチャー中心の開発と、イシュー追跡機能を組み合わせたものです。[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)を使うと、シンプルで、わかりやすく、かつ効率的な作業が可能になります。[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)には、ソフトウェア開発チームがスムーズに機能をリリースするための、ベストプラクティスが含まれています。\n\n[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)はGitLabの開発で使用するワークフローで、メインのブランチである \u003Ccode>main\u003C/code>、リリース前のテスト用ブランチである \u003Ccode>pre-production\u003C/code>、リリース済みのコードを管理する\u003Ccode>production\u003C/code>、機能の開発やバグ修正用\u003Ccode>feature\u003C/code>/\u003Ccode>hotfix\u003C/code>などのブランチがあります。チームは、好きな数だけプリプロダクションブランチを追加できます。たとえば、\u003Ccode>main\u003C/code> からテストに、テストから承認に、承認からプロダクションに、といったように流れをつくります。\n\nチームはフィーチャーブランチを作成する一方で、プロダクションブランチを管理します。メインブランチのデプロイ準備が整ったら、それをプロダクションブランチにマージし、リリースします。[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)はリリースブランチでも使用できます。パブリックのAPIが必要なチームは異なるバージョンを管理しなければなりませんが、[GitLab Flow](https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/)を使うと個別に管理可能なv1ブランチとv2ブランチを作成できるため、コードレビューでバグを検出した場合にv1に戻れ、とても便利です。\n\n\u003CH2> GitFlowを使うメリットと各種機能 \u003C/H2>\n\u003CH3>メリット1: バグ修正を迅速に処理\u003C/H3>\n\nGitFlowを使うメリットのひとつは、本番環境でのバグ修正が素早く処理できる点です。GitFlowは規模の大きなチームで複雑なソフトウェア開発を行なう際に、Git（分散型バージョン管理システム）のワークフローとして利用します。\n\n\u003CH3>メリット2: テストを保証\u003C/H3>\n\nリリースブランチからソフトウェアをリリースするときは、ユーザーがステージング環境でテストできる期間を設定できます。これはコード開発とは独立して行なえます。また、コミットは下流側に流れるので、すべての環境でテスト済みであることが保証できます。\n\n\u003CH3>メリット3: ソフトウェア開発プロセスの効率化\u003C/H3>\nGitFlowを使うと、Gitが最大限に活用できます。それにより、ソフトウェア開発プロセスの効率化が図れます。\n\n\u003CH3>メリット4: より効率的なコラボレーション、コンフリクトの解決、継続的なデリバリー\u003C/H3>\n\nGitFlow を導入することで、コラボレーションが効率化できます。マージのコンフリクトも素早く解決でき、継続的なデリバリーが実現します。\n\n\u003CH2> GitFlowの例 \u003C/H2>\n以下に、GitFlowの構成例を図で示します。フロー全体と、それぞれの分岐や構造などがおわかりになるかと思います。\n\n![AdobeStock 569852816](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673714/Blog/Content%20Images/AdobeStock_569852816.jpg)\n\u003CH2> GitLab FlowとGitFlowのFAQ（よくある質問）\u003C/H2>\n\n### Q: Git Feature Flowとは何ですか。\nA: Gitを使った開発フローについて、提唱されているフローのひとつです。シンプルな開発なら Git Feature Flowで対応可能です。\n\n### Q: GitLab Flowは、使用するだけの価値がありますか。\nA: はい。GitLab Flowはリリース、タグ付け、マージなどのオーバーヘッドを低減します。こういった問題は、他の Gitワークフローでよく出くわす問題です。詳しくは、[こちら](https://about.gitlab.com/topics/version-control/what-are-gitlab-flow-best-practices/)（英語版）をご覧ください。\n\n### Q: GitLab FlowとGit Flow、どちらを選んだらいいですか。\n\nA: Git Flowでは、その構造上、開発ステージが明確に分かれている大型のプロジェクトに向いていますが、GitLab Flowは[アジャイル](https://about.gitlab.com/ja-jp/blog/what-is-agile-development/)なので、継続的なデリバリーや迅速なリリースを優先するようなプロジェクトに向いています。\n\n## \u003CH2>参考文献\u003C/H2>\n[GitLab のDevSecOpsについて](https://about.gitlab.com/ja-jp/)\n\n*監修：大井 雄介 [@yoi_gl](https://gitlab.com/yoi_gl)\n（GitLab合同会社 ソリューションアーキテクト本部 本部長）*\n\n## \u003CH2>今すぐGitLabを始めてみる\u003C/H2>\nGitやバージョンコントロールについて詳しく知りたい方は、[こちら](https://about.gitlab.com/resources/)をご覧ください。\n統合されたDevSecOpsプラットフォームを使用してチームの可能性の広がりを体感しませんか？\n\n[無料トライアルを開始](https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com)\n",[9,677],{"slug":853,"featured":6,"template":680},"what-is-gitflow","content:ja-jp:blog:what-is-gitflow.yml","What Is Gitflow","ja-jp/blog/what-is-gitflow.yml","ja-jp/blog/what-is-gitflow",{"_path":859,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":860,"content":866,"config":872,"_id":874,"_type":13,"title":875,"_source":15,"_file":876,"_stem":877,"_extension":18},"/ja-jp/blog/what-is-the-difference-between-git-fetch-and-git-pull",{"title":861,"description":862,"ogTitle":861,"ogDescription":862,"noIndex":6,"ogImage":863,"ogUrl":864,"ogSiteName":667,"ogType":668,"canonicalUrls":864,"schema":865},"git fetchとgit pullのコマンド上での違いとは？","git pullは、git fetchと同時にgit mergeを実施するgitコマンドのことです。この記事では、それぞれの特徴と適した用途をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665856/Blog/Hero%20Images/AdobeStock_869074524.jpg","https://about.gitlab.com/blog/what-is-the-difference-between-git-fetch-and-git-pull","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"git fetchとgit pullのコマンド上での違いとは？\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2024-07-25\",\n      }",{"title":861,"description":862,"authors":867,"heroImage":863,"date":869,"body":870,"category":675,"tags":871},[868],"GitLab Japan Team","2024-07-25","# \u003CH1> git fetchとgit pullの違いとは？\u003C/H1> \ngitコマンドは、[分散型バージョン管理システム](https://about.gitlab.com/ja-jp/solutions/source-code-management/)として非常に人気があり、リモートリポジトリとの同期が必須です。開発に携わるエンジニアは、プロジェクトのニーズに応じて、適切なコマンドを選択する必要があります。この記事では、git fetchとgit pullの基本とその相違点を説明し、それぞれの使用目的について詳しく解説していきます。\u003Cbr>\n\n## 目次\n\n1. git fetchとgit pullの基本\n2. git fetchとは\n3. git pullとは\n4. git fetchを使うべき場面とは\n5. git pullを使うべき場面とは\n6. git fetchとgit pullに関する FAQ\n\n## \u003CH2> git fetchとgit pullの基本 \u003C/H2>  \ngit fetch（git フェッチ）とgit pull（git プル）は、両方ともgitのコマンドであり、リモートリポジトリから更新情報を取得するために使用されます。\nでは、なにが異なるのでしょうか。git fetchは、リモートリポジトリの変更状況をローカルリポジトリにダウンロードしますが、現在の作業ディレクトリには変更を加えません。ローカルのブランチにマージされないため、作業中に中断を引き起こすことなく、リモートリポジトリの変更を確認できることが利点です。\n一方git pullとは、リモートリポジトリから最新の変更を取得するところまではgit fetchと同様ですが、さらに現在のブランチに自動的にmerge（マージ）するコマンドです。リモートリポジトリの変更が直接ローカルの作業ディレクトリにも反映される点が、git fetchとの違いです。\n\n## \u003CH2> git fetchとは \u003C/H2>  \ngit fetchコマンドは、リモートリポジトリから最新のコミット履歴を取得しますが、ローカルの作業ディレクトリには反映されません。リモートの変更を取得しても、ローカルのブランチには反映されません。\n主に、リモートリポジトリの最新の状態を取得し、それがローカルリポジトリに反映される前に、変更内容を確認したい場合に使用されます。\n取得した変更内容をローカルブランチに適用するには[git mergeやgit rebase](https://docs.gitlab.com/ee/user/project/merge_requests/methods/)を手動で実行する必要があります。\n\n## \u003CH2> git pullとは \u003C/H2>\ngit pullコマンドは、`git fetch`と`git merge`（または`git rebase`）の組み合わせを一つのコマンドで実行します。これにより、リモートリポジトリの変更を取得してローカルの現在のブランチに自動的に統合します。git fetchはリモートリポジトリの変更を取得してローカルに反映させないのに対し、git pullを実行すると、リモートからの変更がローカルブランチに自動的に統合します。\n\n`git pull`は、リモートの変更をローカルのブランチに迅速に反映させるのに適していますが、コンフリクトが発生する可能性があるため、特に複数人での作業時には注意が必要です。\n\n## \u003CH2> git fetchを使うべき場面とは \u003C/H2> \ngit fetchは、リモートリポジトリから最新の情報を取得するコマンドです。取得した情報はローカルのブランチには直接反映されることはありません。git pullを使うと、誤ったリモートブランチや問題のあるリモートブランチもすべてローカルブランチに反映されてしまいます。\n\nリモートおよびローカルの両方で同時に変更が加えられている場合や、開発初心者の方がいるチームでは、git fetchを使ってリモートブランチの内容を取得してからmergeまたはrebaseするのが安全です。\n\n## \u003CH2> git pullを使うべき場面とは \u003C/H2> \ngit pullはgit fetchと比較して、より多くのプロセスを実施してくれるコマンドです。git pullで、git fetchに加えて、git merge（マージ）またはgit Rebase（リベース）を実施することができます。このため、リモートリポジトリの変更をローカルのブランチに素早く反映したいときにおすすめです。\n\n## \u003CH2> git fetchとgit pullに関する FAQ\u003C/H2> \n### \u003CH3> git pullと git fetchはなにが違うの？\u003C/H3> \ngit pullは、git fetch + git mergeもしくはgit fetch + git rebaseを実施するコマンドです。git fetchがローカルリポジトリに影響を与えないのに対し、git pullはリモートリポジトリの変更をローカルリポジトリにも自動で同期します。\n\n### \u003CH3> git pullを使用する際の注意点は？\u003C/H3> \ngit pullを実行する際には、リモートとローカルの変更が競合することがあります。特にマージコンフリクトが発生しやすいので、コンフリクトが発生した場合には手動で解決する必要があります。また、git pull --rebaseを使うことで、リベースを行いながら最新の変更を取り込むこともできます。\n\n### \u003CH3> git fetchは何のために使うの？\u003C/H3> \ngit fetchは、リモートリポジトリの最新の状態を確認・取得するのに役立ちます。しかし、取得した変更はローカルのブランチに自動的に反映されず、ローカルとリモートのリポジトリを同期するために使用されます。\u003Cbr>\n\n*監修：小松原 つかさ  [@tkomatsubara](https://gitlab.com/tkomatsubara)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\n",[9,677],{"slug":873,"featured":90,"template":680},"what-is-the-difference-between-git-fetch-and-git-pull","content:ja-jp:blog:what-is-the-difference-between-git-fetch-and-git-pull.yml","What Is The Difference Between Git Fetch And Git Pull","ja-jp/blog/what-is-the-difference-between-git-fetch-and-git-pull.yml","ja-jp/blog/what-is-the-difference-between-git-fetch-and-git-pull",{"_path":879,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":880,"content":886,"config":892,"_id":894,"_type":13,"title":895,"_source":15,"_file":896,"_stem":897,"_extension":18},"/ja-jp/blog/what-is-yaml",{"ogTitle":881,"schema":882,"ogImage":883,"ogDescription":884,"ogSiteName":667,"noIndex":6,"ogType":668,"ogUrl":885,"title":881,"canonicalUrls":885,"description":884},"拡張子YAMLファイルとは？基本から使い方まで徹底解説","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"拡張子YAMLファイルとは？基本から使い方まで徹底解説\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"},{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-04-09\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662547/Blog/Hero%20Images/what_is_yaml.jpg","YAMLは構成ファイル紹介などに使用されるフォーマットです。この記事では、YAMLの基本からKubernetesなどでの具体的な使い方まで解説します。","https://about.gitlab.com/blog/what-is-yaml",{"title":881,"description":884,"authors":887,"heroImage":883,"date":888,"body":889,"category":762,"tags":890},[868,781],"2025-04-09","## 目次\n\n* YAMLとは？\n* YAMLを何に使う？\n* YAMLとYMLの違いとは？\n* YAMLとJSONの違い\n* YAMLとCUEの比較\n* YAMLのデータ構造と書き方（基本編） \n* GitLabでYAMLを使う\n* 実際にYAMLファイルを編集してみましょう\n* YAMLに関するFAQ\n\nYAMLは、[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/)ファイルやAnsibleプレイブックに使用されるデータシリアライゼーション・フォーマットです。この記事では、YAMLファイルの基本的な書き方や具体的な利用シーンについて詳しく解説します。\n\n## YAMLとは？\n\nYAMLは、人間がデータを簡潔かつ理解しやすく表現するよう設計されており、設定ファイルやデータ転送で頻繁に使用されるプログラミング言語です。階層的情報の整理に適し、Jsonやxmlの代替と利用されることがあります。\n\n## YAMLを何に使う？\n\nYAMLは可読性の高いこともあり、設定ファイルやプレイブックの記載に使われます。いくつか例を下記に記載しますので、参考にしてください。\n\n* 設定ファイルの記述  \n* ログファイル  \n* プロセス間でのメッセージのやり取り  \n* アプリケーション間でのデータ共有  \n* 構造化データの記述\n\n## YAMLとYMLの違いとは？\n\nどちらも同じ形式のファイルを指し、拡張子が「.yml」か「.yaml」という表記の違いだけです。ヤムルファイルであることを示す正式な拡張子は.yamlですが、一般的に拡張子（.txt, .zip, .exe, .png等）は3文字で記載されるので、この3文字ルールに合わせたのが.ymlとなっています。短く簡潔に書きたい開発者には「.yml」が選ばれることが多いです。\n\n## YAMLとJSON形式の違い\n\nJSON形式では中括弧を使って要件を定義していくのに対して、YAMLは、インデントで構造が明示されるので、可読性が高くなっています。下記サンプルを見比べてください。\\\nYAMLは、プログラマーにとっての使いやすさを重視していることがわかると思います。\n\nYAML：\\\n![yamlのキーとバリューの記載例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687456/Blog/Content%20Images/yaml-coding-sample-01.png)\n\nJSON:\n\n![JSON形式のキーとバリューの記載例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687456/Blog/Content%20Images/json-format-coding-sample-01.png)\n\n## YAMLとCUEの比較\n\nYAMLは、可読性が高くシンプルな構造を持つのに比べ、CUEは、スキーマとデータを統合するため、複雑な設定もひとつのファイルで管理できます。また、YAML単体では実現できなかったスキーマバリデーション機能を持つので、データの整合性を担保しやすいです。\n\nまた、柔軟性も大きな特徴です。CUEは、あらゆる種類のデータを定義、生成、検証するために使用される[オープンソース](https://about.gitlab.com/ja-jp/blog/what-is-open-source/)の言語（具体的にはJSONのスーパーセット）なので、Go、JSON、OpenAPI、Protocol Buffers、YAMLなどの他の多くの言語と連携できます。\n\nまた、Go APIによるスクリプト機能を備えているので、CUEによるマニフェストを最終的な[Kubernetes](https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/)リソースのYAMLとして表示したり、特定クラスタにデプロイするリソースを一覧するコマンドを実装する際などに使う機会があります。\n\n## YAMLのデータ構造と書き方（基本編）\n\n### YAMLファイル記述の注意点\n\nインデントとタブが、とても重要であることを覚えておいてください。余分なインデントやタブが使われていると、YAMLオブジェクトの意味が変わってしまうので、これらがとても重要になります。\n\n### YAMLのデータ構造\n\nYAMLは主に、コレクションとスカラーという２つのデータで成り立っています。コレクションは、シーケンスとマッピングから成り立ちます。シーケンスは配列、マッピングは名前と値のペア（Key : Valueで表現する配列）。そしてスカラーは、型を判別させるためのもので、文字列、数値などを表します。\n\n* コレクション  \n\n  * シーケンス  \n  * マッピング  \n* スカラー\n\n### YAMLの書き方\n\n![image2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687456/Blog/Content%20Images/image2.png)\n\n* 複数行のコレクション：複数の行のフォーマットを維持する必要がある場合には | (バーティカルバー) シンボルを使用します。  \n* 複数行のフォーマット：長い文字列の値があり、フォーマットを維持したまま複数行に渡って記述する必要がある場合には、 > を使用します。  \n* リスト：リストは - （ハイフン）を使って表現します。  \n* ネスト：ネストされたデータ構造はインデントを使って表現されます。\n\n### Kubernetes（k8s)のYAMLファイルの書き方\n\nKubernetesでは、リソースの定義にYAMLファイルが使用されます。今回はYAMLマニフェストの書き方を紹介します。  \n\nYAMLマニフェスト：\\\n![YAMLでKubernetesのマニフェストの書き方例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687456/Blog/Content%20Images/YAML-manufest-sample-Kubernetes.png)\n\n### AnsibleのYAMLファイルの書き方\n\nAnsibleでは、処理内容を記載するプレイブックをYAMLで記載します。以下に、簡単なAnsibleプレイブックの例を示します。\n\n![image3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687457/Blog/Content%20Images/image3.png)\n\n## GitLabでYAMLを使う\n\nGitLab CI/CD パイプラインは、プロジェクト毎に[.gitlab-ci.yml](https://docs.gitlab.com/ee/ci/examples/index.html)というYAMLファイルを使って[パイプラインの構造と実行順序を定義](https://gitlab.com/stylez-co-jp/gitlab-ce/-/blob/dev-v12.0.3-ja.1/doc-ja/ci/yaml/README.md)します。このファイルで設定された内容を、GitLab Runnerの中で処理します。CI/CD YAML構文については[こちらの英文まとめページ](https://docs.gitlab.com/ee/ci/yaml/)をご参照ください。\n\n## 実際にYAMLファイルを編集してみましょう\n\nYAMLは、そのシンプルさと可読性の高さから、設定ファイル、CI/CDパイプライン、Kubernetesをはじめとするコンテナオーケストレーションやドキュメント、構成管理など、多岐にわたり利用されています。その可読性の高さで、開発者や運用エンジニアが構成やデータを容易に管理し、効率的に作業を進めることができます。YAMLを理解することで、様々なシステムやツールの設定がより簡単かつ直感的に行えるようになるでしょう。\n\n## YAMLに関するFAQ\n\n### YAMLは何に使われますか\n\nYAMLは、そのシンプルさと可読性の高さから、設定ファイル、CI/CDパイプライン、Kubernetesをはじめとするコンテナオーケストレーションやドキュメントと構成管理など、多岐にわたり利用されています。\n\n### YAMLとJSONの違いは？\n\nJSONファイルは中括弧を使って要件を定義していくのに対して、YAMLは、インデントで構造が明示されるので、可読性が高くなっています。ただし、YAMLではインデントやスペースがとても重要になる点に注意が必要です。\n\n### YAMLはなぜ人気なのですか？\n\nYAMLは開発者の間で人気のあるデータシリアライズ言語です。なぜなら、その読みやすさ、汎用性、Pythonと似たインデントシステムを使うからです。YAMLは複数のデータ型をサポートしており、多くのプログラミング言語で利用可能なパーサーライブラリが提供されているため、さまざまなデータシリアライゼーションタスクを扱うことができ、幅広い場面で活用されています。\n\n\u003Cbr>\u003Cbr>\n\n*監修：佐々木 直晴 [@naosasaki](https://gitlab.com/naosasaki) （GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[810,723,811,108,532,891,701,702,677,9],"cloud native",{"slug":893,"featured":90,"template":680},"what-is-yaml","content:ja-jp:blog:what-is-yaml.yml","What Is Yaml","ja-jp/blog/what-is-yaml.yml","ja-jp/blog/what-is-yaml",{"_path":899,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":900,"content":903,"config":910,"_id":912,"_type":13,"title":913,"_source":15,"_file":914,"_stem":915,"_extension":18},"/ja-jp/blog/what-s-new-in-git-2-50-0",{"noIndex":6,"title":901,"description":902},"Git 2.50.0の新機能","git-diff-pairs(1)コマンドや、参照の一括更新を行うためのgit-rev-list(1)オプションなど、GitLabのGitチームとGitコミュニティによるコントリビュートをご紹介します。",{"title":901,"description":902,"authors":904,"heroImage":906,"body":907,"date":908,"category":675,"tags":909},[905],"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\n## 新しいgit-diff-pairs(1)コマンド\n\n\n差分は、すべてのコードレビューの中心となるもので、2つのリビジョン間で行われた\n\nすべての変更を表示します。GitLabでは、さまざまな場所で差分が表示されますが、最も\n\n一般的なのはマージリクエストの[「変更」タブ](https://docs.gitlab.com/user/project/merge_requests/changes/)です。\n\nその裏側では、差分の生成に[`git-diff(1)`](https://git-scm.com/docs/git-diff)が\n\n使われています。たとえば、以下のように使います。\n\n\n```shell\n\n$ git diff HEAD~1 HEAD\n\n```\n\n\nこのコマンドは、変更されたすべてのファイルの完全な差分を返します。ただし、リビジョン間で変更されたファイル数が非常に多い場合、スケーラビリティの課題が生じる可能性があります。GitLabのバックエンドでは、コマンドが自己設定されたタイムアウトに達してしまうこともあります。変更数が多い場合、\n\n差分の計算をより小さく扱いやすい単位に分割できる方法があれば、より効果的です。\n\n\nこの課題を解決する1つの方法は、\n\n[`git-diff-tree(1)`](https://git-scm.com/docs/git-diff-tree)を使って、\n\n変更されたすべてのファイルに関する情報を取得することです。\n\n\n```shell\n\n$ git diff-tree -r -M --abbrev HEAD~ HEAD\n\n:100644 100644 c9adfed339 99acf81487 M      Documentation/RelNotes/2.50.0.adoc\n\n:100755 100755 1047b8d11d 208e91a17f M      GIT-VERSION-GEN\n\n```\n\n\nGitはこの出力を[「raw」フォーマット](https://git-scm.com/docs/git-diff-tree#_raw_output_format)と呼んでいます。\n\n簡単に言えば、出力の各行にはファイルのペアと、\n\nそれらの間で何が変更されたかを示すメタデータが表示されます。大規模な変更に対して\n\n「パッチ」形式の出力を生成する方法と比べて、\n\nこの処理は比較的高速な上、すべての変更の概要を把握できます。また、このコマンドでは、`-M`フラグを付けることでリネーム検出を有効にし、変更がファイルのリネームによるものかどうかを判別することもできます。\n\n\nこの情報を使えば、`git-diff(1)`を使って各ファイルペアの差分を\n\n個別にコンピューティングすることができます。たとえば、以下のようにblob IDを\n\n直接指定することも可能です。\n\n\n```shell\n\n$ git diff 1047b8d11de767d290170979a9a20de1f5692e26 208e91a17f04558ca66bc19d73457ca64d5385f\n\n```\n\n\nこの処理は、各ファイルペアごとに繰り返すことができますが、\n\n個別のファイル差分ごとにGitプロセスを立ち上げるのは、あまり効率的ではありません。\n\nさらに、blob IDを使った場合、変更ステータスやファイルモードといった、\n\n親ツリーオブジェクトに格納されているコンテキスト情報が差分から失われてしまいます。\n\n本当に必要なのは、「raw」なファイルペア情報を元に、\n\n対応するパッチ出力を生成する仕組みです。\n\n\nバージョン2.50から、Gitに新しい組み込みコマンド\n\n[`git-diff-pairs(1)`](https://git-scm.com/docs/git-diff-pairs)が追加されました。このコマンドは、\n\n標準入力（stdin）から「raw」形式のファイルペア情報を受け取り、どのパッチを出力すべきかを正確に判断します。以下の例は、\n\nこのコマンドの使用方法を示しています。\n\n\n```shell\n\n$ git diff-tree -r -z -M HEAD~ HEAD | git diff-pairs -z\n\n```\n\n\nこのように使用した場合、出力結果は`git-diff(1)`を使った場合と同じになります。\n\nパッチ出力を生成する専用コマンドを分けることで、\n\n`git-diff-tree(1)`から得られた「raw」出力を、より小さなファイルペアのバッチに分割し、それぞれを別々の\n\n`git-diff-pairs(1)`プロセスにフィードすることができます。これにより、差分を一度にすべてコンピューティングする必要がなくなるため、\n\n先に挙げたスケーラビリティの課題が解決されます。今後のGitLabリリースでは、\n\nこの仕組みの応用により、\n\n特に変更量が多い場合における差分生成のパフォーマンス向上が\n\n期待されます。この変更についての詳細は、該当する\n\n[メーリングリストのスレッド](https://lore.kernel.org/git/20250228213346.1335224-1-jltobler@gmail.com/)をご覧ください。\n\n\n_このプロジェクトは[Justin Tobler](https://gitlab.com/justintobler)が主導しました。_\n\n\n## 参照更新の一括処理\n\n\nGitには、参照を更新するための[`git-update-ref(1)`](https://git-scm.com/docs/git-update-ref)\n\nコマンドが用意されています。このコマンドを`--stdin`フラグとともに使用すると、\n\n複数の参照を1つのトランザクションとしてまとめて更新できます。\n\nこれを行うには、各参照更新の指示を標準入力（stdin）で指定します。\n\nこの方法で参照を一括更新すると、アトミックな動作も実現できます。つまり、1つでも参照の更新に失敗した場合、\n\nトランザクション全体が中断され、\n\nどの参照も更新されません。以下は、この動作を示す例です。\n\n\n```shell\n\n# 3つの空のコミットと「foo」という名前のブランチを持つリポジトリを作成する\n\n$ git init\n\n$ git commit --allow-empty -m 1\n\n$ git commit --allow-empty -m 2\n\n$ git commit --allow-empty -m 3\n\n$ git branch foo\n\n\n# コミットIDを出力する\n\n$ git rev-list HEAD\n\ncf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n5a74cd330f04b96ce0666af89682d4d7580c354c\n\n5a6b339a8ebffde8c0590553045403dbda831518\n\n\n# トランザクションで新しい参照を作成し、既存の参照を更新しようとします。\n\n# 指定された古いオブジェクトIDが一致しないため、更新は失敗することが予想されます。\n\n$ git update-ref --stdin \u003C\u003CEOF\n\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n> EOF\n\nfatal: cannot lock ref 'refs/heads/foo': is at cf469bdf5436ea1ded57670b5f5a0797f72f1afc but expected 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n\n# 「bar」リファレンスは作成されませんでした。\n\n$ git switch bar\n\nfatal: invalid reference: bar\n\n```\n\n\n多くの参照を個別に更新する場合と比べて、一括で更新するほうがはるかに効率的です。\n\nこの方法は基本的にうまく機能しますが、\n\n一括更新による効率面のメリットを優先するために、\n\nリクエストされた参照更新の一部が失敗することを許容したい場合も\n\nあります。\n\n\n今回のリリースで、`git-update-ref(1)`に新しく`--batch-updates`オプションが追加されました。\n\nこのオプションを使用すると、1つ以上の参照更新が失敗しても、処理を続行できるようになります。\n\nこのモードでは、個々の失敗が次の形式で出力されます。\n\n\n```text\n\nrejected SP (\u003Cold-oid> | \u003Cold-target>) SP (\u003Cnew-oid> | \u003Cnew-target>) SP \u003Crejection-reason> LF\n\n```\n\n\nこれにより、成功した参照の更新はそのまま進行しつつ、どの更新が拒否されたのか、\n\nまたその理由についての情報も得ることができます。前の例と同じリポジトリを\n\n使った例は以下のとおりです。\n\n\n```shell\n\n# トランザクションで新しい参照を作成し、既存の参照を更新しようとします。\n\n$ git update-ref --stdin --batch-updates \u003C\u003CEOF\n\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n> EOF\n\nrejected refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c incorrect old value provided\n\n\n# 「foo」への更新が拒否されたにもかかわらず、「bar」参照が作成されました。\n\n$ git switch bar\n\nSwitched to branch 'bar'\n\n```\n\n\n今回は`--batch-updates`オプションを使用したことで、\n\n更新処理が失敗しても参照の作成は成功しました。この一連のパッチは、\n\n`git-fetch(1)`や`git-receive-pack(1)`における今後の一括参照更新時の\n\nパフォーマンス改善の基盤となります。詳細については、該当する\n\n[メーリングリストのスレッド](https://lore.kernel.org/git/20250408085120.614893-1-karthik.188@gmail.com/)をご覧ください。\n\n\n_このプロジェクトは、[Karthik Nayak](https://gitlab.com/knayakgl)が主導しました。_\n\n\n## git-cat-file(1)の新しいフィルタオプション\n\n\n[`git-cat-file(1)`](https://git-scm.com/docs/git-cat-file)を使うと、\n\nリポジトリ内に含まれるすべてのオブジェクトの情報を\n\n`--batch–all-objects`オプションで出力できます。たとえば、以下のように実行します。\n\n\n```shell\n\n# シンプルなリポジトリを設定します。\n\n$ git init\n\n$ echo foo >foo\n\n$ git add foo\n\n$ git commit -m init\n\n\n# 到達不能なオブジェクトを作成します。\n\n$ git commit --amend --no-edit\n\n\n# git-cat-file(1)を使用して、到達不能なオブジェクトを含むすべてのオブジェクトに関する情報を出力します。\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)'\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ntree 205f6b799e7d5c2524468ca006a0131aa57ecce7\n\nblob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\n状況によっては、リポジトリ内のすべてのオブジェクトを検索し、\n\n特定の属性に基づいて一部のオブジェクトだけを出力したい場合があります。\n\nたとえば、コミットオブジェクトだけを表示したいときは、\n\n`grep(1)`を使って以下のように実行できます。\n\n\n```shell\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' | grep ^commit\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\nこの方法でも目的は達成できますが、出力のフィルタリングには欠点があります。\n\nそれは、`git-cat-file(1)`が\n\nユーザーが関心を持っていないオブジェクトも含め、リポジトリ内のすべてのオブジェクトをたどらなければならない点です。これはかなり非効率です。\n\n\n今回のリリースでは、`git-cat-file(1)`に`--filter`オプションが追加され、\n\n指定した条件に一致するオブジェクトだけを表示できるようになりました。これは`git-rev-list(1)`にある同名のオプションと似ていますが、\n\n対応しているフィルターの種類はその一部に限られています。\n\n対応しているフィルターは`blob:none`、`blob:limit=`および\n\n`object:type=`です。先ほどの例と同様に、オブジェクトはGitを使用して直接\n\n種類でフィルタリングできます。\n\n\n```shell\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' --filter='object:type=commit'\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\nGitに処理を任せられるのは便利なだけでなく、オブジェクト数の多い大規模なリポジトリにおいては\n\n効率面のメリットも期待できます。\n\nリポジトリにビットマップインデックスがある場合、\n\nGitが特定の種類のオブジェクトを効率的に検索できるようになり、パックファイル全体をスキャンする必要がなくなるため、\n\n処理速度が大幅に向上します。\n\n[Chromiumリポジトリ](https://github.com/chromium/chromium.git)で行われた\n\nベンチマークでは、こうした最適化による大きな改善が確認されています。\n\n\n```text\n\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\n\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\n\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\n\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\n\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\n\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\n\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指定された種類のオブジェクト数に比例して増減することが示されています。\n\n元のメーリングリストのスレッドは、\n\n[こちら](https://lore.kernel.org/git/20250221-pks-cat-file-object-type-filter-v1-0-0852530888e2@pks.im/)でご覧いただけます。\n\n\n_このプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。_\n\n\n## バンドル生成時のパフォーマンスが向上\n\n\nGitには、指定した参照とそれに関連する到達可能なオブジェクトを含むリポジトリのアーカイブを生成する機能があります。\n\n具体的には、\n\n[`git-bundle(1)`](https://git-scm.com/docs/git-bundle)コマンドを使用します。この操作は、\n\nGitLabがリポジトリのバックアップを作成する際や、\n\n[バンドルURI](https://git-scm.com/docs/bundle-uri)メカニズムの一部としても使用されます。\n\n\n何百万もの参照を含む大規模なリポジトリでは、\n\nこの操作に数時間から数日かかることもあります。たとえば、GitLabのメインリポジトリ\n\n（[gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab)）では、\n\nバックアップに約48時間を要していました。調査の結果、バンドルに重複した参照が含まれないようにチェックする処理において、\n\nパフォーマンスのボトルネックが存在することが判明しました。\n\nこの実装では、すべての参照をイテレーションして比較するために入れ子の`for`loopが使われており、\n\n時間計算量はO(N^2)となっていました。これは、\n\nリポジトリ内の参照数が増えるほど、処理性能が大きく低下する構造です。\n\n\n今回のリリースでは、この問題に対応し、\n\nネストされたloopをマップ型のデータ構造に置き換えることで、処理速度が大幅に向上しました。以下は、\n\n10万件の参照を含むリポジトリでバンドルを作成した際のパフォーマンス改善を\n\n示すベンチマーク結果です。\n\n\n```text\n\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\n\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\n\nSummary bundle (refcount = 100000, revision = HEAD) ran 6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master) ```\n\n\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元のメーリングリストのスレッドは\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\n_このプロジェクトは[Karthik Nayak](https://gitlab.com/knayakgl)が主導しました。_\n\n\n## バンドルURIのアンバンドルの改善\n\n\nGitの[バンドルURI](https://git-scm.com/docs/bundle-uri)メカニズムは、\n\nフェッチするバンドルの場所をクライアントに提供することで、クローンやフェッチの速度を\n\n向上させることを目的としています。クライアントがバンドルをダウンロードすると、\n\n`refs/heads/*`以下の参照が、その関連オブジェクトとともにバンドルから\n\nリポジトリにコピーされます。バンドルには`refs/tags/*`のように\n\n`refs/heads/*`以外の参照も含まれていることがありますが、\n\nこれらはクローン時にバンドルURIを使用する場合、単に無視されていました。\n\n\nGit 2.50ではこの制限が解除され、\n\nダウンロードされたバンドルに含まれる`refs/*`に一致するすべての参照がコピーされるようになりました。\n\nこの機能を実装した[Scott Chacon](https://github.com/schacon)さんは、\n\n[gitlab-org/gitlab-foss](https://gitlab.com/gitlab-org/gitlab-foss)をクローンした際の\n\n挙動の違いを紹介しています。\n\n\n```shell\n\n$ git-v2.49 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.49\n\nCloning into 'gl2.49'...\n\nremote: Enumerating objects: 1092703, done.\n\nremote: Counting objects: 100% (973405/973405), done.\n\nremote: Compressing objects: 100% (385827/385827), done.\n\nremote: Total 959773 (delta 710976), reused 766809 (delta 554276), pack-reused 0 (from 0)\n\nReceiving objects: 100% (959773/959773), 366.94 MiB | 20.87 MiB/s, done.\n\nResolving deltas: 100% (710976/710976), completed with 9081 local objects.\n\nChecking objects: 100% (4194304/4194304), done.\n\nChecking connectivity: 959668, done.\n\nUpdating files: 100% (59972/59972), done.\n\n\n$ git-v2.50 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.50\n\nCloning into 'gl-2.50'...\n\nremote: Enumerating objects: 65538, done.\n\nremote: Counting objects: 100% (56054/56054), done.\n\nremote: Compressing objects: 100% (28950/28950), done.\n\nremote: Total 43877 (delta 27401), reused 25170 (delta 13546), pack-reused 0 (from 0)\n\nReceiving objects: 100% (43877/43877), 40.42 MiB | 22.27 MiB/s, done.\n\nResolving deltas: 100% (27401/27401), completed with 8564 local objects.\n\nUpdating files: 100% (59972/59972), done.\n\n```\n\n\nこれらの結果を比較すると、Git 2.50はバンドル展開後に43,887個（40.42 MiB）のオブジェクトをフェッチしているのに対し、\n\nGit 2.49は合計で959,773個（366.94 MiB）のオブジェクトをフェッチしています。\n\nGit 2.50では、取得されるオブジェクト数が約95%、\n\nデータ量が約90%削減されており、クライアントとサーバーの双方にとってメリットがあります。\n\nサーバー側ではクライアントに送信するデータ量が大幅に減り、\n\nクライアント側でもダウンロードおよび展開するデータが少なくて済みます。Chaconさんの提供した例では、\n\nこれによって処理速度が25%向上しました。\n\n\n詳細については、\n\n該当する[メーリングリストのスレッド](https://lore.kernel.org/git/pull.1897.git.git.1740489585344.gitgitgadget@gmail.com/)をご覧ください。\n\n\n_この一連のパッチは、[Scott Chacon](https://github.com/schacon)さんによって提供されました。_\n\n\n## 詳細はこちら\n\n\n本記事でご紹介したのは、最新リリースにおいてGitLabと広範なGitコミュニティによって行われた\n\nコントリビュートのごく一部にすぎません。Gitプロジェクトの[公式リリースのお知らせ](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/)では、\n\nさらに詳しい情報をご覧になれます。また、\n\n[以前のGitリリースのブログ記事](https://about.gitlab.com/blog/tags/git/)もぜひご覧ください。GitLabチームメンバーによる過去の主なコントリビュートをご確認いただけます。\n","2025-06-16",[9,677,269],{"featured":90,"template":680,"slug":911},"what-s-new-in-git-2-50-0","content:ja-jp:blog:what-s-new-in-git-2-50-0.yml","What S New In Git 2 50 0","ja-jp/blog/what-s-new-in-git-2-50-0.yml","ja-jp/blog/what-s-new-in-git-2-50-0",{"_path":917,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":918,"content":924,"config":930,"_id":932,"_type":13,"title":933,"_source":15,"_file":934,"_stem":935,"_extension":18},"/ja-jp/blog/whats-new-in-git-2-45-0",{"title":919,"description":920,"ogTitle":919,"ogDescription":920,"noIndex":6,"ogImage":921,"ogUrl":922,"ogSiteName":667,"ogType":668,"canonicalUrls":922,"schema":923},"Git 2.45.0の新機能","ここでは、GitLabのGitチームと、より広範なGitコミュニティが最新のGitリリースにコントリビュートしたいくつかのハイライトを紹介します。これには、「reftables」や参照用の優れたツールなどが挙げられます。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659507/Blog/Hero%20Images/AdobeStock_623844718.jpg","https://about.gitlab.com/blog/whats-new-in-git-2-45-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git 2.45.0の新機能\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2024-04-30\",\n      }",{"title":919,"description":920,"authors":925,"heroImage":921,"date":926,"body":927,"category":675,"tags":928,"updatedDate":929},[672],"2024-04-30","Gitプロジェクトは最近、[Gitバージョン2.45.0](https://lore.kernel.org/git/xmqq8r0ww0sj.fsf@gitster.g/)をリリースしました。このリリースのハイライトを見てみましょう。これには、GitLabのGitチームと、より広範なGitコミュニティからのコントリビュートによるものがあります。\n\n\n## Reftables: 新しい参照ストレージバックエンド\n\n\nすべてのGitリポジトリは、次の2つの基本的なデータ構造を追跡する必要があります:\n\n\n- ファイルのデータ、ディレクトリ構造、コミットメッセージ、タグを保存するオブジェクトグラフ。\n\n- 特定のオブジェクトをよりアクセスしやすい名前に関連付けるためのオブジェクトグラフへのポインタである参照。たとえば、ブランチは名前が\n`refs/heads/` プレフィックスで始まる参照です。\n\n\n参照がリポジトリに保存されるディスク上のフォーマットは、Gitの発足以来ほとんど変わっておらず、「files」フォーマットと呼ばれています。参照を作成するたびに、Gitは、パスが参照名と一致するGitリポジトリ内のプレーンなファイルである、いわゆる「ルース参照」を作成します。たとえば、\n\n\n```shell\n\n$ git init .\n\nInitialized empty Git repository in /tmp/repo/.git/\n\n\n# Updating a reference will cause Git to create a \"loose ref\". This loose\nref is\n\n# a simple file which contains the object ID of the commit.\n\n$ git commit --allow-empty --message \"Initial commit\"\n\n[main (root-commit) c70f266] Initial commit\n\n$ cat .git/refs/heads/main\n\nc70f26689975782739ef9666af079535b12b5946\n\n\n# Creating a second reference will end up with a second loose ref.\n\n$ git branch feature\n\n$ cat .git/refs/heads/feature\n\nc70f26689975782739ef9666af079535b12b5946\n\n$ tree .git/refs\n\n.git/refs/\n\n├── heads\n\n│   ├── feature\n\n│   └── main\n\n└── tags\n\n\n3 directories, 2 files\n\n```\n\n\n時々、Gitはそれらの参照を「パックされた」ファイルフォーマットにパックして、参照をより効率的に検索できるようにします。たとえば、\n\n\n```shell\n\n# Packing references will create \"packed\" references, which are a sorted\nlist of\n\n# references. The loose reference does not exist anymore.\n\n$ git pack-refs --all\n\n$ cat .git/refs/heads/main\n\ncat: .git/refs/heads/main: No such file or directory\n\n$ cat .git/packed-refs\n\n# pack-refs with: peeled fully-peeled sorted\n\nc70f26689975782739ef9666af079535b12b5946 refs/heads/feature\n\nc70f26689975782739ef9666af079535b12b5946 refs/heads/main\n\n```\n\n\nこのフォーマットはかなりシンプルですが、次のような制限があります。\n\n\n-\n多くの参照を持つ大規模な単一のリポジトリでは、スケーラビリティの問題が発生し始めました。参照を削除することは、特に非効率的です。なぜなら、削除済みの参照を削除するには、「packed\n-\nrefs」ファイル全体を書き換える必要があるからです。当社の最大のリポジトリでは、参照を削除するごとに数ギガバイトのデータを書き換える可能性があります。\n\n- すべての参照を把握するには複数のファイルを読み取る必要があるため、同時に書き込みを行うことなく参照をアトミックに読み取ることはできません。\n\n- 複数のファイルを作成または更新する必要があるため、アトミックに書き込みを実行することができず、ワンステップで実行できません。\n\n- 完全な「packed - refs」ファイルを書き換える必要があるため、参照のメンテナンスはスケーリングがうまくいきません。\n\n-\nルース参照はファイルシステムパスをその名前として使用するため、ファイルシステム固有の動作の対象となります。例えば、大文字と小文字を区別しないファイルシステムは、単に大文字と小文字が異なるだけの参照を保存することはできません。\n\n\nこれらの問題に対処するために、Git\nv2.45.0は新しい「reftable」バックエンドを導入しました。これは、新しいバイナリフォーマットを使用して参照を保存します。この新しいバックエンドは非常に長い間開発され続けてきました。最初は2017年7月に[Shawn\nPearce](https://sfconservancy.org/blog/2018/jan/30/shawn-pearce/)によって提案され、[JGit](https://www.eclipse.org/jgit/)に実装されました。これは[Gerrit\nプロジェクト](https://www.gerritcodereview.com/)で広く使用されています。2021年、[Han-Wen\nNienhuys](https://hanwen.home.xs4all.nl/)がライブラリをGitにアップストリームし、[reftableフォーマット](https://git-scm.com/docs/reftable)の読み取りと書き込みを可能にしました。\n\n\nGit v2.45.0\nでアップストリームした新しい「reftable」バックエンドは、ついにreftableライブラリとGitを統合し、新しいフォーマットをGitリポジトリのストレージバックエンドとして使用できるようになりました。\n\n\n少なくともGit v2.45.0を使用していれば、`--ref-format=reftable` スイッチを`git-init(1)` または\n`git-clone(1)` のいずれかに渡すことで、「reftable」フォーマットを使用して新しいリポジトリを作成できます。たとえば、\n\n\n```shell\n\n$ git init --ref-format=reftable .\n\nInitialized empty Git repository in /tmp/repo/.git/\n\n$ git rev-parse --show-ref-format\n\nreftable\n\n$ find -type f .git/reftable/\n\n.git/reftable/0x000000000001-0x000000000001-01b5e47d.ref\n\n.git/reftable/tables.list\n\n\n$ git commit --allow-empty --message \"Initial commit\"\n\n$ find -type f .git/reftable/\n\n.git/reftable/0x000000000001-0x000000000001-01b5e47d.ref\n\n.git/reftable/0x000000000002-0x000000000002-87006b81.ref\n\n.git/reftable/tables.list\n\n```\n\n\nご覧のとおり、参照は `.git/refs` ディレクトリではなく `.git/reftable` に保存されています。参照と参照ログは、`.ref`\nで終わるファイルである「テーブル」に保存されますが、`tables.list`\nファイルには現在アクティブなすべてのテーブルのリストが含まれています。この仕組みの技術的な詳細については、別のブログ記事でご説明します。引き続きブログをご覧いただくようお願いいたします。\n\n\n「reftable」バックエンドは、「files」バックエンドに取って代わるものです。したがって、ユーザーの観点からは、すべてが同じように機能する必要があります。\n\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。また、Shawn\nPearceがフォーマットのオリジナルを発案、Han - Wen Nienhuysがreftableライブラリを作成しています。\n\n\n## 参照用ツールの改善\n\n「reftable」フォーマットは、私たちが抱えている多くの問題を解決してくれる一方で、新しい問題も生み出しています。\n最も重要な問題の1つが、格納されているデータへのアクセシビリティです。\n\n\n「files」バックエンドを使用すると、最悪の場合、通常のUnixツールを使用して参照の状態を調べることになります。「packed」参照と「loose」参照の両方には、人間が簡単に理解できるデータが含まれています。これは、バイナリフォーマットである「reftable」フォーマットとは異なります。したがって、Gitは新しい「reftable」フォーマットからデータを抽出するために必要なすべてのツールを提供する必要があります。\n\n\n### すべての参照の一覧表示\n\n最初の問題は、リポジトリからすべての参照を把握するのは基本的に不可能であるということです。\nGitで参照を作成したり変更できるのに、すべての参照を網羅的にリストできないと聞くと、困惑する方もいるかもしれません。\n\n\n確かに、「files」バックエンドはできません。`refs/`\nプレフィックスで始まるすべての「通常の」参照を簡単にリストすることはできますが、Gitはいわゆる[pseudo\nrefs](https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefpseudorefapseudoref)（疑似参照）も使用します。これらのファイルはGitディレクトリのルートに直接存在し、たとえば\n`.git/MERGE_HEAD` などのようなファイルです。問題は、これらの疑似参照が、Gitが格納する、たとえば `.git/config`\nのような他のファイルの隣に存在することです。\n\n\n一部の疑似参照はよく知られているため識別しやすく、理論上はGitが書き込むことができる参照に制限はありません。「foobar」という参照を作成するのを妨げるものはありません。\n\n\nたとえば、\n\n\n```shell\n\n$ git update-ref foobar HEAD\n\n$ cat .git/foobar\n\nf32633d4d7da32ccc3827e90ecdc10570927c77d\n\n```\n\n\n「files」バックエンドにある問題は、ディレクトリをスキャンして参照を列挙するしかないということです。したがって `.git/foobar`\nが実際には参照であることを理解するために、Gitはファイルを開き、ファイルが参照のようにフォーマットされているかどうかを確認する必要があります。\n\n\n一方、「reftable」バックエンドは、それに含まれるすべての参照について簡単に認識します。参照はデータ構造にエンコードされているため、それらの参照をデコードして返すだけです。しかし、「files」バックエンドの制限により、存在するすべての参照について学ぶことができるツールは存在しません。\n\n\nこの問題に対処するために、`git-for-each-ref(1)` に `--include-root-refs`\nという新しいフラグを追加しました。これにより、参照名の階層のルートに存在するすべての参照もリストアップされます。\n\nたとえば、\n\n\n```shell\n\n$ git for-each-ref --include-root-refs\n\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    HEAD\n\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    MERGE_HEAD\n\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    refs/heads/main\n\n```\n\n\n「files」バックエンドの場合、この新しいフラグはベストエフォートで処理され、既知の疑似参照名に一致するすべての参照が含まれます。「reftable」バックエンドの場合、それに関連するすべての参照をすべてリストアップすることができます。\n\n\nこのプロジェクトは、[Karthik Nayak](https://gitlab.com/knayakgl)が主導しました。\n\n\n### すべての参照ログの一覧表示\n\n\nブランチを更新するたびに、Gitはデフォルトでそれらのブランチの更新をいわゆる参照ログで追跡します。この参照ログを使用すると、意図しない変更を行った場合に、そのブランチへの変更をロールバックできるため、非常に役立つツールとなります。\n\n\n「files」バックエンドでは、これらのログは `.git/logs` ディレクトリに保存されます。\n\n\n```shell\n\n$ find -type f .git/logs/\n\n.git/logs/HEAD\n\n.git/logs/refs/heads/main\n\n```\n\n\n実際、このディレクトリ内のファイルを一覧表示することが、そもそもどの参照が実際に参照ログを保持しているかを知る唯一の方法です。これは、参照と一緒にそれらのログを保存する「reftable」バックエンドの問題です。そのため、「reftable」フォーマットを使用すると、リポジトリにどの参照ログが存在するかを知る方法はまったくありません。\n\n\nこれは実際には「reftable」フォーマットの欠陥ではありませんが、Gitが提供するツールにおける不備です。この欠落に対処するために、`git-reflog(1)`\nに新しい `list` サブコマンドを導入しました。これにより、すべての既存の参照ログをリストアップできます。\n\n\n```shell\n\n$ git reflog list\n\nHEAD\n\nrefs/heads/main\n\n```\n\n\nこのプロジェクトは、[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n\n### 参照のより効率的なパッキング\n\n\nGitリポジトリを効率的に保つには、定期的なメンテナンスが必要です。 通常、このメンテナンスは `git maintenance run --auto`\nを実行してGitリポジトリにデータを書き込むさまざまなGitコマンドによってトリガーされます。このコマンドは、Gitが計算リソースを無駄にしないように、実際に最適化が必要なデータ構造のみを最適化します。\n\n\nGitのメンテナンスによって最適化されるデータ構造の1つは、`git pack-refs --all`\nを実行することによって行われる参照データベースです。「files」バックエンドの場合、これは、すべての参照が「packed -\nrefs」ファイルに再パックされ、ルース参照が削除されることを意味します。一方、「reftable」バックエンドの場合、すべてのテーブルが単一のテーブルにマージされます。\n\n\n「files」バックエンドについては、合理的に改善することはできません。「packed -\nrefs」ファイル全体を書き直す必要があることを考えると、すべてのルース参照をパックしたいと考えるのは理にかなっています。\n\n\nしかし、「reftable」バックエンドの場合、「reftable」バックエンドが自己最適化されるため、最適ではありません。Gitは、新しいテーブルを「reftable」バックエンドに追加するたびに、必要に応じて自動コンパクションを実行し、テーブルを一緒にマージします。したがって、参照データベースは常に適切に最適化された状態にある必要があり、そのため、すべてのテーブルを一緒にマージすることは無駄な努力となります。\n\n\nそこでGit v2.45.0では、新しい `git pack-refs --auto`\nモードを導入し、参照バックエンドに必要に応じて最適化を行うようにしました。 「files」バックエンドは、`--auto`\nフラグが設定されていても同じように動作し続けますが、「reftable」バックエンドは、自動コンパクションにすでに使用されているのと同じ経験則を使用します。\n実際には、これはほとんどの場合何も操作を行いません。\n\n\nさらに、`git maintenance run --auto` は、デフォルトでこの新しいモードを使用するために、`-tauto` フラグを\n`git-pack-refs(1)` に渡すように調整されています。\n\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n\n## 補足情報\n\n\nこのブログ記事では、新しい「reftable」バックエンドに重点を置いています。このバックエンドにより、多くの参照を持つ大規模なリポジトリでの拡張性が向上しました。また、このバックエンドをうまく機能させるために関連したツールも導入しました。このGitリリースではさまざまなパフォーマンスの向上、バグ修正、その他の細かい機能がGitコミュニティによって導入されています。Gitプロジェクトの[公式リリース発表](https://lore.kernel.org/git/xmqq8r0ww0sj.fsf@gitster.g/)をご覧いただくと詳細をご確認いただけます。\n\n\n*監修：小松原 つかさ\u003Cbr>\n\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\n\n\n## 過去のGitリリースへのコントリビューション\n\n* [Git\n2.44.0へのGitLabのコントリビューション](https://about.gitlab.com/blog/gitlabs-contributions-to-git-2-44-0/)\n\n* [Git\n2.43.0へのGitLabのコントリビューション](https://about.gitlab.com/blog/the-contributions-we-made-to-the-git-2-43-release/)\n\n* [Git\n2.42.0へのGitLabのコントリビューション](https://about.gitlab.com/blog/contributions-to-git-2-42-release/)\n\n* [Git\n2.41.0へのGitLabのコントリビューション](https://about.gitlab.com/blog/contributions-to-latest-git-release/)\n",[9,269],"2024-05-17",{"slug":931,"featured":6,"template":680},"whats-new-in-git-2-45-0","content:ja-jp:blog:whats-new-in-git-2-45-0.yml","Whats New In Git 2 45 0","ja-jp/blog/whats-new-in-git-2-45-0.yml","ja-jp/blog/whats-new-in-git-2-45-0",{"_path":937,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":938,"content":944,"config":949,"_id":951,"_type":13,"title":952,"_source":15,"_file":953,"_stem":954,"_extension":18},"/ja-jp/blog/whats-new-in-git-2-46-0",{"title":939,"description":940,"ogTitle":939,"ogDescription":940,"noIndex":6,"ogImage":941,"ogUrl":942,"ogSiteName":667,"ogType":668,"canonicalUrls":942,"schema":943},"Git 2.46.0の新機能","ここでは、参照バックエンド移行ツールやトランザクションシンボリック参照の更新など、GitLabのGitチームやより広範なGitコミュニティがリリースにコントリビュートしたハイライトをご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660028/Blog/Hero%20Images/blog-image-template-1800x945__25_.png","https://about.gitlab.com/blog/whats-new-in-git-2-46-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git 2.46.0の新機能\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Justin Tobler\"}],\n        \"datePublished\": \"2024-07-29\",\n      }",{"title":939,"description":940,"authors":945,"heroImage":941,"date":946,"body":947,"category":675,"tags":948},[905],"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\n\n前回の[Git\n2.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\n\nreftableバックエンドのオンディスクフォーマットは、既存のファイルバックエンドとは異なります。したがって、既存のリポジトリでreftableを使用するにはさまざまなフォーマット間の変換が必要となります。これを達成するため、参照バックエンド移行の実行時に利用可能な`migrate`サブコマンドを含む新しいgit-refs(1)コマンドが導入されました。以下は、このコマンドの使用方法の例です。\n\n\n```shell\n\n# reflogが含まれないようにするために、新規リポジトリを「bare」として初期化します。\n\n$ git init --bare .\n\n$ git commit --allow-empty -m \"init\"\n\n# リポジトリに、バックエンドのファイルへの参照を投入します。\n\n$ git branch foo\n\n$ git branch bar\n\n$ tree .git/refs\n\n.git/refs\n\n├── heads\n\n│   ├── bar\n\n│   ├── foo\n\n│   ├── main\n\n└── tags\n\n# reftableフォーマットへの参照移行を実行します。\n\n$ git refs migrate --ref-format=reftable\n\n# reftableバックエンドが使用されていることを確認します。\n\n$ tree .git/reftable\n\n.git/reftable\n\n├── 0x000000000001-0x000000000001-a3451eed.ref\n\n└── tables.list\n\n# リポジトリ設定をチェックして、`refstorage`フォーマットが変更されていることを確認します。\n\n$ cat config\n\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\n移行ツールには現在いくつか留意すべき制限があります。リポジトリ内のreflogは参照バックエンドのコンポーネントであり、フォーマット間の移行が必要となります。残念ながら、現時点ではツールを使用してファイルとreftablesバックエンド間でreflogを変換することはできません。また、worktreeが含まれるリポジトリには基本的に複数のrefストアがありますが、移行ツールはまだこのようなシナリオに対応していません。したがって、リポジトリにreflogまたはworktreeが含まれている場合、現時点では参照移行を行えません。こうした制限は、今後のバージョンでなくなる可能性があります。\n\n\nbare\nGitリポジトリにはreflogが含まれないため、移行は簡単です。標準的なnon-bareリポジトリを移行するには、まずreflogを削除する必要があります。そのため、reflogやworktreeのないリポジトリであれば、すべて移行できます。こうした制限はありますが、このツールを使うことで既存のリポジトリでreftablesバックエンドを活用し始められます。\n\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n\n## トランザクションシンボリック参照の更新\n\n\n[git-update-ref(1)](https://git-scm.com/docs/git-update-ref)コマンドは、Gitリポジトリ内で参照更新を実行します。こうした参照更新は、`git\nupdate-ref\n--stdin`を使用してupdate-ref命令をstdinに渡すことで、トランザクションで一括してアトミックに実行することもできます。こちらは実行方法の例です。\n\n\n```shell\n\n$ git init .\n\n$ git branch -m main\n\n$ git commit --allow-empty -m \"foo\" && git commit --allow-empty -m \"bar\"\n\n# 作成された2つのコミットのオブジェクトIDを取得します。\n\n$ git rev-parse main~ main\n\n567aac2b3d1fbf0bd2433f669eb0b82a0348775e\n\n3b13462a9a42e0a3130b9cbc472ab479d3ef0631\n\n# トランザクションを開始し、update-ref命令を出し、コミットします。\n\n$ git update-ref --stdin \u003C\u003CEOF\n\n> start\n\n> create refs/heads/new-ref 3b13462a9a42e0a3130b9cbc472ab479d3ef0631\n\n> update refs/heads/main 567aac2b3d1fbf0bd2433f669eb0b82a0348775e\n\n> commit\n\n> EOF\n\n$ git for-each-ref\n\n567aac2b3d1fbf0bd2433f669eb0b82a0348775e commit refs/heads/main\n\n3b13462a9a42e0a3130b9cbc472ab479d3ef0631 commit refs/heads/my-ref\n\n```\n\n\nこの例では、トランザクションがコミットされると「bar」コミットを指す新しいブランチが作成され、メインブランチは以前の\n「foo」コミットを指すよう更新されます。トランザクションをコミットすると、指定された参照更新がアトミックに実行されます。個々の参照更新が失敗した場合、トランザクションは中止され、参照更新は実行されません。\n\n\nここで注目すべきは、こうしたトランザクションでシンボリック参照更新をサポートする命令がないことです。ユーザーが、同一のトランザクション内で他の参照とともにシンボリック参照をアトミックに更新したい場合でも、それに対応できるツールはありません。今回のリリースでは、この機能を提供するために`symref-create`、`symref-update`、`symref-delete`、`symref-verify`命令が導入されました。\n\n\n```shell\n\n# 次の操作で更新されるシンボリック参照を作成します。\n\n$ git symbolic-ref refs/heads/symref refs/heads/main\n\n# シンボリック参照自体が更新されるようにするには、--no-derefフラグが必要です。\n\n$ git update-ref --stdin --no-deref \u003C\u003CEOF\n\n> start\n\n> symref-create refs/heads/new-symref refs/heads/main\n\n> symref-update refs/heads/symref refs/heads/new-ref\n\n> commit\n\n> EOF\n\n$ git symbolic-ref refs/heads/symref\n\nrefs/heads/new-ref\n\n$ git symbolic-ref refs/heads/new-symref\n\nrefs/heads/main\n\n```\n\n\n上記の例ではトランザクション内で新しいシンボリック参照が作成され、別のシンボリック参照が更新されています。こうした新しいsymref命令を既存の命令と組み合わせて使用することで、あらゆる種類の参照更新を単一のトランザクションで実行できます。新しい命令に関する詳細はこちらの[ドキュメント](https://git-scm.com/docs/git-update-ref)をご覧ください。\n\n\nこのプロジェクトは[Karthik Nayak](https://gitlab.com/knayakgl)が主導しました。\n\n\n## git-config(1)のUXの改善\n\n\ngit-config(1)コマンドを使用すると、リポジトリやグローバルオプションの表示や設定を行えます。設定を行う際に使用するモードは、フラグを使用して明示的に選択したり、コマンドに指定した引数の数に基づいて暗黙的に決定したりすることができます。例：\n\n\n```shell\n\n$ git config --list\n\n# ユーザー名の設定を明示的に取得\n\n$ git config --get user.name\n\n# ユーザー名の設定を暗黙的に取得\n\n$ git config user.name\n\n# ユーザー名の設定を明示的に行う\n\n$ git config --set user.name \"Sidney Jones\"\n\n# ユーザー名の設定を暗黙的に行う\n\n$ git config user.name \"Sidney Jones\"\n\n# 3つ目の引数を指定することも可能です。これは何の役に立つのでしょうか？\n\n$ git config \u003Cname> [\u003Cvalue> [\u003Cvalue-pattern>]]\n\n```\n\n\n全体的に[git-config(1)](https://git-scm.com/docs/git-config)のユーザーインターフェイスは、サブコマンドを使うのが一般的な、他のより現代的なGitコマンドの動作とは一致していません（例：`git\nremist`）。このリリースではconfigコマンドで使用するサブコマンドとして`list`、`get`、`set`、`unset`、`rename-section`、`remove-section`、`edit`が導入されましたが、以前の形式の構文も引き続き使用できます。今回の変更はconfigコマンドをよりUIに沿ったものにし、Git内の他のコマンドとの整合性を高めてユーザーエクスペリエンスを向上させることを目的としています。以下は新しいコマンドの使用例です。\n\n\n```shell\n\n$ git config list\n\n$ git config get user.name\n\n$ git config set user.name \"Sidney Jones\"\n\n```\n\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)によって主導されました。\n\n\n## パフォーマンスのリグレッションへの対応\n\n\n属性を使用するGit操作は、リポジトリのworktreeにある`.gitattributes`ファイルの読み取りに依存しています。bare\nGitリポジトリの場合は定義上worktreeが欠如しているため、問題となります。これを回避するためGitには`attr.tree`という設定があり、SourceTreeを指定して属性を参照できます。\n\n\nGitリリース2.43.0では、bareリポジトリのGit属性のソースとして`HEAD`のツリーをデフォルトで使用するようになりました。残念なことに、Gitの属性ファイルのスキャンによる負荷の増加は、パフォーマンスに深刻な影響を及ぼす結果となっています。これは`attr.tree`が設定されている場合、属性を検索するたびにSourceTreeを開いて関連する`.gitattributes`ファイルを確認する必要があるためです。リポジトリのSourceTreeが大きく深くなればなるほど、性能のリグレッションも顕著なものとなります。たとえば、linux.gitリポジトリで実行されるベンチマークでは、git-pack-objects(1)完了までに1.68倍の時間がかかっています。これにより、クローンやフェッチを実行する際に速度が低下するおそれがあります。\n\n\n```\n\n# Gitバージョン2.43.0では、デフォルトでattr.treeがHEADに完了済みとして設定されています。\n\nBenchmark 1: git -c attr.tree=HEAD pack-objects --all --stdout \u003C/dev/null\n>/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が空のツリーに設定されていました。\n\nBenchmark 2: git -c attr.tree=4b825dc642cb6eb9a060e54bf8d69288fbee4904\npack-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\n\nこれまでGitプロジェクトでのテストは、シェルスクリプトとして実装されたE2Eテストを通じて行われてきました。Gitプロジェクトでは比較的最近、Cで書かれたユニットテストフレームワークが導入されました。この新しいテストフレームワークにより、個々の関数呼び出しレベルで低レベルの実装の詳細をより詳しくテストする機会がもたらされたほか、既存のE2Eテストが補完されます。既存のE2Eテストにはユニットテストにより適しているものがあり、移行に適しています。\n\n\n本年度も、GitLabは[Google Summer of\nCode（GSoC）](https://summerofcode.withgoogle.com/)のGitプロジェクトに参加するコントリビューターのメンターを務めています。進行中のGSoCプロジェクトとより広範なGitコミュニティの貢献により、既存のテストの一部がリファクタリングされ、ユニットテストフレームワークに移行されつつあります。前回のリリースサイクルでは、Gitプロジェクトのテストを改善するという目標に向けて複数のコントリビュートがありました。上述のGSoCコントリビューターのプロジェクトの詳細については、[Chandra](https://chand-ra.github.io/)および[Ghanshyam](https://spectre10.github.io/posts/)のブログをご確認ください。\n\n\n## バンドルURIの修正\n\n\n通常、クライアントがリモートリポジトリからフェッチする場合、必要なすべてのオブジェクトはリモートサーバーによって計算されたパックファイルで送信されます。こうした計算の一部を回避するため、サーバーは、リモートサーバーとは別に保存され、クライアントが必要とする可能性のある参照とオブジェクトのセットを含む事前構築の「バンドル」のアドバタイズを選択できます。クライアントは、[bundle-uri](https://git-scm.com/docs/bundle-uri)と呼ばれるメカニズムを介して最初にこうしたバンドルを取得できます。\n\n\n[Xing\nXin](https://lore.kernel.org/git/pull.1730.git.1715742069966.gitgitgadget@gmail.com/)さんのコントリビュートにより、いくつかのバンドルをダウンロードしたにもかかわらず、Gitがバンドルがないかのようにリモートからすべてをダウンロードし続けるという問題が特定・修正されました。これは、Gitがダウンロードしたすべてのバンドルを正しく検出できなかったために、リモートから連続したバンドルを取得する必要があったことが理由でした。この問題が修正されたことで、bundle-uriメカニズムを使用するリモートは冗長な作業を実行する必要がなくなったため、パフォーマンスが向上します。\n\n\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",[9,677,269],{"slug":950,"featured":90,"template":680},"whats-new-in-git-2-46-0","content:ja-jp:blog:whats-new-in-git-2-46-0.yml","Whats New In Git 2 46 0","ja-jp/blog/whats-new-in-git-2-46-0.yml","ja-jp/blog/whats-new-in-git-2-46-0",{"_path":956,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":957,"content":963,"config":968,"_id":970,"_type":13,"title":971,"_source":15,"_file":972,"_stem":973,"_extension":18},"/ja-jp/blog/whats-new-in-git-2-47-0",{"title":958,"description":959,"ogTitle":958,"ogDescription":959,"noIndex":6,"ogImage":960,"ogUrl":961,"ogSiteName":667,"ogType":668,"canonicalUrls":961,"schema":962},"Git 2.47.0の新機能","Gitの最新バージョンについてご紹介します。新たに追加されたグローバル変数を使用すれば、参照やオブジェクトのハッシュの形式を設定できます。GitLabのGitチームと、より広範なGitコミュニティによるコントリビュートをご確認ください。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663691/Blog/Hero%20Images/AdobeStock_752438815.jpg","https://about.gitlab.com/blog/whats-new-in-git-2-47-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git 2.47.0の新機能\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Justin Tobler\"}],\n        \"datePublished\": \"2024-10-07\",\n      }",{"title":958,"description":959,"authors":964,"heroImage":960,"date":965,"body":966,"category":675,"tags":967},[905],"2024-10-07","Gitプロジェクトは、最近[Gitバージョン2.47.0](https://lore.kernel.org/git/xmqqa5fg9bsz.fsf@gitster.g/)をリリースしました。\n\nGitLabのGitチームやより広範なGitコミュニティからのコントリビュートを含む、本リリースの主なハイライトをご覧ください。\n\n\n## 新しいグローバル構成オプション\n\n\nGitの最新リリースをチェックしている方であれば、[Gitバージョン2.45](https://about.gitlab.com/blog/whats-new-in-git-2-45-0/)より新たに提供開始された「reftable」参照バックエンドについてご存知かもしれません。詳しくは、『[Git\nreftableフォーマットの入門ガイド](https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format/)』をご確認ください。これまでは、「reftable」フォーマットを使用してリポジトリを初期化するには、次のようにgit-init(1)コマンドに`--ref-format`オプションを付けて実行する必要がありました。\n\n\n```sh\n\n$ git init --ref-format reftable\n\n```\n\n\nGit\n2.47のリリースでは、`init.defaultRefFormat`という設定オプションが追加され、リポジトリを初期化する際にどの参照バックエンドを使用するかをGitに指示できるようになりました。このオプションを使用することで、デフォルトの「files」バックエンドを上書きし、「reftable」バックエンドを利用できるようになります。設定するには、以下のコマンドを実行します\n\n\n```sh\n\n$ git config set --global init.defaultRefFormat reftable\n\n```\n\n\n一部の方はご存知かもしれませんが、Gitリポジトリで使用されるオブジェクトのハッシュ形式も設定可能です。デフォルトでは、リポジトリはSHA-1オブジェクト形式を使用するように初期化されますが、SHA-256形式というより安全で将来性のある代替案もあります。詳しくは、[GitalyにおけるSHA-256のサポートに関する過去のブログ記事](https://about.gitlab.com/blog/sha256-support-in-gitaly/#what-is-sha-256%3F)でご確認いただけます。SHA-256リポジトリは、git-init(1)に`--object-format`オプションを指定することで作成できます。\n\n\n```sh\n\n$ git init --object-format sha256\n\n```\n\n\nこのGitのリリースでは、別の設定オプションとして、`init.defaultObjectFormat`が追加されました。このオプションは、リポジトリを初期化する際に、どのオブジェクト形式をデフォルトで使用するかをGitに指示するものです。以下のコマンドで設定できます。\n\n\n```sh\n\n$ git config set --global init.defaultObjectFormat sha256\n\n```\n\n\n注意点として、SHA-256リポジトリはSHA-1リポジトリと互換性がなく、すべてのフォージがSHA-256リポジトリのホスティングをサポートしているわけではありません。先日GitLabが発表した[SHA-256リポジトリの実験的サポート](https://about.gitlab.com/blog/gitlab-now-supports-sha256-repositories/)をお試しになれます。\n\n\nこれらのオプションを使うことで、すぐにこれらのリポジトリ機能を使用できるようになり、新しいリポジトリを初期化するたびに形式について検討せずに済みます。\n\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n\n## git-refs(1)のサブコマンド\n\n\n前回のGitリリースでは、リポジトリ内の参照への低レベルアクセスを可能にするコマンド「[git-refs(1)](https://git-scm.com/docs/git-refs)」が導入されました。このコマンドには、参照バックエンド間での変換を行う「migrate」サブコマンドが含まれていました。今回のリリースでは、新たに「verify」サブコマンドが追加され、参照データベースの整合性を確認できるようになりました。リポジトリの整合性を確認する際には、「[git-fsck(1)](https://git-scm.com/docs/git-fsck)」を実行するケースが多々あります。\n\n\nしかし、このコマンドはリポジトリの参照データベースを明示的に検証するわけではありません。特に「reftable」というバイナリ形式の参照形式が導入されたことで、手動での検証が難しくなり、このギャップを埋めるツールの必要性が増しています。例として、無効な参照を設定したリポジトリを作成して検証してみましょう。\n\n\n```sh\n\n# The \"files\" backend is used so we can easily create an invalid reference.\n\n$ git init --ref-format files\n\n$ git commit --allow-empty -m \"init\"\n\n# A lone '@' is not a valid reference name.\n\n$ cp .git/refs/heads/main .git/refs/heads/@\n\n$ git refs verify\n\nerror: refs/heads/@: badRefName: invalid refname format\n\n```\n\n\nこの例では、無効な参照が検出され、エラーメッセージが表示されていることが確認できます。このツールはエンドユーザーが頻繁に使用するものではありませんが、サーバー側でリポジトリの整合性を保つために特に有用です。最終的には、このコマンドを「git-fsck(1)」に統合し、一貫したリポジトリ整合性チェックを行えるようにすることが目標です。\n\n\nこのプロジェクトは、Google Summer of Code（GSoC）の一環としてJialuo\nSheによって主導されました。詳しくは、Jialuoの『[GsoCレポート](https://luolibrary.com/2024/08/25/GSoC-Final-Report/)』をご参照ください。\n\n\n## reftableに関連した進行中の作業\n\n\n今回のリリースでは、「reftable」バックエンドに関するいくつかのバグ修正も含まれています。その中でも特に興味深いのは、テーブルの圧縮プロセスに関するバグです。\n\n\nご存知でない方のために説明すると、reftableバックエンドはリポジトリ内のすべての参照の状態を保持する一連のテーブルで構成されています。各参照のアトミックな変更が行われるたびに、新しいテーブルが作成され、「tables.list」ファイルに記録されます。テーブルの数を減らすために、参照の更新後には、テーブルがファイルサイズに基づいた幾何数列に従って圧縮されます。テーブルが圧縮されると、「tables.list」ファイルも更新され、ディスク上のreftableの最新の状態が反映されます。\n\n\n設計上、テーブルの書き込みと圧縮を同時に実行可能です。特定のタイミングでの同期は、ロックファイルを使用して制御されています。たとえば、圧縮が始まる際には、最初に「tables.list」ファイルが、安定した読み込みのためにロックされます。また、圧縮が必要なテーブルもロックされる場合があります。実際のテーブルの圧縮には時間がかかるため、ロックは途中で解除され、同時書き込みが実行されます。同時書き込みは、ロックされている圧縮対象のテーブルを変更してはいけないことを理解した上で行われるため、この処理は安全です。圧縮された新しいテーブルの書き込みが完了すると、再び「tables.list」ファイルがロックされ、今度は新しいテーブルの状態が反映されるように更新されます。\n\n\nしかし、次のような問題があります。もし、テーブルの圧縮中に最初のロックが解除された後、リストファイルが更新される前に、参照の同時更新によって新しいテーブルが「tables.list」に書き込まれたらどうなるでしょうか？このような競合が起こると、圧縮プロセスでは新しいテーブルの存在が認識されず、新しいテーブルを反映しないまま「tables.list」ファイルを書き直してしまいます。これにより、同時に行われた更新が失われ、参照が想定どおりに追加、更新、削除されない結果になる可能性があります。\n\n\n幸い、この問題は比較的簡単な手順で解決できます。圧縮プロセスで「tables.list」ファイルへの書き込みのためにロックが取得される際は、ファイルに更新があったかどうかを最初に確認してから、ファイルを再読み込みする必要があります。これにより、同時に行われたテーブルの更新も正しく反映されるようになります。こちらの修正について詳しくは、該当する[メーリングリストのスレッド](https://lore.kernel.org/git/cover.1722435214.git.ps@pks.im/)をご参照ください。\n\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n\n## git-maintenance(1)の修正\n\n\nリポジトリが大きくなるにつれて、適切なメンテナンスが重要になります。デフォルトでは、Gitは特定のオペレーション後に[git-maintenance(1)](https://git-scm.com/docs/git-maintenance)を実行することで、リポジトリの健全性を保ちます。その際、不要なメンテナンスが行われないようにするために、`--auto`オプションが指定されています。このオプションでは、定義されたヒューリスティック（経験則）を使用してメンテナンスタスクを実行するかどうかを決定します。このコマンドは、さまざまなメンテナンスタスクを実行するように設定できますが、デフォルトでは、ユーザーが通常の作業を続けられるように、[git-gc(1)](https://git-scm.com/docs/git-gc)のみがバックグラウンドで実行されるようになっています。\n\n\nこの動作は通常、期待どおりに機能しますが、デフォルト以外のメンテナンスタスクを実行するように設定されている場合、設定されたメンテナンスタスクはフォアグラウンドで実行され、最初のメンテナンスプロセスはすべてのタスクが完了するまで終了しません。唯一「gc」タスクだけが期待どおりにバックグラウンドで実行されます。この原因は、git-gc(1)が`--auto`オプションで実行された際に、誤ってプロセスをデタッチしていたこと、また、ほかのメンテナンスタスクがそのような機能を持っていなかったことであると判明しました。この問題により、一部のGitコマンドが自動メンテナンスの完了を待機する必要があり、コマンドの実行速度が低下する可能性がありました。\n\n\n今回のリリースでは、git-maintenance(1)に`--detach`オプションが追加され、個々のタスクではなくgit-maintenance(1)全体のプロセスをバックグラウンドで実行できるようになったことで、この問題が解消されました。また、Gitが実行する自動メンテナンスもこの新しいオプションを使うように更新されています。こちらの修正について詳しくは、[メーリングリストのスレッド](https://lore.kernel.org/git/cover.1723533091.git.ps@pks.im/)をご参照ください。\n\n\n前述したように、自動メンテナンスでは、特定のメンテナンス操作を実行すべきかどうかを判断するために一連のヒューリスティックが使用されます。しかし残念なことに、「files」参照バックエンドでは、[git-pack-refs(1)](https://git-scm.com/docs/git-pack-refs)が`--auto`オプションで実行された場合、このようなヒューリスティックが存在せず、疎な参照が必ず「packed-refs」ファイルにパック化されてしまいます。多くの参照を持つリポジトリでは、「packed-refs」ファイルの書き換えに時間がかかることがあります。\n\n\n今回のリリースでは、「files」バックエンドで疎な参照をパック化するかどうかを決定するヒューリスティックも導入されました。このヒューリスティックは、既存の「packed-refs」ファイルのサイズとリポジトリ内の疎な参照の数を考慮します。「packed-refs」ファイルが大きくなるほど、参照のパック化が実行される前に許容される疎な参照の数のしきい値も上がります。これにより、「files」バックエンドでの参照のパック化をやや抑制しつつ、適切にリポジトリがメンテナンスされた状態を保てます。詳しくは、[メーリングリストのスレッド](https://lore.kernel.org/git/cover.1725280479.git.ps@pks.im/)をご参照ください。\n\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n\n## コードリファクタリングと保守性の向上\n\n\n機能の変更に加えて、コードリファクタリングやクリーンアップも進められています。これらの改善は、プロジェクトの内部コンポーネントをライブラリ化するという長期的な目標にも寄与するという点でも重要です。ライブラリ化に関する最新のアップデートについては、[こちらのスレッド](https://lore.kernel.org/git/eoy2sjhnul57g6crprxi3etgeuacjmgxpl4yllstih7woyuebm@bd62ib3fi2ju/)をご参照ください。\n\n\nメモリリークを解決することも、求められていた改善事項でした。Gitプロジェクトには多くのメモリリークが存在しますが、通常Gitプロセスは短時間しか動作せず、システムによるクリーンアップが後から行われるため、大きな問題が生じることはあまりありません。しかし、ライブラリ化を進める上では、この問題に対処する必要があります。リークサニタイザを使ってプロジェクト内のテストをコンパイルし、リークを検出することはできますが、既存のリークが存在しているために、新しい変更が新たなリークを引き起こしていないかを検証し、それを阻止するのは難しい状況でした。現在、プロジェクト内の既存のテストで検出されたすべてのメモリリークを修正する取り組みが進められています。リークのないテストは`TEST_PASSES_SANITIZE_LEAK=true`とマークされ、今後もリークが発生しないことが想定されます。今回のリリース以前は、プロジェクトにメモリリークを含むテストファイルが223件ありましたが、今回のリリースでは60件にまで減少しました。\n\n\nもう1つの取り組みとして、プロジェクト全体でグローバル変数の使用を減らす作業が進められています。その中でも特に問題視されているのが`the_repository`というグローバル変数で、これはオペレーション中のリポジトリの状態を保持し、プロジェクト内のさまざまな箇所で参照されています。今回のリリースでは、この`the_repository`の使用を減らし、必要な場所に直接値を渡すようにするための複数のパッチが導入されました。まだ`the_repository`に依存しているGitプロジェクトのサブシステムでは、このグローバル変数を使用できるようにするために`USE_THE_REPOSITORY_VARIABLE`が定義されています。現在ではrefs、config、pathのサブシステムはこの変数に依存しなくなりました。\n\n\nこのプロジェクトは、[John Cai](https://gitlab.com/jcaigitlab)と[Jeff\nKing氏](https://github.com/peff)の協力のもと、[Patrick\nSteinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n\n## 補足情報\n\n\nこのブログ記事では、GitLabや広範なGitコミュニティによる最新リリースへのコントリビュートの一部をご紹介しました。Gitプロジェクトの[公式リリースのお知らせ](https://lore.kernel.org/git/xmqqa5fg9bsz.fsf@gitster.g/)では、さらに詳しい情報をご覧になれます。また、[過去のGitリリースに関するブログ記事](https://about.gitlab.com/blog/tags/git/)では、GitLabチームメンバーによるこれまでの主要なコントリビュートをご紹介しています。\n\n\n- [Git\n2.46.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-46-0/)\n\n- [Git\n2.45.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-45-0/)\n\n- [Git\nreftableフォーマットの入門ガイド](https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format/)\n\n- [git fetchとgit\npullコマンドの違いとは？](https://about.gitlab.com/blog/git-pull-vs-git-fetch-whats-the-difference/)\n",[9,677,269],{"slug":969,"featured":90,"template":680},"whats-new-in-git-2-47-0","content:ja-jp:blog:whats-new-in-git-2-47-0.yml","Whats New In Git 2 47 0","ja-jp/blog/whats-new-in-git-2-47-0.yml","ja-jp/blog/whats-new-in-git-2-47-0",{"_path":975,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":976,"content":981,"config":988,"_id":990,"_type":13,"title":991,"_source":15,"_file":992,"_stem":993,"_extension":18},"/ja-jp/blog/whats-new-in-git-2-48-0",{"title":977,"description":978,"ogTitle":977,"ogDescription":978,"noIndex":6,"ogImage":960,"ogUrl":979,"ogSiteName":667,"ogType":668,"canonicalUrls":979,"schema":980},"Git 2.48.0の新機能","Gitの最新バージョンについてご紹介します。新たなビルドシステムに加え、最適化された新しいreftableバックエンドが導入されました。また、GitLabのGitチームおよびGitコミュニティによるコントリビュートもご紹介します。","https://about.gitlab.com/blog/whats-new-in-git-2-48-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git 2.48.0の新機能\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christian Couder\"}],\n        \"datePublished\": \"2025-01-10\",\n      }",{"title":977,"description":978,"authors":982,"heroImage":960,"date":984,"body":985,"category":675,"tags":986,"updatedDate":987},[983],"Christian Couder","2025-01-10","Gitプロジェクトは先日[Git 2.48.0](https://lore.kernel.org/git/xmqqplku7cvm.fsf@gitster.g/)をリリースしました。本記事では、GitLabのGitチームや幅広いGitコミュニティからのコントリビュートなど、このリリースにおけるハイライトをご紹介します。\n\n## Mesonビルドシステム\n\nこれまで長い間、Gitは[Makefile](https://en.wikipedia.org/wiki/GNU_Make)ベースまたは[Autoconf](https://en.wikipedia.org/wiki/Autoconf)ベースのビルドシステムのいずれかを使用してビルドできる仕組みになっていました。しかし、Gitデベロッパーの多くはMakefileベースのビルドシステムを主に利用しており、[Autoconfベースのビルドシステムは機能やメンテナンスの面で後れ](https://lore.kernel.org/git/GV1PR02MB848925A79A9DD733848182D58D662@GV1PR02MB8489.eurprd02.prod.outlook.com/)を取っていました。また、Windowsデベロッパーがよく利用する統合開発環境（IDE）は、MakefileやAutoconfベースのビルドシステムを十分にサポートしていないという問題もありました。\n\n2020年に[CMake](https://cmake.org/)を使用したGitのビルドが可能になり、特にVisual Studio向けに、WindowsでのサポートやIDE統合が改善されました。また、out-of-sourceビルドなどのモダンなビルドシステムも追加されました。\n\nしかし、最近ではCMakeのサポートも後れを取っており、前述の2つのビルドシステムを完全に置き換えるには適していない可能性が出てきました。こうした背景から、GitLabのGitエンジニアリングマネージャーである[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が、[Meson](https://mesonbuild.com/)ビルドシステムを導入しました。これにより、最終的にAutoconf、CMake、そして場合によってはMakefileベースのビルドシステムを置き換えることが期待されています。\n\nMesonビルドシステムの主なメリットは以下のとおりです。\n* MakefileやCMakeでは難しいビルドオプションを簡単に確認できる\n* AutoconfやCMakeに比べてシンプルな構文\n* さまざまなOS、コンパイラ、IDEをサポート\n* out-of-sourceビルドなど、モダンなビルドシステムに対応\n\n以下に、Mesonを使用したGitのビルド方法をご紹介します。\n\n```shell\n$ cd git             \t# Gitのソースコードのルートディレクトリに移動\n$ meson setup build/ \t# \"build\"をビルドディレクトリとして設定\n$ cd build           \t# \"build\"ディレクトリに移動\n$ meson compile      \t# Gitをビルド\n$ meson test         \t# 新しいビルドをテスト\n$ meson install      \t# 新しいビルドをインストール\n\n```\n\n`meson setup \u003Cbuild_dir>`を使うことで、複数のビルドディレクトリを設定できます。また、ビルドディレクトリ内で`meson configure`を実行して、そのディレクトリのビルド構成を確認または変更できます。\n\n詳しい手順は、Gitコードリポジトリの[`meson.build`ファイル](https://gitlab.com/gitlab-org/git/-/blob/master/meson.build)の冒頭に記載されています。また、Gitで使用される[ビルドシステムの比較](https://gitlab.com/gitlab-org/git/-/blob/master/Documentation/technical/build-systems.txt)は、Gitの技術ドキュメントで確認できます。\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n## Gitのメモリリーク完全解消（テストスイートによる検証済み）\n\n前回のGit 2.47.0リリースに関するブログ記事で触れたように、GitLabでは[プロジェクト内で発生したメモリリークの修正](https://about.gitlab.com/blog/whats-new-in-git-2-47-0/#code-refactoring-and-maintainability-improvements)に取り組んできました。その結果、Git 2.47.0リリース以前は、223のテストファイルで確認されていたメモリリークが、最終的に60ファイルまで削減されました。\n\nその後、残りの60ファイルにおけるメモリリークもすべて解消され、テストスイートで検証された範囲では、Gitは完全にメモリリークがない状態となりました。この成果は、Git内部コンポーネントを内部ライブラリに「ライブラリ化（変換）」するという長年の目標に向け大きく前進したことを示しています。また、メモリ使用の最適化にもつながります。\n\n今後、新たに追加されるテストはデフォルトでメモリリークがないことが求められます。リークを含むテストも可能ですが、その場合、作成者は例外的な処理を使用して、メモリリークを解消できない理由を明示する必要があります。\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n## バンドルURIチェックの改善\n\nGit 2.46.0リリースに関するブログ記事で[Xing Xin](https://lore.kernel.org/git/pull.1730.git.1715742069966.gitgitgadget@gmail.com/)による[バンドルURI修正](https://about.gitlab.com/blog/whats-new-in-git-2-46-0/#bundle-uri-fixes)を取り上げました。 その後、Xing Xinは[バンドルを使ったフェッチ](https://lore.kernel.org/git/pull.1730.v8.git.1718770053.gitgitgadget@gmail.com/)が、通常のフェッチと同様に[fsck](https://git-scm.com/docs/git-fsck)メカニズムで完全に検証されるように改良しました。\n\n通常のフェッチの検証では、[異なるfsckの問題](https://git-scm.com/docs/git-fsck#_fsck_messages)に対して[異なる重大度](https://git-scm.com/docs/git-fsck#Documentation/git-fsck.txt-fsckltmsg-idgt)を指定することで、特定のリポジトリにおいて何を許容し、何を拒否するかを細かく制御できます。しかし、これまでバンドルを使ったフェッチではこうした制御は不可能でした。\n\n[バンドルURI](https://git-scm.com/docs/bundle-uri)の有用性と安全性をさらに高めるために、[この問題を解決](https://lore.kernel.org/git/20241121204119.1440773-1-jltobler@gmail.com/)し、バンドルを使ったフェッチの検証にも異なるfsck問題に対して異なる重大度を指定できるようにしました。\n\nこのプロジェクトは[Justin Tobler](https://gitlab.com/justintobler)が主導しました。\n\n## 参照の整合性チェックを追加\n\nGit 2.47.0リリースに関するブログ記事で、[Google Summer of Code 2024](https://summerofcode.withgoogle.com/archive/2024/projects/ukm4PTEF)（GSoC 2024）の一環としてJialuo Sheが[「verify」サブコマンドをgit-refs(1)に追加](https://about.gitlab.com/blog/whats-new-in-git-2-47-0/#new-subcommand-for-git-refs\\(1\\))したことについて言及しました。\n\n記事では、最終目標として、この新しいサブコマンドをgit-fsck(1)に統合し、リポジトリの整合性チェックを一元化できるようにすることを挙げました。GSoC終了後、Jialuo Sheはこの統合作業に着手しました。\n\n[この取り組み](https://lore.kernel.org/git/ZrtrT1CPI4YUf5db@ArchLinux/)の結果、git-fsck(1)は、参照の内容が不適切な場合や、シンボリック参照としてシンボリックリンクが使用された場合、ターゲットが無効な参照を指している場合など、参照に関連するさまざまな問題を検出し処理できるようになりました。git-fsck(1)の一部として`git refs verify`を呼び出し、git-fsck(1)が現在実行しているバックエンドに依存しないすべてのチェックを`git refs verify`が引き継ぐ必要がありますが、参照の整合性チェックを一元化するという最終目標に一歩近づきました。\n\nこのプロジェクトはJialuo Sheが主導しました。\n\n## reftableにおけるイテレータの再利用\n\n[Git 2.45.0](https://gitlab.com/gitlab-org/git/-/raw/master/Documentation/RelNotes/2.45.0.txt)のリリースでは、参照（主にブランチやタグ）を管理する新しいバックエンドとして「reftable」フォーマットが導入されました。reftableバックエンドについての詳細は、この機能を紹介している過去の[Gitリリースに関するブログ記事](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-45-0/)や、[reftableの仕組みを詳しく解説した](https://about.gitlab.com/ja-jp/blog/a-beginners-guide-to-the-git-reftable-format/)初心者向けガイドをお読みください。\n\n2.45.0以降もバックエンドの改良を重ね、最近では、[内部イテレータの再利用](https://lore.kernel.org/git/cover.1730732881.git.ps@pks.im/)によってランダムな参照を読み取る際のパフォーマンスを向上させることに注力しました。こうした改善がなされるまでは、単一の参照を読み取るたびに新しいイテレータを作成し、対象のテーブル内の正しい位置を探してそこに移動させ、次の値を読み取る必要があり、多くの参照を短時間で読み取る際にはきわめて非効率でした。しかし、今回の変更により、単一のイテレータを作成し、それを再利用して複数の参照を読み取ることで、処理効率を高められるようになりました。\n\nその結果、reftableに関連するさまざまなユースケースでパフォーマンスが向上しました。特に、ランダム読み取りが頻繁に実行されるトランザクション内で多くの参照を作成する際に、7%の速度向上が確認されています。また、この変更によって、イテレータ内で保持される状態をより多く再利用できるようになるため、最適化がさらに進むと予想できます。\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n## `git-refs migrate`におけるreflog対応\n\nGit 2.46.0のリリース記事では、[このツールに関する取り組み](https://about.gitlab.com/blog/whats-new-in-git-2-46-0/#tooling-to-migrate-reference-backends)に加え、いまだ存在する課題についても次のように言及しています。\n\n「リポジトリ内のreflogは参照バックエンドのコンポーネントであり、フォーマット間の移行も必要となります。残念ながら、現時点ではツールを使用してファイルとreftableバックエンドの間でreflogを変換することはできません」\n\n[この課題はGit 2.48.0で解決](https://lore.kernel.org/git/20241216-320-git-refs-migrate-reflogs-v4-0-d7cd3f197453@gmail.com/)されました。\n`git refs migrate`を使うことでreflogの移行も可能になりました。複数のワークツリーを持つリポジトリを扱うことはまだできませんが、残された課題はこの一点のみであり、ワークツリーを使用していない場合は、既存のリポジトリでreftableバックエンドをすでに利用することが可能です。\n\nこのプロジェクトは[Karthik Nayak](https://gitlab.com/knayakgl)が主導しました。\n\n## Ref-filterの最適化\n\n「ref-filter」サブシステムは、`git for-each-ref`、`git branch`、`git tag`といったコマンドで使用されるフォーマットコードで、Git参照に関連する情報を並べ替え、フィルタリング、フォーマット、表示する役割を担っています。\n\nリポジトリの規模が大きくなるにつれて、扱う参照の数も増加します。そのため、reftableバックエンドなどの参照を保存するバックエンド（上記参照）の改善だけでなく、「ref-filter」サブシステムのようなフォーマットコードの最適化にも取り組んでいます。\n\n今回、ref-filterのコードでバックエンドの順序通りに参照を処理すべき場合に、参照の一時的なバッファリングやイテレーション処理を不要にする[方法を特定](https://lore.kernel.org/git/d23c3e3ee7fdb49fcd05b4f2e52dd2a1cfdc10f2.1729510342.git.ps@pks.im/)しました。この結果、メモリの節約が可能になり、特定のコマンドでは処理速度が最大で770倍も速くなるケースが確認されています。\n\nこのプロジェクトは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)が主導しました。\n\n## 補足情報\n\nこのブログ記事では、最新リリースにおけるGitLabや広範なGitコミュニティによるコントリビュートの一部をご紹介しました。詳細は、Gitプロジェクトの公式リリース発表をご覧いただくと詳細をご確認いただけます。また、[これまでのGitリリースに関するブログ記事](https://about.gitlab.com/blog/tags/git/)では、GitLabチームの過去のコントリビュートもハイライトされていますので、ぜひご確認ください。\n\n- [Git 2.47.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-47-0/)（英語）\n- [Git 2.46.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-46-0/)（英語）\n- [Git 2.45.0の新機能](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-45-0/)\n- [初心者向けGit reftableフォーマットガイド](https://about.gitlab.com/ja-jp/blog/a-beginners-guide-to-the-git-reftable-format/)\n\n\u003Cbr>\n*監修：小松原 つかさ* [*@tkomatsubara*](https://gitlab.com/tkomatsubara)\u003Cbr>\n*（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*",[9,677,269],"2025-02-13",{"slug":989,"featured":90,"template":680},"whats-new-in-git-2-48-0","content:ja-jp:blog:whats-new-in-git-2-48-0.yml","Whats New In Git 2 48 0","ja-jp/blog/whats-new-in-git-2-48-0.yml","ja-jp/blog/whats-new-in-git-2-48-0",{"_path":995,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":996,"content":1001,"config":1007,"_id":1009,"_type":13,"title":1010,"_source":15,"_file":1011,"_stem":1012,"_extension":18},"/ja-jp/blog/whats-new-in-git-2-49-0",{"title":997,"description":998,"ogTitle":997,"ogDescription":998,"noIndex":6,"ogImage":906,"ogUrl":999,"ogSiteName":667,"ogType":668,"canonicalUrls":999,"schema":1000},"Git 2.49.0の新機能","このリリースでは、zlib-ngによるパフォーマンス向上、新しい名前ハッシュアルゴリズム、そして新しいコマンドgit-backfill(1)の導入などが行われています。","https://about.gitlab.com/blog/whats-new-in-git-2-49-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git 2.49.0の新機能\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Toon Claes\"}],\n        \"datePublished\": \"2025-03-14\",\n      }",{"title":997,"description":998,"authors":1002,"heroImage":906,"date":1004,"body":1005,"category":675,"tags":1006},[1003],"Toon Claes","2025-03-14","Gitプロジェクトは最近、[Git 2.49.0](https://lore.kernel.org/git/xmqqfrjfilc8.fsf@gitster.g/)をリリースしました。このリリースには、GitLabのGitチームや、より広範なGitコミュニティからのコントリビュートが含まれます。注目すべきハイライトを見てみましょう。\n\nこの記事では以下の変更点についてご紹介します。\n- [git-backfill(1)と新しいpath-walk API](#git-backfill(1)-and-the-new-path-walk-api)\n- [zlib-ngの導入](#introduction-of-zlib-ng)\n- [Mesonの継続的なイテレーション](#continued-iteration-on-meson)\n- [.git/branches/および.git/remotes/の非推奨化](#deprecation-of-.gitbranches%2F-and-.git%2Fremotes%2F)\n- [libgitに対するRustバインディング](#rust-bindings-for-libgit)\n- [新しい名前ハッシュアルゴリズム](#new-name-hashing-algorithm)\n- [プロミサーリモート機能](#promisor-remote-capability)\n- [`--revision`を使用した軽量なクローン](#thin-clone-using---revision)\n\n## git-backfill(1)と新しいpath-walk API\n\n[`git-clone(1)`](https://git-scm.com/docs/git-clone)コマンドでGitリポジトリをクローンする際に、\n[`--filter`](https://git-scm.com/docs/git-clone#Documentation/git-clone.txt-code--filterltfilter-specgtcode)オプションを指定することができます。\nこのオプションを使用すると、部分クローンを作成できます。部分クローンでは、指定されたオブジェクトフィルターに従って、サーバーから到達可能なオブジェクトの一部のみが送信されます。\n例えば、`--filter=blob:none`を指定してクローンを作成すると、サーバーからblob（ファイルの中身）が一切フェッチされず、_ブロブを含まないクローン_が作成されます。\n\nブロブを含まないクローンには、すべての到達可能なコミットとツリーは含まれますが、blobは含まれていません。そのため、[`git-checkout(1)`](https://git-scm.com/docs/git-checkout)のような操作を行うと、\nGitは必要なblobをサーバーからダウンロードして、その操作を完了させます。ただし、[`git-blame(1)`](https://git-scm.com/docs/git-blame)のような一部の操作では、\n必要なオブジェクトが1つずつダウンロードされることになり、この処理が非常に遅くなります。\nこれは、`git-blame(1)`がコミット履歴をたどって必要なblobを特定し、\n不足している各blobを個別にサーバーへリクエストする必要があるためです。\n\nGit 2.49では、新たに`git-backfill(1)`というサブコマンドが導入されました。これは、ブロブを含まない部分クローンに対して、不足しているblobをダウンロードするために使用できます。\n\n内部的には、`git-backfill(1)`は新しいパスウォークAPIを利用しています。これはGitが通常行うコミットのイテレーション処理とは異なります。従来の方法では、コミットを1つずつイテレーションし、それぞれに関連するツリーやblobに再帰的にアクセスしていました。一方、パスウォークAPIはパスごとに処理を行います。各パスについて関連するツリーオブジェクトのリストをスタックに追加し、そのスタックを深さ優先で処理します。つまり、コミット`1`のすべてのオブジェクトを処理してからコミット`2`へ進むのではなく、ファイル`A`のすべてのバージョンを全コミットにわたって処理してからファイル`B`に進む、という方式です。このアプローチは、パスごとにグループ化して処理する必要がある場合に、大幅なパフォーマンス向上をもたらします。\n\n[`gitlab-org/git`](https://gitlab.com/gitlab-org/git)リポジトリのブロブを含まないクローンを作成し、その使い方をお見せします。\n\n```shell\n$ git clone --filter=blob:none --bare --no-tags git@gitlab.com:gitlab-org/git.git\nCloning into bare repository 'git.git'...\nremote: Enumerating objects: 245904, done.\nremote: Counting objects: 100% (1736/1736), done.\nremote: Compressing objects: 100% (276/276), done.\nremote: Total 245904 (delta 1591), reused 1547 (delta 1459), pack-reused 244168 (from 1)\nReceiving objects: 100% (245904/245904), 59.35 MiB | 15.96 MiB/s, done.\nResolving deltas: 100% (161482/161482), done.\n```\n\n上の例では、Gitが初期ブランチをチェックアウトするためにblobをダウンロードする必要がないよう、`--bare`オプションを使用しています。このクローンにblobが含まれていないことは、次のコマンドで確認できます。\n\n```sh\n$ git cat-file --batch-all-objects --batch-check='%(objecttype)' | sort | uniq -c\n  83977 commit\n 161927 tree\n```\n\nもしこのリポジトリ内のファイル内容を確認したい場合、Gitはそのファイルをダウンロードする必要があります。\n\n```sh\n$ git cat-file -p HEAD:README.md\nremote: Enumerating objects: 1, done.\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 1 (from 1)\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\n\n[![Build status](https://github.com/git/git/workflows/CI/badge.svg)](https://github.com/git/git/actions?query=branch%3Amaster+event%3Apush)\n\nGit - fast, scalable, distributed revision control system\n=========================================================\n\nGit is a fast, scalable, distributed revision control system with an\nunusually rich command set that provides both high-level operations\nand full access to internals.\n\n[中略]\n```\n\nご覧のとおり、Gitはまずリモートリポジトリにアクセスし、blobをダウンロードしてから内容を表示しています。\n\nこのファイルに対して`git-blame(1)`を実行したい場合は、さらに多くのデータをダウンロードする必要があります。\n\n```sh\n$ git blame HEAD README.md\nremote: Enumerating objects: 1, done.\nremote: Counting objects: 100% (1/1), done.\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\nremote: Enumerating objects: 1, done.\nremote: Counting objects: 100% (1/1), done.\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\nremote: Enumerating objects: 1, done.\nremote: Counting objects: 100% (1/1), done.\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\nremote: Enumerating objects: 1, done.\n\n[中略]\n\ndf7375d772 README.md (Ævar Arnfjörð Bjarmason 2021-11-23 17:29:09 +0100  1) [![Build status](https://github.com/git/git/workflows/CI/badge.svg)](https://github.com/git/git/actions?query=branch%3Amaster+event%3Apush)\n5f7864663b README.md (Johannes Schindelin \t2019-01-29 06:19:32 -0800  2)\n28513c4f56 README.md (Matthieu Moy        \t2016-02-25 09:37:29 +0100  3) Git - fast, scalable, distributed revision control system\n28513c4f56 README.md (Matthieu Moy        \t2016-02-25 09:37:29 +0100  4) =========================================================\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  5)\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  6) Git is a fast, scalable, distributed revision control system with an\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  7) unusually rich command set that provides both high-level operations\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  8) and full access to internals.\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  9)\n\n[中略]\n```\n\n出力は省略していますが、ご覧のように、Gitはそのファイルの各リビジョンについて個別にサーバーへアクセスしています。これはとても非効率的です。そこで`git-backfill(1)`を使えば、Gitに対してすべてのblobを一括でダウンロードするよう指示できます。\n\n```shell\n$ git backfill\nremote: Enumerating objects: 50711, done.\nremote: Counting objects: 100% (15438/15438), done.\nremote: Compressing objects: 100% (708/708), done.\nremote: Total 50711 (delta 15154), reused 14730 (delta 14730), pack-reused 35273 (from 1)\nReceiving objects: 100% (50711/50711), 11.62 MiB | 12.28 MiB/s, done.\nResolving deltas: 100% (49154/49154), done.\nremote: Enumerating objects: 50017, done.\nremote: Counting objects: 100% (10826/10826), done.\nremote: Compressing objects: 100% (634/634), done.\nremote: Total 50017 (delta 10580), reused 10192 (delta 10192), pack-reused 39191 (from 1)\nReceiving objects: 100% (50017/50017), 12.17 MiB | 12.33 MiB/s, done.\nResolving deltas: 100% (48301/48301), done.\nremote: Enumerating objects: 47303, done.\nremote: Counting objects: 100% (7311/7311), done.\nremote: Compressing objects: 100% (618/618), done.\nremote: Total 47303 (delta 7021), reused 6693 (delta 6693), pack-reused 39992 (from 1)\nReceiving objects: 100% (47303/47303), 40.84 MiB | 15.26 MiB/s, done.\nResolving deltas: 100% (43788/43788), done.\n```\n\nこれにより、すべてのblobが補完され、ブロブを含まないクローンが完全なクローンになります。\n\n```shell\n$ git cat-file --batch-all-objects --batch-check='%(objecttype)' | sort | uniq -c\n 148031 blob\n  83977 commit\n 161927 tree\n```\n\nこの[プロジェクト](https://lore.kernel.org/git/pull.1820.v3.git.1738602667.gitgitgadget@gmail.com/)は[Derrick Stolee](https://stolee.dev/)によって主導され、[e565f37553](https://gitlab.com/gitlab-org/git/-/commit/e565f3755342caf1d21e22359eaf09ec11d8c0ae)でマージされました。\n\n## zlib-ngの導入\n\n`.git/`フォルダ内のすべてのオブジェクトは、Gitによって[`zlib`](https://zlib.net/)を使って圧縮されています。`zlib`は[RFC\n1950](https://datatracker.ietf.org/doc/html/rfc1950)（ZLIB圧縮データフォーマット）のリファレンス実装であり、1995年に作られました。`zlib`は長い歴史を持ち、非常に高い移植性があり、\nインターネット以前の多くのシステムもサポートしています。このように幅広いアーキテクチャやコンパイラをサポートしている一方で、\nzlibには機能面での制限もあります。\n\nその制限に対応するために生まれたのが[`zlib-ng`](https://github.com/zlib-ng/zlib-ng)というフォークです。\n`zlib-ng`は、現代的なシステム向けに最適化されることを目指しており、レガシーシステムのサポートを廃止する代わりに、\nIntel向けの最適化パッチや、Cloudflareによる最適化、その他いくつかの小規模なパッチが取り込まれています。\n\n`zlib-ng`ライブラリ自体は`zlib`との互換レイヤーを提供しており、この互換性により、`zlib-ng`を`zlib`の代替としてそのまま差し替えて使うことが可能です。\nただし、この互換レイヤーはすべてのLinuxディストリビューションで利用できるわけではありません。Git 2.49では以下の変更が加えられました。\n\n- Gitプロジェクトへのzlib-ng互換レイヤーの追加\n- [`Makefile`](https://gitlab.com/gitlab-org/git/-/blob/b9d6f64393275b505937a8621a6cc4875adde8e0/Makefile#L186-187)および[Mesonビルドファイル](https://gitlab.com/gitlab-org/git/-/blob/b9d6f64393275b505937a8621a6cc4875adde8e0/meson.build#L795-811)へのビルドオプションの追加\n\nこれらの追加により、`zlib-ng`によるパフォーマンス向上の恩恵を受けやすくなりました。\n\nローカルでのベンチマークでは、`zlib`ではなく`zlib-ng`を使用することで約25%の高速化が確認されています。現在、これらの変更をGitLab.comにも順次導入中です。\n\n`zlib-ng`によるパフォーマンス向上の恩恵を受けたい場合は、まず`git version --build-options`コマンドを実行して、お使いのマシンでGitがすでに`zlib-ng`を使用しているかどうかを確認してください。\n\n```shell\n$ git version --build-options\ngit version 2.47.1\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nlibcurl: 8.6.0\nOpenSSL: OpenSSL 3.2.2 4 Jun 2024\nzlib: 1.3.1.zlib-ng\n```\n\n出力の一番下の行に`zlib-ng`と表示されていれば、すでにGitは高速な`zlib`のバリアントでビルドされています。表示されていない場合は、以下のいずれかの方法で対応できます。\n\n- お使いのGitパッケージのメンテナーに、`zlib-ng`のサポートを有効にしてもらうよう依頼する\n- Gitをソースコードから自分でビルドする\n\nなお、これらの[変更](https://gitlab.com/gitlab-org/git/-/commit/9d0e81e2ae3bd7f6d8a655be53c2396d7af3d2b0)\nは[Patrick Steinhardt](https://gitlab.com/pks-gitlab)によって[導入](https://lore.kernel.org/git/20250128-b4-pks-compat-drop-uncompress2-v4-0-129bc36ae8f5@pks.im/)されました。\n\n## Mesonの継続的なイテレーション\n\nGit 2.48のリリースについて紹介した記事では、[Mesonビルドシステムの導入](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-48-0/#meson%E3%83%93%E3%83%AB%E3%83%89%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0)について触れました。[Meson](https://ja.wikipedia.org/wiki/Meson_(%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2))は、Gitプロジェクトで使用されるビルド自動化ツールで、将来的には[Autoconf](https://ja.wikipedia.org/wiki/Autoconf),\n[CMake](https://ja.wikipedia.org/wiki/CMake)さらには\n[Make](https://ja.wikipedia.org/wiki/Make_(UNIX))に取って代わる可能性もあります。\n\n今回のリリースサイクルでも、Mesonの利用に関する作業が引き続き進められ、不足していた機能の追加や安定性向上のための以下の修正が行われました。\n\n  - [CIのテストカバレッジ改善](https://lore.kernel.org/git/20250122-b4-pks-meson-additions-v3-0-5a51eb5d3dcd@pks.im/)が、コミット[72f1ddfbc9](https://gitlab.com/gitlab-org/git/-/commit/72f1ddfbc95b47c6011bb423e6947418d1d72709)でマージされました\n- [`contrib/`ディレクトリでMesonを使えるようにする作業の一部](https://lore.kernel.org/git/20250219-b4-pks-meson-contrib-v2-0-1ba5d7fde0b9@pks.im/)が、コミット[2a1530a953](https://gitlab.com/gitlab-org/git/-/commit/2a1530a953cc4d2ae62416db86c545c7ccb73ace)でマージされました\n  - [Mesonベースのビルド手順に関する修正や改善](https://lore.kernel.org/git/20250226-b4-pks-meson-improvements-v3-0-60c77cf673ae@pks.im/)が、コミット[ab09eddf60](https://gitlab.com/gitlab-org/git/-/commit/ab09eddf601501290b5c719574fbe6c02314631f)でマージされました\n  - [git-subtree(1)のビルドにMesonを対応させる変更](https://lore.kernel.org/git/20250117-b4-pks-build-subtree-v1-0-03c2ed6cc42e@pks.im/)が、コミット[3ddeb7f337](https://gitlab.com/gitlab-org/git/-/commit/3ddeb7f3373ae0e309d9df62ada24375afa456c7)でマージされました\n  - [MesonにHTMLドキュメントページの生成を学習させる変更](https://lore.kernel.org/git/20241227-b4-pks-meson-docs-v2-0-f61e63edbfa1@pks.im/)が、コミット[1b4e9a5f8b](https://gitlab.com/gitlab-org/git/-/commit/1b4e9a5f8b5f048972c21fe8acafe0404096f694)でマージされました\n\nこれらの作業はすべて[Patrick Steinhardt](https://gitlab.com/pks-gitlab)によって行われました。\n\n## .git/branches/および.git/remotes/の非推奨化\n\nおそらく、 `.git`ディレクトリやその中身についてはご存じかと思います。\nしかし、 `.git/branches/`や`.git/remotes/`というサブディレクトリの存在についてはどうでしょうか？\nご存じの通り、ブランチへの参照は`.git/refs/heads/`に保存されているため、`.git/branches/`はそのための場所ではありません。そして、`.git/remotes/`の用途は何でしょうか？\n\n2005年、[`.git/branches/`](https://git-scm.com/docs/git-fetch#_named_file_in_git_dirbranches)はリモートの短縮名を保存するために導入されました。そしてその数か月後に、それらは[`.git/remotes/`](https://git-scm.com/docs/git-fetch#_named_file_in_git_dirremotes)に移動されました。\n[2006年](https://lore.kernel.org/git/Pine.LNX.4.63.0604301520460.2646@wbgn013.biozentrum.uni-wuerzburg.de/)には、[`git-config(1)`](https://git-scm.com/docs/git-config)に[リモート](https://git-scm.com/docs/git-config#Documentation/git-config.txt-remoteltnamegturl)設定を保存する機能が追加され、\nこれがリモートを設定する標準的な方法として定着しました。\nその後2011年には、`.git/branches/`と`.git/remotes/`は「レガシー」であることが[文書化](https://gitlab.com/git-scm/git/-/commit/3d3d282146e13f2d7f055ad056956fd8e5d7ed29#e615263aaf131d42be8b0d0888ebd3fec954c6c9_132_124)され、現代のリポジトリでは使用されなくなりました。\n\nそして2024年、Gitの次のメジャーバージョン（v3.0）の破壊的な変更の概要をまとめるドキュメント[破壊的な変更](https://git-scm.com/docs/BreakingChanges)が作成されました。\nこのリリースはすぐに行われる予定はありませんが、このドキュメントにはそのリリースに含まれると予想される変更点について記載されています。\nコミット[8ccc75c245](https://gitlab.com/git-scm/git/-/commit/8ccc75c2452b5814d2445d60d54266293ca48674)では、`.git/branches/`および`.git/remotes/`ディレクトリの使用に関する内容がこのドキュメントに追加され、これにより公式に非推奨とされ、Git 3.0で削除予定であることが明示されました。\n\n[この非推奨化を正式に文書化](https://lore.kernel.org/git/20250122-pks-remote-branches-deprecation-v4-5-5cbf5b28afd5@pks.im/)した[Patrick Steinhardt](https://gitlab.com/pks-gitlab)に感謝します。\n\n## libgitに対するRustバインディング\n\nGitをコンパイルすると、内部ライブラリ`libgit.a`が生成されます。このライブラリには、Gitの中核となる機能の一部が含まれています。\n\nこのライブラリ（およびGitの大部分）はC言語で書かれていますが、Git 2.49では一部の関数をRustから使えるようにするためのバインディングが追加されました。この実現のために、2つの新しいCargoパッケージ、`libgit-sys`と`libgit-rs`が作成されました。これらのパッケージは、GitのSourceTree内の[`contrib/`](https://gitlab.com/gitlab-org/git/-/tree/master/contrib)サブディレクトリに配置されています。\n\n[他言語関数インターフェイス](https://ja.wikipedia.org/wiki/Foreign_function_interface)を使う場合、ライブラリを2つのパッケージに分けるのは[一般的](https://doc.rust-lang.org/cargo/reference/build-scripts.html#-sys-packages)な手法です。\n`libgit-sys`パッケージは、C関数への純粋なインターフェースを提供し、ネイティブの`libgit.a`にリンクします。一方、`libgit-rs`パッケージは、`libgit-sys`の関数をRustらしいスタイルで扱える高レベルなインターフェースを提供します。\n\n現時点では、これらのRustパッケージで使える機能は非常に限定的で、対応しているのは`git-config(1)`とやり取りするためのインターフェースのみです。\n\nこの取り組みは[Josh Steadmon](https://lore.kernel.org/git/8793ff64a7f6c4c04dd03b71162a85849feda944.1738187176.git.steadmon@google.com/)さんによって主導され、コミット[a4af0b6288](https://gitlab.com/gitlab-org/git/-/commit/a4af0b6288e25eb327ae9018cee09def9e43f1cd)でマージされました。\n\n## 新しい名前ハッシュアルゴリズム\n\n`.git/`にあるGitのオブジェクトデータベースは、その大部分のデータを パックファイルに保存しています。また、このパックファイルは、Gitのサーバーとクライアント間でオブジェクトをやり取りする際にも使われます。\n\nパックファイルのフォーマットについては、[`gitformat-pack(5)`](https://git-scm.com/docs/gitformat-pack)に詳しく書かれていますが、その中でも重要なのが差分圧縮です。差分圧縮では、すべてのオブジェクトがそのまま保存されるわけではなく、一部のオブジェクトは他のオブジェクトとの_差分_として保存されます。つまり、オブジェクトの内容全体を保存するのではなく、他のオブジェクトと比較した変更点だけを記録します。\n\n差分の計算や保存方法についてはここでは詳しく触れませんが、\n非常に似ているファイルをグループ化しておくことが重要なのは想像できるかと思います。Git v2.48以前では、Gitは「ファイルパスの最後の16文字」をもとに、blobが似ているかどうかを判断していました。このアルゴリズムはバージョン`1`と呼ばれています。\n\nGit 2.49では、バージョン`2`のアルゴリズムが追加されました。これはバージョン`1`のイテレーションで、親ディレクトリの影響を減らすように調整されたバージョンです。どちらのアルゴリズムを使用するかは、[`git-repack(1)`](https://git-scm.com/docs/git-repack)の`--name-hash-version`オプションで指定できます。\n\n以下は、このプロジェクトを推進した[Derrick Stolee](https://stolee.dev/)さんによる、`git repack -adf --name-hash-version=\u003Cn>`を実行した際のパックファイルサイズの比較です。\n\n| リポジトリ                                          \t| バージョン1のサイズ   | バージョン2のサイズ |\n|---------------------------------------------------|-----------|---------|\n| [fluentui](https://github.com/microsoft/fluentui) | 440 MB \t| 161 MB   |\n| Repo B                                        \t| 6,248 MB   | 856 MB   |\n| Repo C                                        \t| 37,278 MB  | 6,921 MB |\n| Repo D                                        \t| 131,204 MB | 7,463 MB |\n\nこの件に関する詳細は、コミット[aae91a86fb](https://gitlab.com/gitlab-org/git/-/commit/aae91a86fb2a71ff89a71b63ccec3a947b26ca51)にマージされた[パッチセット](https://lore.kernel.org/git/pull.1823.v4.git.1738004554.gitgitgadget@gmail.com/)にて確認できます。\n\n## プロミサーリモート機能\n\nGitが大きなファイルを扱うのに向いていないことは、よく知られています。この問題に対する解決策として、[Git LFS](https://git-lfs.com/)のようなツールがありますが、依然として以下のような欠点が残っています。\n\n- Git LFSでは、どのファイルをLFSに入れるかをユーザーが自分で設定する必要があり、サーバー側ではそれについて制御できず、すべてのファイルを提供する必要があります。\n- リポジトリにファイルがコミットされると、履歴を書き換えない限り、それを取り除く方法がありません。これは特に大きなファイルでは厄介で、一度入れると永遠に残ってしまいます。\n- ユーザーは、Git LFSに入れるファイルを後から変更することはできません。\n- Git LFS のようなツールは、導入・学習・運用すべてにそれなりの労力が必要です。\n\n以前からGitにはプロミサーリモートという概念が存在しており、この機能を大きなファイルに対処するための手段として利用できます。そしてGit 2.49では、この機能がさらに一歩前進しました。\n\n新しい「プロミサーリモート」機能の考え方は比較的シンプルです。Gitサーバーがすべてのオブジェクトを自ら送信する代わりに、「これらのオブジェクトは_XYZ_からダウンロードしてね」とGitクライアントに伝えます。この_XYZ_がプロミサーリモートです。\n\nGit 2.49では、サーバーがプロミサーリモートの情報をクライアントに通知できるようになりました。この変更は、[`gitprotocol-v2`](https://git-scm.com/docs/gitprotocol-v2)の拡張として行われています。サーバーとクライアントがデータを送受信している間に、サーバーは自分が知っているプロミサーリモートの名前やURLをクライアントに送信します。\n\n現時点では、Gitクライアントはクローン時にサーバーから受け取ったプロミサーリモートの情報をまだ利用していません。つまり、今のところは、クローン元のリモートからすべてのオブジェクトを取得しています。しかし今後は、サーバーから受け取ったプロミサーリモート情報を活用できるように開発を進め、より簡単に使える仕組みにしていく予定です。\n\nこの[パッチセット](https://lore.kernel.org/git/20250218113204.2847463-1-christian.couder@gmail.com/)は[Christian Couder](https://gitlab.com/chriscool)さんによって提出され、コミット[2c6fd30198](https://gitlab.com/gitlab-org/git/-/commit/2c6fd30198187c928cbf927802556908c381799c)でマージされました。\n\n## `--revision`を使用した軽量なクローン\n\n[`git-clone(1)`](https://git-scm.com/docs/git-clone)に新しく`--revision`オプションが追加されました。このオプションを使うことで、指定されたリビジョンの履歴のみを含む、軽量なクローンを作成できます。このオプションは`--branch`に似ていますが、`refs/heads/main`、`refs/tags/v1.0`、`refs/merge-requests/123`のような リファレンス名や、16進数のコミットオブジェクトIDを受け取る点が異なります。`--branch`との違いは、このオプションでは追跡ブランチが作られず、`HEAD`がデタッチ状態になる点です。そのため、このクローンを使ってブランチにコントリビュートするといった用途には向いていません。\n\n`--revision`と`--depth`を組み合わせて使うことで、非常にミニマルなクローンを作成できます。おすすめの用途は、自動テストです。たとえば、CIシステムが特定のブランチ（またはリファレンス）をチェックアウトして、ソースコードのテストを行うだけでいい場合、この最小限のクローンで十分です。\n\nこの[変更](https://gitlab.com/gitlab-org/git/-/commit/5785d9143bcb3ef19452a83bc2e870ff3d5ed95a)は[Toon Claes](https://gitlab.com/toon)さんによって[推進](https://lore.kernel.org/git/20250206-toon-clone-refs-v7-0-4622b7392202@iotcl.com/)されました。\n\n# もっと詳しく\n- [Git 2.48.0の新機能](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-48-0/)\n- [Git 2.47.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-47-0/)\n- [Git 2.46.0の新機能](https://about.gitlab.com/blog/whats-new-in-git-2-46-0/)",[269,677,9],{"slug":1008,"featured":90,"template":680},"whats-new-in-git-2-49-0","content:ja-jp:blog:whats-new-in-git-2-49-0.yml","Whats New In Git 2 49 0","ja-jp/blog/whats-new-in-git-2-49-0.yml","ja-jp/blog/whats-new-in-git-2-49-0",{"_path":1014,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1015,"content":1021,"config":1028,"_id":1030,"_type":13,"title":1031,"_source":15,"_file":1032,"_stem":1033,"_extension":18},"/ja-jp/blog/a-beginners-guide-to-the-git-reftable-format",{"title":1016,"description":1017,"ogTitle":1016,"ogDescription":1017,"noIndex":6,"ogImage":1018,"ogUrl":1019,"ogSiteName":667,"ogType":668,"canonicalUrls":1019,"schema":1020},"初心者向けGit reftableフォーマットガイド","Git 2.45.0では、GitLabがreftableバックエンドをGitに取り込んだことで、参照の保存方法が完全に変更されました。この新しいフォーマットの内部の仕組みを詳しく見てみましょう。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664595/Blog/Hero%20Images/blog-image-template-1800x945__9_.png","https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"初心者向けGit reftableフォーマットガイド\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2024-05-30\",\n      }",{"title":1016,"description":1017,"authors":1022,"heroImage":1018,"date":1023,"body":1024,"category":675,"tags":1025,"updatedDate":1027},[672],"2024-05-30","最近まで、Gitでの参照の保存方法は、「files」フォーマットだけに限られていましたが、[Git 2.45.0の新機能](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-45-0/)により、Gitでは参照を「reftable」フォーマットで保存できるようになりました。この新しいフォーマットは、バイナリフォーマットで非常に複雑ですが、その複雑さが「files」フォーマットのいくつかの欠点を解決します。「reftable」フォーマットは、次のような目的で設計されました。\n\n- 単一の参照の検索と参照範囲のイテレーションを、可能な限り効率的かつ迅速に行えるようにする。\n- 複数の参照が部分的にしか更新されていない中途半端な状態をGitが読み取らないように、一貫した参照の読み取りをサポートする。\n- 複数の参照の更新がオールオアナッシング型のオペレーションとして実行される、アトミック書き込みをサポートする。\n- 参照および参照ログの効率的な保存。\n\nこの記事では、「reftable」フォーマットの仕組みを詳しく見ていきます。\n\n## Gitでの参照の保存方法\n\n「reftable」フォーマットについて詳しく掘り下げる前に、まずはGitがこれまで参照をどのように保存してきたのかを簡単に振り返ってみましょう。すでにご存知の方は、このセクションを読み飛ばして構いません。\n\nGitリポジトリは、次の重要な2つのデータ構造を追跡します。\n\n- [オブジェクト](https://git-scm.com/book/en/v2/Git-Internals-Git-Objects)：リポジトリの実際のデータ（コミット、ディレクトリツリー構造、ソースコードを含むblobなど）を格納しています。オブジェクトは互いに参照し合い、オブジェクトグラフを形成します。さらに、各オブジェクトにはオブジェクトIDがあり、そのオブジェクトを一意に識別します。\n\n- 参照：ブランチやタグなどがあります。これらはオブジェクトグラフへのポインタであり、オブジェクトに覚えやすい名前を付けたり、開発履歴の異なるトラックを追跡するのに使われます。たとえば、リポジトリには`main`ブランチが含まれている場合があり、これは特定のコミットを指し示す`refs/heads/main`という名前の参照です。\n\n参照は、参照データベースに保存されます。Git 2.45.0までは、「files」データベースフォーマットのみが存在していました。このフォーマットでは、各参照が通常のファイルとして保存され、そのファイルには次のいずれかが含まれます。\n\n- 通常の参照：指し示すコミットのオブジェクトIDが保存されています。\n- シンボリック参照：別の参照の名前が保存されています。これは、シンボリックリンクが別のファイルを指し示すのと似ています。\n\n定期的に、これらの参照は検索を効率化するために1つのpacked-refsファイルにまとめられます。\n\n次の例は、「files」フォーマットがどのように動作するかを示しています。\n\n```shell\n$ git init .\n$ git commit --allow-empty --message \"Initial commit\"\n[main (root-commit) 6917c17] Initial commit\n\n# HEADはrefs/heads/mainを指すシンボリック参照です。\n$ cat .git/HEAD\nref: refs/heads/main\n\n# refs/heads/mainはコミットを指す通常の参照です。\n$ cat .git/refs/heads/main\n6917c178cfc3c50215a82cf959204e9934af24c8\n\n# git-pack-refs(1)はこれらの参照をpacked-refsファイルにパック化します。\n$ git pack-refs --all\n$ cat .git/packed-refs\n# pack-refs with: peeled fully-peeled sorted\n```\n\n## reftableフォーマットの構造概要\n\nGit 2.45.0以降がインストールされている場合、`--ref-format=reftable`スイッチを使用して「reftable」フォーマットでリポジトリを作成できます。\n\n```shell\n$ git init --ref-format=reftable .\nInitialized empty Git repository in /tmp/repo/.git/\n$ git rev-parse --show-ref-format\nreftable\n\n# わかりやすくするために不要なファイルを削除しています。\n$ tree .git\n.git\n├── config\n├── HEAD\n├── index\n├── objects\n├── refs\n│   └── heads\n└── reftable\n\t├── 0x000000000001-0x000000000002-40a482a9.ref\n\t└── tables.list\n\n4 directories, 6 files\n```\n\nまず、リポジトリの設定を見ると、それには`extension.refstorage`キーがあります。\n\n```shell\n$ cat .git/config\n[core]\n    repositoryformatversion = 1\n    filemode = true\n    bare = false\n    logallrefupdates = true\n[extensions]\n    refstorage = reftable\n```\n\nこの設定は、リポジトリが「reftable」フォーマットで初期化されており、「reftable」バックエンドを使用してアクセスするようGitに指示するものです。\n\n不思議なことに、このリポジトリにはまだ「files」バックエンドが使われているかのように見えるいくつかのファイルがあります。\n\n- `HEAD`は通常、現在チェックアウト済みのブランチを指すシンボリック参照です。「reftable」バックエンドでは使用されませんが、GitクライアントがディレクトリをGitリポジトリとして検出するために必要です。したがって、「reftable」フォーマットを使用する場合、`HEAD`は`ref: refs/heads/.invalid`という内容のスタブになります。\n\n- `refs/heads`は、`this repository uses the reftable format`という内容が書かれているファイルです。「reftable」フォーマットを認識できないGitクライアントは、このパスがディレクトリであると想定します。したがって、このパスをファイルとして作成することで、古いGitクライアントが「files」バックエンドでリポジトリにアクセスしようとすると、意図的に失敗するようになります。\n\n実際の参照は、次のように`reftable/`ディレクトリに保存されます。\n\n```shell\n$ tree .git/reftable\n.git/reftable/\n├── 0x000000000001-0x000000000001-794bd722.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000001-794bd722.ref\n```\n\nここには、次の2つのファイルがあります。\n\n- `0x000000000001-0x000000000001-794bd722.ref`は、参照と参照ログデータをバイナリフォーマットで含むテーブルです。\n\n- `tables.list`は、テーブルのリストです。リポジトリの現在の状態では、このファイルにはテーブルの名前の1行だけが含まれています。このファイルは「reftable」データベースにある現在有効なテーブルをまとめて追跡し、新しいテーブルがリポジトリに追加されるたびに更新されます。\n\n次のように、参照を更新すると、新しいテーブルが作成されます。\n\n```shell\n$ git commit --allow-empty --message \"Initial commit\"\n[main (root-commit) 1472a58] Initial commit\n\n$ tree .git/reftable\n.git/reftable/\n├── 0x000000000001-0x000000000002-eb87d12b.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000002-eb87d12b.ref\n```\n\nご覧のとおり、以前のテーブルは新しいテーブルに置き換えられました。さらに、`tables.list`ファイルが更新され、新しいテーブルが取り込まれました。\n\n## テーブルの構造\n\n前述のとおり、参照データベースの実際のデータはテーブルに含まれています。テーブルは大まかに次のような複数のセクションに分かれています。\n\n- header：テーブルに関するメタデータが含まれています。これには、フォーマットのバージョン、ブロックサイズ、およびリポジトリで使用されるハッシュ関数（SHA1、SHA256など）が、他の情報と一緒に含まれています。\n- ref：参照が含まれています。これらのレコードは参照名と等しいキーを有し、通常の参照の場合はオブジェクトIDを、シンボリック参照の場合は他の参照を指します。\n- obj：オブジェクトIDからそれらのオブジェクトIDを指す参照への逆マッピングが含まれています。これにより、Gitは特定のオブジェクトIDを指す参照を効率的に検索できます。\n- log：参照ログエントリが含まれています。これらのレコードは、参照名にログエントリの番号を表すインデックスを付け足したものと等しいキーを有し、 さらに、古いオブジェクトIDと新しいオブジェクトID、およびその参照ログエントリのメッセージを含みます。\n- footer：各セクションへのオフセットが含まれます。\n\n![すべてのreftableセクションを含んだ縦長の表](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_1_-_Reftable_overview.svg)\n\n各セクションのタイプは、似たような構造を持っています。セクションには一連のレコードが含まれており、各レコードのキーでソートされています。たとえば、 `refs/heads/aaaaa`と `refs/heads/bbb`という2つの参照レコードがある場合、これらの参照名がそれぞれのキーとなり、`refs/heads/aaaaa`が`refs/heads/bbb`よりも前に来ます。\n\nさらに、各セクションは固定長のブロックに分割されています。このブロックの長さはヘッダー（header）にエンコードされており、次の2つの目的を果たします。\n\n- セクションの開始位置とブロックサイズに基づき、リーダー（reader）は各ブロックの開始位置を暗に認識します。これにより、Gitは先行するブロックを読み込むことなくセクションの途中に簡単に移動できるため、ブロック上でのバイナリ検索が可能になり、レコードの検索を高速化します。\n- 一度に読み込むディスクデータの量をリーダーが認識できるようにします。このために、ブロックサイズはデフォルトで4KiBに設定されており、これはハードディスクのセクターサイズとしては最も一般的です。最大ブロックサイズは16MBです。\n\nたとえば、「ref」セクションを覗いてみると、おおよそ次の図のようになります。ここで留意すべき点は、レコードがブロック内で、そしてブロック間の両方で辞書順に並んでいることです。\n\n![未圧縮参照ブロック](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_2_-_Ref_block_uncompressed.svg)\n\n現在の情報を基に、次の手順でレコードを検索できます。\n\n1. 各ブロックの最初のレコードのキーを確認してバイナリ検索を行い、目的のレコードが含まれているブロックを特定します。\n\n2. 特定したブロック内で線形検索を行い、目的のレコードを特定します。\n\nこの手順はまだ少し非効率です。多くのブロックがある場合、目的のブロックを特定するためにバイナリ検索で対数的に多くのブロックを読み込むことが必要になる場合があります。また、ブロックに多数のレコードが含まれている場合、線形検索中にすべてのレコードの読み込みが必要になる可能性もあります。\n\n「reftable」フォーマットには、これらのパフォーマンス問題に対処する追加のメカニズムが組み込まれています。後のセクションでこれらについて詳しく説明します。\n\n### プレフィックス圧縮\n\nお気づきかもしれませんが、すべてのレコードキーには`refs/`という共通のプレフィックスがあります。これはGitでは一般的です。\n\n- すべてのブランチは`refs/heads/`で始まります。\n- すべてのタグは`refs/tags /`で始まります。\n\nしたがって、後続のレコードもキーの大部分で共通のプレフィックスを持つことが予想されます。これを利用して、貴重なディスク容量を節約できます。ほとんどのキーが共通のプレフィックスを持つことがわかっているため、これを最適化するのは理にかなっています。\n\nこの最適化にはプレフィックス圧縮を使用します。各レコードは、前のレコードのキーから何バイトを再利用するかを示すプレフィックスの長さがエンコードされています。たとえば、`refs/heads/a`と`refs/heads/b`という2つのレコードがある場合、後者はプレフィックスの長さを11バイトとしてエンコードし、サフィックスとして`b`だけを保存します。その後、リーダーは`refs/heads/a`の最初の11バイト（`refs/heads/`）を取得し、サフィックス`b`を追加します。\n\n![プレフィックス圧縮](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_3_-_Ref_block_prefix_compression.svg)\n\n### 再起点\n\n前述のように、現在の「reftable」フォーマットの理解に基づいてブロック内の参照を検索する最適な方法は、線形検索です。これは、レコードが固定長ではないため、ブロックの先頭からスキャンしないとレコードの開始位置を特定できないためです。また、レコードが固定長であったとしても、レフィックス圧縮があるため、先行するレコードを読み込む必要があり、ブロックの途中に直接移動はできません。 \n\nしかし、ブロックには数百から数千のレコードが含まれる可能性があり、線形検索は非常に非効率です。この問題に対処するために、「reftable」フォーマットは各ブロックに「再起点」と呼ばれるポイントをエンコードします。再起点は圧縮されていないレコードであり、ここではプレフィックス圧縮がリセットされます。したがって、再起点のレコードは常に完全なキーを含んでおり、先行するレコードをスキップしながら直接移動してレコードを読み込むことが可能になります。これらの再起点は各ブロックのフッターにリストされています。\n\nこの情報を用いることで、ブロック全体を線形検索する必要がなくなります。代わりに、再起点のバイナリ検索を行い、目的のキーより大きい最初の再起点を探します。そこから、目的のレコードが_前の_再起点から特定された再起点までのセクションに存在することがわかります。\n\nしたがって、レコードを検索する最初の手順（ブロックのバイナリ検索、レコードの線形検索）は次のようになります。\n\n1. ブロックのバイナリ検索を行い、目的のレコードが含まれるブロックを特定します。\n\n2. 再起点のバイナリ検索を行い、目的のレコードが含まれるブロックのサブセクションを特定します。\n\n3. 特定したサブセクション内でレコードの線形検索を行います。\n\n![レコードの線形検索](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_4_-_Restart_points.svg)\n\n### インデックス\n\nブロック内のレコードの検索はかなり効率化されましたが、ブロック自体の位置を特定するのはまだ効率的とはいえません。数個のブロックであればバイナリ検索でも十分に効率的です。しかし、数百万もの参照を含むリポジトリには数百から数千のブロックが存在します。この場合、追加のデータ構造がなければ、平均して対数的に多くのディスクアクセスが必要になります。\n\nこの問題を避けるために、各セクションの後にブロックを効率的に検索するためのインデックスセクションを追加できます。各インデックスレコードには次の情報が含まれます。\n\n- インデックス化されているブロックの位置。\n- インデックス化されているブロックの最後のレコードのキー。\n\n3つ以下のブロックであれば、バイナリ検索は最大2回のディスク読み取りで目的のブロックを特定できます。この読み取り回数は、インデックスを使用する場合も同じです。具体的には、インデックス自体を読み取るための1回と、目的のブロックを読む取るための1回です。したがって、インデックスは実際に読み取り回数を減らす場合、つまりインデックス化されたブロックが4つ以上ある場合にのみ作成されます。\n\n次の疑問は、インデックス自体が複数のブロックにまたがるほど大きくなった場合はどうすべきかという点です。その答えは、そのインデックスをインデックス化するために別のインデックスを作成するというものです。この複数階層のインデックスは、数十万もの参照があるリポジトリでのみ必要となります。\n\n次のインデックスを使用することで、レコードの検索手順をさらに効率化できます。\n1. テーブルのフッターを見てインデックスがあるかどうかを確認します。\n\t- インデックスがあれば、バイナリ検索を行い、目的のブロックを特定します。このブロックがインデックスブロック自体を指している場合は、目的のレコードタイプに到達するまでこの手順を繰り返します。\n\t- インデックスがなければ、先ほどのようにブロックのバイナリ検索を行います。\n2. 再起点のバイナリ検索を行い、目的のレコードが含まれているブロックのサブセクションを特定します。\n3. 特定したサブセクション内でレコードの線形検索を行います。\n\n## 複数のテーブル\n\nここまでは、単一のテーブルを読み取る方法について説明してきましたが、`tables.list`という名前が示すように、「reftable」データベースには複数のテーブルを格納できます。\n\nリポジトリ内の参照を更新するたびに、新しいテーブルが作成され、`tables.list`に追加されます。したがって、最終的には次のように複数のテーブルが存在することになります。\n\n```shell\n$ tree .git/reftable/\n.git/reftable/\n├── 0x000000000001-0x000000000007-8dcd8a77.ref\n├── 0x000000000008-0x000000000008-30e0f6f6.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000007-8dcd8a77.ref\n0x000000000008-0x000000000008-30e0f6f6.ref\n```\n\nリポジトリの実際の状態を読み取るためには、これらの複数のテーブルを単一の仮想テーブルにマージする必要があります。\n\nここで疑問が生じます。それは、参照が更新されるたびにテーブルが作成され、同じ参照が複数回更新される場合、「reftable」フォーマットは特定の参照の最新の値をどのように把握するのか、ということです。直感的には、最新のテーブルに含まれる参照の値が最新であると仮定できます。\n\n実際には、各レコードには「更新インデックス」と呼ばれるものがあり、これがレコードの「優先度」をエンコードしています。たとえば、同じ名前の2つの参照レコードが存在する場合、更新インデックスが高い方が低い方を上書きします。\n\nこれらの更新インデックスは、上のファイル構造で確認できます。長い16進文字列（例：`0x000000000001`）が更新インデックスであり、テーブル名の左側がテーブルに含まれる最小の更新インデックス、そして右側が最大の更新インデックスを示しています。\n\nテーブルのマージは、参照レコードのキーと更新インデックスによって順序付けられた[優先キュー](https://en.wikipedia.org/wiki/Priority_queue)を介して行われます。すべての参照レコードをスキャンする場合、次の手順で行います。\n\n1. 各テーブルの最初のレコードを優先キューに追加します。\n\n![優先キューに最初のレコードを追加する](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_5_-_Priority_queue_1.svg)\n\n2. 優先キューの先頭を取り出します。このキューは更新インデックス順に並んでいるため、先頭にあるレコードは最新のバージョンでなければなりません。そのテーブルの次の項目を優先キューに追加します。\n\n![優先キューの先頭を取り出す](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_6_-_Priority_queue_2.svg)\n\n3. 同じ名前を持つすべてのレコードをキューから削除します。これらのレコードは上書きされているため表示されません。レコードを削除した各テーブルについては、その次のレコードを優先キューに追加します。\n\n![同じ名前を持つすべてのレコードをキューから削除する](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_7_-_Priority_queue_3.svg)\n\nこれを繰り返して、他のキーのレコードを読み取ります。\n\nテーブルには、レコードが削除されたことを示す特殊な「トゥームストーン」レコードが含まれている場合があります。このように、すべてのテーブルを書き換えることなく、レコードを削除できます。\n\n### 自動圧縮\n\n優先キューの考え方はシンプルですが、このアプローチでは、マージするテーブルの数が数百個、あるいは数十個であっても、非常に非効率になります。参照を更新するたびに新しいテーブルが`tables.list`ファイルに付加されるのは事実ですが、他にも重要な特徴があります。\n\nそれが、自動圧縮です。新しいテーブルがテーブルリストに付加された後、「reftable」バックエンドは一部のテーブルをマージする必要があるかどうかを確認します。これは、シンプルなルールを使って行われます。具体的には、テーブルのリストがファイルサイズの[幾何数列](https://en.wikipedia.org/wiki/Geometric_progression)を形成しているかどうかをチェックします。すべてのテーブル`n`は、その次に新しいテーブル`n+1`の2倍以上のサイズでなければなりません。この幾何数列が維持されなかった場合、バックエンドはテーブルを圧縮して幾何数列を復元します。\n\n時間が経つにつれて、次のような構造になります。\n\n```shell\n$ du --apparent-size .git/reftable/*\n429    .git/reftable/0x000000000001-0x00000000bd7c-d9819000.ref\n101    .git/reftable/0x00000000bd7d-0x00000000c5ac-c34b88a4.ref\n32    .git/reftable/0x00000000c5ad-0x00000000cc6c-60391f53.ref\n8    .git/reftable/0x00000000cc6d-0x00000000cdc1-61c30db1.ref\n3    .git/reftable/0x00000000cdc2-0x00000000ce67-d9b55a96.ref\n1    .git/reftable/0x00000000ce68-0x00000000ce6b-44721696.ref\n1    .git/reftable/tables.list\n```\n\nすべてのテーブルにおいて、`size(n) > size(n+1) * 2`という性質が維持されていることに注目してください。\n\n自動圧縮がもたらすメリットのひとつは、「reftable」バックエンドのメンテナンスが自動化されることです。これにより、リポジトリで`git pack-refs`を実行する必要がなくなります。\n\n## さらに詳しく知りたい方へ\n\nこの記事では、新しい「reftable」フォーマットの仕組みについて解説しました。さらに詳しく知りたい場合は、Gitプロジェクトで提供される[テクニカルドキュメント](https://git-scm.com/docs/reftable)をご参照ください。\n\n> [Git 2.45.0の新機能](https://about.gitlab.com/ja-jp/blog/whats-new-in-git-2-45-0/)では、このバージョンにおけるその他の変更点をご確認いただけます。\n\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)\u003Cbr>\n（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*\n",[9,701,677,1026],"performance","2025-02-04",{"slug":1029,"featured":90,"template":680},"a-beginners-guide-to-the-git-reftable-format","content:ja-jp:blog:a-beginners-guide-to-the-git-reftable-format.yml","A Beginners Guide To The Git Reftable Format","ja-jp/blog/a-beginners-guide-to-the-git-reftable-format.yml","ja-jp/blog/a-beginners-guide-to-the-git-reftable-format",2,[660,685,709,730,749,771,791,819,839],1759347863994]