Git チーム

ミッションステートメント

Git チームは、Git バージョン管理システムの構築、保守、および専門知識の提供に責任を持ちます。主な責任は次のとおりです:

Git バージョン管理システムのアップストリーム開発。
GitLab の他のチームへの専門知識の提供。
Git コミュニティの育成。
Git プロジェクトの長期的な実行可能性の確保。

アップストリーム開発

Git チームは、コミュニティの目標に従い、他のチームから提起された GitLab 固有のニーズに対応するために、Git のアップストリーム開発を推進する責任があります。これは次の幅広いカテゴリに分類されます:

GitLab のユースケースが必要とする新しいツールの形での新機能の実装。
最適化と新しいデータフォーマットの形でのスケーラビリティ改善。
開発者の最初の選択肢として Git が選ばれ続けるように、Git の使いやすさの改善。
Git コードベースのメンテナンス。

専門知識の提供

Git バージョン管理システムは GitLab が行っていることの中核であり、GitLab 全体の多くのチームにとって非常に重要です。これにはエンジニアリング部門の一部であるチームだけでなく、例えばサポートなど他の部門にも及びます。Git チームはそのようなチームの主な連絡先であり、Git を効果的かつ効率的に使用する方法についての専門知識を提供します。以下の非網羅的なトピックについての洞察を提供します:

特定のユースケースを Git でどのように実装できるか？
特定のワークロードのパフォーマンスをどのように改善するか？
Git の特定の機能をお客様にどのように公開するか？
Git コミュニティで何が起こっており、プロジェクトはどの方向に向かっているか？
Git ユーザーの間でどの Git 関連のワークフローと慣行を奨励すべきか？

Git コミュニティの育成

GitLab は Git コミュニティが健全であることに依存しています。健全なコミュニティとは、直接の競合他社も含む多様な視点を持つコミュニティであると私たちは考えています。Git チームは Git コミュニティを育成・成長させる手助けをします:

Google Summer of Code や Outreachy などのメンターシッププログラムを通じて新しい貢献者の流入を確保する。
新しい貢献者向けの Git ドキュメントと資料を改善する。
ユーザーグループや Git Merge などのコミュニティ指向のイベントに参加またはホストする。
ガイダンスを提供しレビューを行うことでコミュニティメンバーを支援する。
ブログポストや Git Rev News などの形で情報を広める。

長期的な実行可能性

Git プロジェクトはこの執筆時点でほぼ 20 年間有機的に成長してきました。そのため、プロジェクト自体が長期的に実行可能であり続けるために何らかの形で対処する必要があるさまざまな形の負債を蓄積してきました。これには次のようなトピックが含まれます:

技術的負債を削減するための Git コードベースのメンテナンスとリファクタリング。
テックスタックの一部の近代化。
Git の使いやすさの改善。
機能の非推奨と削除。

ロードマップ

公開されている Gitaly の製品方向性をご覧ください。

現在のロードマップはこの Epic ボードです。

チーム

責任 | 製品階層内での位置

チームメンバー情報は原文 (英語) を参照してください。

チームへのお問い合わせ方法

他のチームやお客様が必要とするときは喜んでお手伝いします。ただし、私たちは主に_開発_チームであり、「フィールドエンジニアリング」に対応できるわけではありません。

私たちの_エンジニア_は、Git 固有のユースケースとデータに基づいた深い技術調査と、サポート、CSM、Gitaly などの Git の直接ユーザーとの密接なパートナーシップによる技術的なコラボレーションについて、できれば非同期で支援できます。

エンジニアリングマネージャー（@pks-gitlab）と_プロダクトマネージャー_（@mjwood）は、ロードマップ、機能、タイムラインの明確化が必要な場合や、正しい優先順位付けを確保するためにお客様と関わることも喜んでいます。

ただし、以下の場合は適切ではありません:

他のチームによる Git の使用方法についてのガイダンス。_どのように_統合するかについての専門知識を提供できますが、_実際の_統合は私たちの範囲外です。
セルフホスト環境でのワークフローとインスタンス設定またはアーキテクチャに関するアドバイス（リファレンスアーキテクチャとプロフェッショナルサービスが対応できます）
明確な終了基準のない関与。まず明確にしてください。「話し合うために電話しましょう」は通常このカテゴリに該当します。
長期的な「アドバイスをください」シナリオ。サポートとドキュメントを参照するか、プロフェッショナルサービスをご利用ください。

Git オフィスアワー

チームは GitLab 内部向けの Git オフィスアワーを定期的にホストしています。このイベントは Gitaly チームのカレンダーに含まれており、事前にアナウンスされ、通常は水曜日の UTC 午後 2 時 30 分に開催されます。

これらのオフィスアワーは主に Git チームでのアップストリーム開発について議論するために使用されますが、Git コミュニティで何が起こっているかを学びたい Git チーム外の人々の参加も歓迎しています。

この場を利用して特定の問題についてのガイダンスを求めることができます:

製品への Git の統合方法についてのフィードバックとガイダンスを求める。
お客様が経験するような興味深いエッジケースについてディスカッションする。
Git の機能についてのフィードバックを提供する。

これは日常的に Git を使用する方法に関する一般的なサポートフォーラムとして意図されていないことに注意してください。そのような質問をする場合は #git-help のほうが適切なチャンネルです。

上記のアジェンダにトピックを追加して参加してください。

バグ、機能、パフォーマンス

Git チームに何かを取り組んでもらうには、GitLab 固有の Git Issue トラッカーで Issue を作成し、group::git と workflow::problem validation ラベル、およびその他の適切なラベルを追加するのが最善です。その後、上記にリストされている関連するプロダクトマネージャーおよび/またはエンジニアリングマネージャーをタグ付けしてください。

情報リクエストやその他の簡単な一回限りのことについては、Issue に注意を向けるために Slack の #g_git を気軽にご利用ください。

緊急 Issue と停止

サポート組織の一員でない場合は、まずサポートに助けを求めることを検討してください。サポートはより良いアベイラビリティを持ち、ほとんどの一般的なケースで対応できます。

それでも助けが必要な場合は、ここで Issue を提起してください。即座の可視性のために #g_git に投稿し、EM と PM、および一緒に作業しているサポート担当者をタグ付けしてください。

オンコールローテーション

Git チームのメンバーは Gitaly のオンコールローテーションに参加しています。詳細については、チームページをご覧ください。

アップストリーム Git でのワークフロー

Git プロジェクトはアップストリームプロジェクトであるため、異なるワークフローを使用する必要があります。

プランニング

Git プロジェクトは、おおよそ 3 ヶ月ごとに新しいリリースが公開される異なるリリーススケジュールを持っています。スケジュールは Git プロジェクトのカレンダーで確認できます。さらに、ほとんどのトピックは開発とアップストリームへのマージの両方においてかなり長い時間がかかることが予想されます。その結果、通常のマイルストーンはアップストリーム Issue のコンテキストでの目標 GitLab バージョンを適切に追跡するための良いメカニズムではありません。

代わりに、オープンな Issue の目標 Git バージョンや完了した Issue で実際にランディングしたバージョンにアノテーションを付けるために git-milestone::v2.42 のようなラベルを使用します。これらのマイルストーンラベルは通常のマイルストーンに加えて適用されます。

これは、マイルストーンを Gitaly チームメンバーによる作業の実装をスケジュールするための時間枠として割り当てることを意味しますが、これは Git プロジェクトによって作業がリリースされる時間枠とは対応しません。その意味は、Git Issue が通常の Issue ボードに引き続き表示され、すぐに発見できるようにするための計画ツールに縮小されます。結果として、新しい作業を選ぶ通常の方法が Git Issue にも適用されます。

通常のレビュープロセスとの違い

アップストリームの Git プロジェクトで作業する場合、私たちは依然として開発者が Issue をトピックブランチで実装し、マージリクエストを作成し、通常通りレビュワーを割り当てるシンプルなワークフローを使用します。Issue とマージリクエストは Git プロジェクトのミラーで作成される必要があります。ただし、変更はアップストリームのレビューを受ける必要があるため、ワークフローは通常のワークフローと異なります

変更はオプションで内部レビューを受けることができます。
オプションの内部レビューの後、パッチは Git メーリングリストに送信されます。

マージリクエストの意味は、純粋に情報提供に縮小されます。

開発者は、オプションの内部レビューをスキップして、パッチをメーリングリストに直接送ることを奨励されています。その場合、https://public-inbox.org/git/ のメーリングリストのスレッドへのリンクをマージリクエストにコメントとして追加する必要があります。レビューはメーリングリストで直接行われるべきです。

開発者がメーリングリストに直接パッチを送ることを奨励することには複数の利点があります:

レビュワーは Git メーリングリストに触れることができます。これは、自分たちのレビューが可視になる一方で、より幅広い Git コミュニティに GitLab で Git に取り組んでいるチーム全体がいることを示し、レビュワーの信頼性を高めます。
そうでなければあまり注目されないトピックが、私たち自身のレビューが可視になることでより多くの注目を集めるかもしれません。
2 つの連続したレビューを行う必要がなくなり、そうでなければトピックをさらに遅延させることになります。

オプションの内部レビューは、特に新しい内部貢献者を念頭に置いています。参入のハードルを下げ、より幅広い Git コミュニティへの露出がもたらす不快感のレベルを低下させるのに役立てるべきです。同じ精神で、レビュワーはレビューコメントを最初に内部で投稿してから Git メーリングリストに送ることができます。最終的に、目標はこれらの新しい貢献者を社内でメンタリングして、最終的に Git メーリングリストに直接投稿するようになることです。

以下は内部レビューを好む例外の非網羅的なリストです:

セキュリティ Issue は非公開セキュリティミラーで実装されます。
私たち自身のユースケースに提案されたソリューションが対応しているかどうかを評価する必要がある潜在的に議論を呼ぶトピック。

長期実行トピック

単一リリースで変更をランディングすることが実現不可能な場合に、長期実行トピックで協力する必要がある場合があります。私たちの通常のイテレーション的な開発アプローチは、Git プロジェクト内では常にうまく機能するわけではありません。最も重要なことは、オープンソースプロジェクトでは、貢献者が取り組みの途中で去ってしまい、実際の利益を得ることなくアーキテクチャを複雑にした断片を残す可能性があるという前提が必要です。企業主導のプロジェクトとは対照的に、Git プロジェクトはこれらが最終的に完成することを保証する方法がありません。

複数のリリースにまたがるトピックについては、トピックをアップストリームに提出できる状態になるまで長期実行のフィーチャーブランチを使用することを余儀なくされます。ここでのワークフローは通常のアップストリーム作業とは異なり、開発者が現在のアップストリーム master ブランチから作成する別のトピックブランチで行われます。ここから、トピックの開発は社内で行われ、各マージリクエストがトピックブランチをターゲットとする通常のマージリクエストワークフロー（内部レビューを含む）に従います。

この文脈での 1 つの問題は、アップストリームの master ブランチが進むにつれてトピックブランチが古くなってくることです。master からトピックブランチに定期的にマージすることは可能ですが、その結果はアップストリームに提出できる状態にはなりません。一方、master の上にトピックブランチをリベースすると、他の貢献者は強制更新に対応する必要があります。

代わりに、リベースとマージの組み合わせを使用して、アップストリームの master ブランチでトピックブランチを更新します:

トピックブランチはすべての変更を破棄して master ブランチにフェイクマージされます。結果のツリーは master のツリーと同じになります。
トピックブランチのすべてのコミットはフェイクマージの上にリベースされます。
オプションで、リベースされたコミットはアップストリームに提出できる状態になるように squash または再編成されます。

複雑ではありますが、このワークフローには多くの利点があります:

トピックブランチを強制更新する必要がない。
トピックブランチはアップストリームに提出できる状態を維持する。
トピックブランチの歴史は無傷のままであり、これは個々の貢献が他のコミットに squash された場合でも無傷のままであることを意味します。

このワークフローは Git for Windows が使用するものに類似しており、その shears.sh スクリプトで実装できます:

## origin を更新し、origin/master の新しい変更を取得する
$ git fetch origin
## トピックブランチに切り替える
$ git switch topic
## トピックブランチの現在のルートを見つける。これはフェイクマージの最後の場合があります
$ base=$(git rev-parse ':/Start the merging-rebase')
## またはトピックブランチと origin/master のマージベースの場合もあります
$ base=$(git merge-base origin/master topic)
## トピックブランチを origin/master にリベースする
$ ./shears.sh --merging --onto origin/master $base

イテレーション

Git メーリングリストは、パッチシリーズへの返答としてしばしば受ける多くの bike-shedding や批判のために、気がめいるように感じることが多いです。ただし、これは悪いことではありません: 正しく使用すれば、このフィードバックメカニズムはアイデアを評価し、設計上の問題を避けるためのツールとして使用できます。ただし、このメカニズムが機能するためには、パッチシリーズをイテレーションすることが重要です:

メーリングリストに送信する前に、特に大きなパッチシリーズに対して完璧主義を避けてください。基本的な設計アイデアを再考する必要があるフィードバックを受ける可能性が高く、そうなると磨くために費やした時間の多くが無駄になります。
メーリングリストにパッチシリーズを送る前に、すべての答えを持っている必要はありません。代わりに、確信のない領域を明示的に強調し、フィードバックを求めることは問題ありません。

これらのメカニズムを有益に機能させるには、より広いコミュニティと関わる必要があります:

フィードバックを受けてから最長でも数日後に新しいバージョンのパッチシリーズを送ってください。これにより、以前のバージョンでのディスカッションがまだ記憶に新しいことが確保されます。さらに、多くのアクティビティを示すパッチシリーズは、他の貢献者からより多くの注目を引く可能性があります。
受け取ったフィードバックにはすぐに、理想的には 2〜3 営業日以内に返答してください。迅速なやり取りは実りある議論に役立ち、勢いを維持することを確保します。
一方、次のバージョンをすぐに送る場合には、すべての小さな誤字の訂正に返答する必要はありません。ただし、次のバージョンを送るまでに時間がかかる場合は、些細な修正を認めつつも、さらにフィードバックを得るまで新しいバージョンの送付を保留することを伝えることが良いでしょう。
他の人の視点を考慮し、同意の上でコミットする準備をしてください。受けたフィードバックを無視しないでください。そうすることで、その人があなたの将来のパッチシリーズをレビューする可能性が低くなり、フラストレーションにつながります。

良き市民として信頼を築く

ほとんどのオープンソースプロジェクトと同様に、Git コミュニティの基盤は信頼の上に構築されています。これは自然なことです: 企業がプロジェクトの方向性とその上で働く人々を制御できる一方で、オープンソースプロジェクトは個々の貢献者の内発的な動機に依存しなければなりません。

この動機は、個人が自由な時間が少なくなったり、企業が焦点を変えたりすることに基づいて変化する可能性があります。その結果、大規模なプロジェクトが完成しない可能性があります。そのため、信頼できて依存できることは、より大きなプロジェクトに取り組むことができるため、Git コミュニティでは非常に重要です。

残念ながら、信頼は構築するのに多大な時間がかかるリソースです。開発者が達成できることの制限要因となります。これは他の GitLab 管理プロジェクトとの重要な違いです: Git チームにエンジニアを単純に追加して、大きなプロジェクトをランディングさせることを期待することはできません。これらの人々は、まず自分の専門知識を示すために Git コミュニティとある程度の時間を過ごす必要があります。

Git 自体の状態を前進させることに加えて、信頼を構築するのに役立つ他のいくつかの重要な措置があります:

GitLab の Git チームの一部ではない他の個人貢献者からのパッチシリーズをレビューしてください。これは GitLab の現在の焦点分野外であっても同様です。これにより、彼らとより良い関係を築くことができ、レビュワーが不足している中で Git コミュニティを助けることにもなります。
Git メーリングリストで同じチームメンバーからのパッチシリーズを批判的にレビューしてください。私たちは互いに責任を持ち、パッチシリーズにゴム印を押すだけではないことを示すべきです。
一般的なディスカッションとバグレポートに参加してください。
コードベースに責任を持ってください。改善できるものを見つけたら、それに対処することが良いアイデアかもしれません。一方ではこれにより Git コードベースが時間をかけて改善されることが確保されます。他方では、コミュニティの好意を得るための別の良いメカニズムです。
約束を守ってください。例えばレビューの一部として特定の項目に対応すると言った場合は、その約束を守る必要があります。これにより他のコミュニティメンバーはあなたが信頼できると感じ、複数のステップが必要となるより大きな問題に取り組むことができます。
Git メーリングリストへの存在感を一貫させてください。メールにコピーされている場合は、確認して返信すべきである可能性が高いです。これにより、他の人はあなたが主題の専門家として信頼できると感じます。

透明性

Git 開発に参加している他のコードフォージと比較して GitLab が持つ大きな利点の 1 つは、計画とコーディングのほとんどが公開の場で行われることです。これにより、Git の特定の機能を実装したい理由についても、はるかにオープンになることができます。

一般的に、直面している具体的な問題とパッチシリーズがその問題にどのように対処するかを非常に明示的にすることが推奨されます。より多くのコンテキストを提供するために、Gitaly の特定のコードと Issue に直接リンクすることができます。お客様データが含まれていない限り、特定のメトリクスに関する情報を共有することもできます。

ダウンストリーム GitLab でのワークフロー

アップストリーム優先

Git チームはアップストリーム優先のアプローチを取っています: GitLab で使用したい機能は、まずアップストリームにマージされる必要があります。これにより、アップストリームの Git から分岐したフォークに最終的に終わることがなくなります。そのようなフォークは、大幅に小さいテストユーザーベースによる追加のメンテナンスコストと、破壊のリスクが高まります。

バックポートはこのルールの例外です。バックポートとは、まだデプロイされていないバージョンにマージされる変更です。それは未リリースのバージョン（つまり master にマージされた変更）か、最新リリースより古いバージョンを実行している場合のいずれかです。バックポートは次の場合に発生する可能性があります:

本番環境でバグやパフォーマンスの修正を必要とする問題が発生した場合。
GitLab に関連するセキュリティ修正が行われた場合。

このようなバックポートを実行するために、Git プロジェクトのミラーで GitLab 固有のブランチを使用します。各リリースには対応する GitLab 固有のブランチがある場合があります（例: gitlab-git-v2.50）。このブランチは最初に対応するリリーストラックの最新のメンテナンスリリース（例: v2.50.1）を指します。

修正をバックポートする必要がある場合、個々の貢献者は GitLab 固有のブランチをターゲットとするマージリクエストを作成することが期待されます。ソースブランチに含めたいパッチを cherry-pick し、このマージリクエストは通常のレビューを受けて最終的にマージされます。

マージされたら、別のタグを作成します。例えば、そのブランチの最新のアップストリームリリースが Git v2.50.1 であれば、新しいタグ v2.50.1.gl1 を作成します。後でさらにパッチをバックポートする必要がある場合は v2.50.1.gl2 を作成します。

アップストリームプロジェクトが最終的に v2.50.2 をタグ付けした場合、これらの変更を GitLab 固有のブランチにマージして新しい v2.50.2.gl1 タグを作成する必要があります。これは新しいアップストリームバージョンに GitLab 固有のパッチが含まれていない場合のみ必要です。

真実の情報源

Gitaly は本番システムで使用する Git バージョンの真実の情報源です。プロジェクトの Makefile には、Git のビルド手順と Gitaly がビルドすべき特定のバージョンが含まれています。

更新プロセスは現在手動であり、Git チームが新しいリリースでバージョンをバンプする責任を持ちます。私たちは現在、タグ付きリリースを使用しないように変更するプロセスを進めています。代わりに、約 2 週間の遅延で master ブランチから Git をデプロイし始めます。このプロセスは Renovate を通じて自動化されます。

最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)

ページのソースコードを見る - ページの編集 - please contribute.