ほぼ2年前、私たちはフラッグシップのDBMS Linterプロジェクトの開発に新しいブランチおよびgitサブモジュール管理モデルの使用を開始しました。 この間に開発者グループが数万件のコミットを行ったため、ある程度の確実性を持ってイノベーションを成功させることができます。 この記事は、gitモジュール、既存の分岐戦略、およびlinflowツールキットの代替実装に基づいた大規模プロジェクトでソースコードリポジトリを整理する原則の概要です。

モノリポジトリ、gitサブモジュール、gitサブツリーまたは...

以前は、LINTERソースコードはCVSに保存されていました。 このバージョン管理システムの道徳的陳腐化にもかかわらず、私たちが積極的に使用した特定の機能がありました（これにより、この「恐竜」がランク内で長く続くことができました）：特定のタスクで作業するには、その依存関係を持つ必要なモジュールのみを抽出できました これは、プロジェクト内のモジュールのほとんどが相互に低く自由にペアリングされているため便利です。



技術的には、必要なソースコードを取得するプロセスは可能な限りシンプルに編成されました。サーバーは一連のモジュールをディレクトリに格納し、開発者は特定の技術プロセスに必要なツリーの抽出ツールとファイル記述子を保持しました。 より明確にするために、このような記述子の小さな断片を示します。

#RepositoryDir Unix RELAPI relapi LINDESKX lindeskx KERNEL5/SQL sql KERNEL5/TSP tsp
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ルールによって、抽出するモジュールだけでなく、それらを抽出する場所、つまり中央リポジトリのツリーと作業コピーのツリーが異なることも決定されたことがわかります。 これらの記述子ファイルは、さまざまなターゲット配布、オペレーティングシステム、およびDBMSのバージョンごとに変更されました。



しかし、ご存じのとおり、gitはリポジトリの一部を複製するための単純なメカニズムを提供していません。 したがって、CVSからgitに移行するという疑問が生じた場合、まず、プロジェクトツリー全体で単一のリポジトリ（モノリポジトリ）を使用し、製品のアセンブリプロセスへの変更が不可避的に導入されるか、プロジェクトを独立したモジュールのセットに格納する2つの最も明白な方法を検討しましたgitのサブモジュール/サブツリーを使用してそれらを操作します。

モノリポジトリ

プロジェクトツリー全体で1つのストアを使用するという考えは、すぐに放棄されました。 そして、正当な理由がありました：

• パフォーマンス。 いいえ、Facebookのテスト（ http://habrahabr.ru/post/137615/ ）のように130万個のファイルはありませんでしたが、14,000個までのファイルのエクスポートされた履歴のコミット数114800は、作業中の顕著なパフォーマンス低下を修正するのに十分であることが判明しましたインデックス付き。
• 物語。 モノリポジトリには、編集の共通の履歴があります。カーネルの編集、例、ユーティリティ、ドキュメントなどは、1つのログ行に混在させることができます。
• サポート。 ソースツリーの統一は、前世紀末以降にリリースされた製品のすべてのバージョンのアセンブリメカニズムの変更につながります。 もちろん、これらのリリースの開発は現在進行中ではありませんが、アーカイブバージョンから「ほこりを吹き飛ばす」機能を失いたくありませんでした。

gitサブモジュール/ gitサブツリー

モジュールのグループをメインリポジトリに保存するという観点から問題がなければ、正しい作業ツリーにクローンを作成するのは困難でした。 もちろん、gitはネイティブのサブモジュールとサブツリーをサポートしていますが、それらを使用することには十分な欠点があります（ http://habrahabr.ru/post/75964/を参照）。これらはこのバージョン管理システムのアーキテクチャ機能です。 しかし、最も不快な瞬間は、子モジュールの非公開状態への参照がコンテナーモジュールのメインリポジトリに入らないようにする必要があることでした。 そのため、実験リポジトリを使用して、クライアント側でモジュールを管理するための代替メカニズムが必要であるという結論に達しました。

linmodules

ネイティブgitサブモジュールとgitサブツリーの欠点を排除するために、gitレベルで動作する独自のモジュール管理メカニズムを開発しました。 このメカニズムの実装は、linflowと呼ばれるツールキットの一部になりました。



スキームは非常に単純です。各プロジェクトモジュールは、エクスポートされた履歴とともに個別のリポジトリに格納され、モジュールの1つ（この例ではlinter.gitという名前）は、ソースコードを含まないコンテナモジュールであり、その主なタスクはみんなのためのグローバルブランチツリー。 コンテナモジュール内のこれらのグローバルブランチはそれぞれ、独自の記述子ファイル（.linmodulesという名前）を持つことができます。これは、正しいプロジェクトツリーを取得するために必要です。



ネイティブのgitサブモジュールを毎日使用しない幸運な読者にとっては、どんなに驚くべきことに聞こえるかもしれませんが、そのようなスキームは標準実装よりも簡単で便利であることが判明しました。





図1：ソースツリーバリアントの取得方法。 1-記述子ファイルを使用してコンテナモジュールを複製します。2-初期化、3-登録済みモジュールをターゲットディレクトリに複製します。



テンプレートの説明の構文（.linmodulesファイル）は、「ネイティブ」構文を完全に繰り返します。これは、gitで.gitmodulesファイルに使用されます。 これは、後方互換性のために意図的に行われました。



図1の配置テンプレートのフラグメントを次に示します。

 [submodule "tick"] path = lib/tick url = git@linter-git.common.relex.ru:TICK [submodule "odbc"] path = odbc url = git@linter-git.common.relex.ru:ODBC [submodule "inl"] path = app/inl url = git@linter-git.common.relex.ru:INL
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、モジュールを任意の作業コピー構造に抽出する機能を維持することができました。 テンプレートの最初の形成とその後の変更は、linflowを使用して行われます。

分岐モデル

gitベースのリポジトリの最適な組織を探している多くの開発者がVincent Driessenの仕事「Gitブランチモデルの成功」に精通していると考えるのは大きな間違いではありません（これを行う時間がなかった人は常に元のhttp：// nvieを読むことができます） .com / posts / a-successful-git-branching-model /またはHaberの翻訳http://habrahabr.ru/post/106912/ ）。 私たちも例外ではなく、モデルをテストした後、モデルを調整しました。その結果、「親」モデルの一部の機能を継承した独自のモデルになりました。 元の記事のタイトルは不誠実ではありませんが（モデルは本当に成功しています）、これは長い歴史を持つ本当に大きなプロジェクトにそれを適用する必要があるまで正確です。



Vincent Driessenの「成功した」モデルに変更が必要な理由はいくつかありました。 発生と解決の順序で最も重要なもののみを示します。

• 元のモデルは、ソースプロジェクトをサブモジュールおよび依存関係のあるモジュールに分解するときの動作を指定していません。
• 製品のメンテナンス中はリリースブランチを閉じることができないため、これらの行を書いている時点では、2009年の初めからリリースされたすべてのバージョンにバグ修正と新機能の一部が含まれています。 このため、異なるバージョンの製品のビルドを、ブランチでの単一のコミットシーケンスで表すことはできません。
• パッチおよび機能ブランチは、開発ブランチへのすべての変更を含まない古いバージョンに移行できるため、マージは単に不可能です。
• 圧倒的多数の修正には1つのコミットが含まれています（これらの行を書いている時点では、2598個のパッチが適用されたブランチのうち、262個のみが2つ以上のコミットを持っています）。そのため、毎回追加のマージコミットを生成するno-ffマージを使用するのはあまり便利ではありません。

「成功した」モデルの変更に関する作業の結果、独自の戦略が作成されました。これは、元の用語、規則、命名、および作業プロセスの一部を継承します。 簡単にするために、以下で詳細に説明する主な変更点を強調します。

• 1つのプロジェクトのサブモジュールでブランチを維持するためのルールが指定されています。
• 開発ブランチで作業するためのルールを変更しました。
• バージョンリリースルールが変更されたため、
• リリースブランチを管理するためのルールを変更しました。
• 編集をブランチからブランチに転送するためのルールを変更しました。

図2：モジュールでコードを分岐およびラップするためのオプション。 リリース＃2のリリースブランチは最新であり、マージを使用して編集を転送できます。リリース＃1は以前のバージョンをサポートし、選択的に変更を受け取ります。

主な支店

中央リポジトリには、 常にすべてのモジュールに存在するブランチのグループが含まれています 。

• リリースブランチ -バージョンが利用可能になったときに補足されるプロジェクトブランチのグループ。
• 開発（マスター） -開発のメインブランチ。

オリジン/リリースブランチはメインの本番ブランチと見なされます。つまり、それらのソースコードはいつでもバージョンをリリースしたりビルドしたりできるようにする必要があります。 origin / masterブランチはメインの本番ブランチと見なされ、プロジェクトへのすべての変更が含まれ、 origin / releaseを作成するためのソースとして機能します。 origin / masterのソースコードをリリースする準備ができたら、変更を特定の方法で対応するorigin / releaseに転送するか、新しいバージョンを生成する必要があります。したがって、 origin / releaseにブランチを作成します。

補助枝

メインブランチに加えて、リポジトリの構造（中央コピーと作業コピーの両方）は、次のタイプの補助ブランチの存在を意味します。

• 機能ブランチ -新しい機能のブランチ。
• 枝を修正

これらのタイプのブランチにはそれぞれ、特定の目的と一連のメンテナンスルールがあります。これらについては以下で説明します。





図3：モジュールによるブランチの分布：メインブランチはすべてに存在し、補助ブランチは必要なものにのみ存在します。

一般規則

中央およびローカルリポジトリでブランチを管理するための一般的なルール：

• 開発（マスター）には安定したコードが含まれています。
• 開発（マスター）はすべてのモジュールに存在します。
• 開発（マスター）ブランチでの開発は禁止されています。
• 開発（マスター）は、新しいバージョンまたはリリースをリリースするために必要なコードを保管します。
• 必要に応じて、 開発（マスター）ブランチリリースブランチからの新しいリリース。
• リリースブランチは 、新しいビルドをリリースするためのコードを格納します。
• ビルドリリースは、対応するリリースブランチのヘッドコミットでタグ付けされます。
• コンテナモジュールにリリースブランチタイプのブランチを作成すると、各サブモジュールに同じブランチが作成されます（図2を参照）。
• 修正ブランチは、 開発（マスター） ブランチまたはリリースブランチから分岐でき、両方を開発（マスター） ブランチとリリースブランチにマージできます。
• 機能ブランチは開発（マスター）からのみ分岐し 、必然的にそれにマージします。
• 機能ブランチを構成するコミットは 、必要に応じて、1つ以上のリリースブランチに転送でき ます （ただし、この事実は、developerとの強制的なマージに関する以前のルールをキャンセルしません）。
• 機能ブランチとホットフィックスブランチは 、中央リポジトリで定期的に公開されます。

リリースブランチ

リリースブランチはrelease / Blinter_AB_Cと呼ばれます 。ここで、 Aはメジャーバージョン、 Bはマイナーバージョン、 Cはリリース番号です。 リリースブランチは、developから生成され、LINTERバージョンが常にサポートされています。 ブランチはコードの受信者であり、開発は実行されません。 新しいビルドのリリースの各ファクトは、 Blinter_AB_C_Dの形式の対応するタグでマークされます。ここで、 Dはビルド番号です。 このタイプのブランチは、別のリリースブランチへのリンク（組織の観点からoriginへ ）にすることができます。 この場合、これらのブランチの1つで公開されると、関連するすべてのブランチが更新されます。 リリースブランチはグローバルです。つまり、コンテナモジュールで作成された場合、すべてのモジュールに存在します。 ビルドタグを持つタグは、すべてのモジュールで一度に設定されます。

ブランチを修正

修正ブランチはホットフィックス/ *と呼ばれ、開発（主に）またはリリースから生成でき、 開発（マスター）およびリリースにマージできます。 修正に1つのコミットが含まれる場合、マージコミットを作成せずにマージが実行されます。 コメント本文の最後のコミットには、バグトラッカーの対応するチケットの番号への参照が含まれています。 編集を転送した後、パッチブランチは閉じられます。

機能ブランチ

関数ブランチはfeature / *と呼ばれ、Developer （master）からのみ生成されます。

機能ブランチは、現在または将来のリリースで表示される新しい機能を開発するために使用されます。 機能の開発が継続している限り、ブランチが存在します。 中間結果が達成されると、ブランチは中央リポジトリに公開されます。 ブランチでの作業が完了すると、後者は必然的にメインの開発ブランチ（機能が次のリリースで追加されることを意味します）にマージされ、オプションでリリースブランチにマージされます。 コード転送後、機能ブランチは閉じられます。

linflow

上記のテキストで何度か言及されたlinflowツールキットについていくつかの言葉を言う価値があります。 Linflowは、ソースツリーのモジュールを使用した操作、および分岐モデルのサポート用に設計されています。 linflowのクライアント部分はgit-flowプロジェクト（ https://github.com/nvie/gitflow ）のフォークです。これは、戦略のために変更され、linmodulesをサポートするように拡張されています。 さらに、gitoliteの拡張機能として機能するサーバーパーツを開発しました（ http://gitolite.com ）。



linflowのモジュール管理機能を使用すると、次のことができます。

• モジュールの登録/削除。
• 既存のモジュールのソースおよびターゲットディレクトリを編集します。
• 作業コピーの初期設定を行います。
• コンテナモジュールのステータスを監視し、ネストされたモジュールをタイムリーに切り替えて更新します。
• モジュールをパックします。
• プロジェクトツリー全体の一貫性を確認します。

linflowのブランチ管理機能により、次のことが可能になります。

• 許可されているすべてのタイプのブランチを作成/削除/公開します。
• ブランチ命名契約の実行を制御するため。
• コンテナモジュールの後のすべてのモジュールでブランチとタグに一貫して切り替えます。
• モジュールの一括操作を実行します。
• さまざまな戦略を使用してブランチからブランチにコードを転送します。
• 変更された履歴を持つブランチにコードを転送します。
• ブランチの誤った削除を防止します。

サーバー側の機能により、次のことが可能になります。

• 命名規則への準拠を監視します。
• ロールごとにユーザー権利を区別します。
• リンクブランチを管理する
• 潜在的に関心のある参加者の動的に生成されたリストに変更の通知を送信するため。
• 完全バックアップを作成します。

現在、分岐モデルおよびlinflowツールの完全な技術ドキュメントを公開する可能性の問題について議論されています。 この出版物への応答（または不在）は、これにおける最も重要な役割ではありません。