中央コードライブラリを管理するための効果的なgitプロセスとは何ですか？
簡単な背景：私たちは小規模から中規模のSymfony 1.4サイトを開発している小さなWebエージェンシー（常に3〜6人の開発者）です。私たちは今1年間gitを使用していますが、以前はSubversionを使用していました。
過去6か月間、カスタムCMSを強化する中心的なSymfonyプラグインに多くの開発時間を費やしてきました。このプラグインには、カスタム機能の構築に使用する多数の機能、ヘルパー、基本クラスなどが含まれています。このプラグインはgitに格納されますが、プラグインがさまざまな製品で使用され、常にプル/プッシュされるため、ブランチは乱暴になります。リポジトリは通常、主要なプロジェクト内のサブモジュールとして使用されます。
私たちが今目にし始めている問題は、多数のMergeの競合と、開発者が独自のプロジェクトのコンテキストでカスタム機能を追加することによってリポジトリにもたらされた後方互換性のない変更です。
私は Vincent Driessenの優れたgit分岐モデル を読んで、過去のプロジェクトで正常に使用しましたが、特定の状況にうまく適用されていないようです。新しい機能を開発しながら、同じコアプラグインを同時に使用する多くのプロジェクトがあります。
私たちに必要なのは、以下を提供する戦略です。
- コードリポジトリ内の主要な機能を開発するための方法論。
- これらの機能を他のプロジェクトに移行する方法。
- コアリポジトリをバージョン管理する方法、および各主要プロジェクトが使用するバージョンを追跡する方法。
- バグ修正を古いバージョンに移行するための計画。
- 変更がどこから来たのかを簡単に確認できる明確な履歴。
提案や議論は大歓迎です。
このフローの主な間違いは、顧客ブランチの作成です!!!可能なブランチは、新しいライブラリ機能お客様のものではないのみです。
これは一般的なライブラリなので、（機能リクエストからの）顧客クラスによってオーバーライドできるAPIを提供する必要があります。ただし、このカスタマイズされたクラスは、クライアントのメインプロジェクトリポジトリにある必要があります。
開発者が非常に高度に結合されたコードを記述しています。コードのモジュール性、インジェクション、インターフェースなどに関する記事を読んでください。これにより、痛みが大幅に軽減されます。
2つ目は、ライブラリの適切なフローです。バージョン付きライブラリを開発する必要があります（例：0.5、0.7、1.0、1.2）。ライブラリの問題は、プロジェクトごとにバージョンが異なることです。 Gitフローはこれを適切にサポートしていません（最後のリリースと現在の開発のみ）。このタイプのフローに適切なサポートツールを探しています。
まとめ-あなたの主な悩みは悪いライブラリコードにあります。 開発者は、デフォルトの動作、クライアントの動作なし、およびデフォルトの動作をオーバーライドできるAPIを使用してコードを記述する必要があります。
毎日こういうことをしていると、あなたの痛みを感じます。私の状況は、オープンソースプロジェクトの複数の顧客バージョンを維持する必要があり、それぞれに異なるプラグイン、コアハックなどが選択されていることです。それらを50個持っていると、楽しくありません。
理想的な（完全にクリーンな）ソリューションはまだ見つかりませんが、GitFlowに対する変更は次のとおりです。
- 各顧客の本番コードに対して（マスター以外の）別のブランチを作成します。完全な全機能バージョンのマスターを使用し、顧客が望むものだけを自分のものにマージします。
- 厳密に定義された修正プログラムと機能ブランチで開発（または追加されたプラグインなど）を維持し、マージした後でもそれらをそのままにしておく必要があるので、他の顧客ブランチにマージできます。また、ログをクランチすることで、誰がどの機能を持っているかを簡単に追跡できます。
- 新しい機能を開発するときは、可能であれば、すべての顧客の最新の共通祖先から分岐します。これは、マージして開発してからマスターできるだけでなく、（理論的には）競合を発生させることなく顧客の本番ブランチにマージできることを意味します。
- GitFlowのように見える、開発作業専用のメインリポジトリを1つ用意します。 devリポジトリをリモートとして持つ別のものを用意します。これは、顧客のブランチを保存して、devリポジトリがよりクリーンな履歴を持つようにするために使用されます。
- 本当に簡単に競合を解決できず、ブランチ全体を一度にチェリーピックする必要がある場合は、rebase --onto like this を使用します。機能がどこから来たのか、そしてなぜそれが通常マージされないのかをコミットメッセージで明確にしてください。
Gitを使用すると、追加の副次的な利点があり、すべての本番サーバーでcronジョブを実行して、gitリポジトリのステージングされていないファイルをチェックできるようになりました。これで、サポートスタッフが誰にも言わずにサーバーのプロダクションコードを試してみたかどうかがわかりました。これにより、多くの頭痛の種がなくなりました:)
お役に立てば幸いです。
共有コードは、開発と保守にコストがかかります。複数のシナリオで機能する必要があります。下位互換性がなければなりません。また、変更によって既存のクライアントが破損しないことを確認するためのテストケースが必要です。
原則として、共有機能は、3か所以上で使用される場合にのみ価値があります。
developers adding custom functionality in the context of their own project.
1つまたは2つのプロジェクトのカスタム変更は、共有コードに反映されません。これを許可すると、共有コードはすぐに複雑になり、維持できなくなります。ワークフローはそれを助けることができません。
マットギブソン自身の答えについて同意します。
私たちの会社でも同じ状況があり、同じリポジトリの複数のバージョンを複数の顧客に処理することは過去に行われており、非効率的であることが示されています。私たちが見つけた最善の解決策は、構成によって機能を有効/無効にする可能性のある製品に私たちのソリューションを変換することでした（プログラマーだけが実行でき、顧客は実行できません）。これは、次の理由から良いことがわかりました。
リポジトリが1つしかないため、コードの保守が容易になります。
更新頻度が高い（毎週）顧客は、バグ修正と小さな「無料」機能を利用できるので、より快適になります。これは、使用するフレームワークとCMSでコードを最新の状態に保ち、セキュリティ修正を確実にするためにも重要です。
更新率が低い、または保守契約がないお客様は、以前のバージョンと更新されていないバージョンのスナップショットを含むカスタムブランチを持っているため、重大なバグのみを修正できます（また、マスターで修正するため、これらの古いブランチに固有のものはありません）。 。これは私たちが避けているアプローチですが、特定の顧客は更新の支払いを望まないため、これが私たちがそれを処理する方法です。
新しい機能は妥当な頻度でお客様に提供され、当社の営業チームがそれらを提案することができます。多くの場合、これは機能します。つまり、すでに機能している機能を販売できるため、共有機能であるため、開発を待つ必要がなく、コストが削減されます。
だから、私はあなたが持っているものについて再考することが最良の選択肢だと思います。それは支店についてではなく、会社が所有する製品についてです。
短命のコード変更のためにブランチを使用します-通常は数日から1週間または2週間です。
ブランチは純粋に新しい機能/修正/アップグレード/雑用を管理するために使用する必要がありますnotは製品の機能自体を管理するためのメカニズムである必要があります。
1つのオプションは、製品ごとに複数のマスターを使用することですが、これは一般的なコードの同期を維持する必要性に対応していません。
コードを変更せずにスイッチを介してこれらを構成できるソフトウェア/ API /構成を開発する必要があるようです。
私が見ると予想される主な「長命」のブランチは、Rubyおよび/またはRailsバージョンなど）のようなアプリケーションに関連しない違いのバージョンです。
これは、バージョン管理の問題ではなく、依存関係の管理の問題のように聞こえます。
composer のようなものを使用するのはどうですか？どの依存関係各プロジェクトが使用するか、およびそれらのプロジェクトのどのバージョン（例：1.2.x）が許容されるかを定義します。共有コンポーネントを更新しても、依存プロジェクトは自動的に更新されません。特定のプロジェクトの依存関係を更新するには、composerを明示的に指示する必要があります。
プロジェクトの依存関係を更新する場合、依存関係の更新をコミットする前にすべてが引き続き機能することを確認できます。これはあなたに物事を安全に試す機会を与えます。
Composer docsには多くのリソースがあり、正しい方向を示しているはずです。