0

The problem: We develop systems for banks. These systems are (theoretically) highly secure and almost always protected by quite fierce NDA's. Consequently, whilst there is some shared code between the various projects, a lot of it is entirely separate. That said, it would be catastrophic if code or documentation from one project 'bled' into another project owned by a different client. This problem is exacerbated by two clients requiring that we push code to their repo (part of our contractual requirements).

Hitherto, we've simply used a completely independent repo for each client. Of course this means that in some cases we have duplicates of the same code modules; changes/fixes are inevitably lost if an update is made in one repo and not distributed to the others. It would be much better if we only had to maintain one copy of such files.

Another approach, of course would be to use a branch for each client but I've found the overhead of merging between branches is unsupportable. Also, I've looked at git sub-modules but, again, these seem to be too fraught with peril in that a careless commit could comprise the 'Chinese walls' between the projects and merging seems to be even more complicated than just by forking the project (see http://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/). I hate implementing systems where a developer has to remember a particular procedure because, when things are done in a hurry, mistakes are inevitable.

Obviously first prize would be to have one single repository but where only certain directories or files are uploaded to a specific remote repo. While I appreciate that this could be accomplished to a certain extent by using .gitignore and individual branches per client, I'm concerned that finger-trouble (if someone edits the .gitignore file inappropriately), could cause the very thing I'm trying to avoid.

Almost all of our development platforms are Linux based but the development environment for one legacy system can only operate on Windows XP and it won't run under Wine for some reason (linked to the Java runtime I suspect but that's a story for another day).

I've considered using rsync or symbolic links to share the common files but it seems tacky and may also cause trouble if some idiot changes the file dates on old versions of a source module. At the moment we have too many individual repositories and duplicate modules for my liking and I can see it causing trouble down the track. I figure this must be a fairly common problem and I'm sure someone has handled it in a stable, platform-independent way that doesn't assume developers never make mistakes on commits.

4

3 に答える 3

3

これを考えると、私はそれを期待します:

もちろん、これは場合によっては同じコード モジュールが重複していることを意味します。更新が 1 つのリポジトリで行われ、他のリポジトリに配布されない場合、変更/修正は必然的に失われます。そのようなファイルのコピーを 1 つだけ保持すればよいのであれば、はるかに優れています。

解決策は、共通のリポジトリ (クライアントに関連付けられていない) を維持して、ライブラリ コンポーネントを構築することです。そうすれば、ライブラリのさまざまなバージョン (適切にバージョン管理されたもの) をビルドし、実際のコードをインポートするのではなく、クライアント コードのさまざまなリリースがそれらのライブラリを使用します

私は通常、これらのライブラリの異なる (連続する) バージョンを保存し、クライアントのコード ベースで使用するライブラリのバージョンを指定します。ライブラリ プロジェクトはライブラリ テストなどを定義し、クライアント プロジェクトのバージョン番号を変更することで、使用するライブラリのバージョン (たとえば、修正された新しいバージョン) を指定できます。

明らかに最初の賞は、単一のリポジトリを持つことですが、特定のディレクトリまたはファイルのみが特定のリモートリポジトリにアップロードされます

上記の理由から、これはスケーラブルまたは実用的ではないと思います。開発をサンドボックス化し、結果のバイナリをダウンストリームで使用できるようにする方がはるかに優れていると思います。新しいクライアント リポジトリをチェックアウトする場合、すべての依存コードを再構築する必要はありませんが、アーティファクトをダウンロードするだけです (リポジトリがサポートしている場合はソース コードも)。

バイナリ展開を配布するためのさまざまなソリューションが存在します (たとえば、Java の世界では、 Sonatypeの Nexusとその Maven ビルドツールとの統合を確認してください。Nexus/Maven は、バイナリと一緒にパッケージ化されたソース コードのダウンロードをサポートしています)。

于 2013-05-15T16:51:00.647 に答える
0

共通のモジュールとコードのリポジトリを作成し、それを各プロジェクト リポジトリに複製することを検討しましたか? このようにして、各プロジェクトに同じコア コード ベースを使用しながら、クライアント用にそれらを分けておくことができます。

決定した場合は、何らかの理由で更新中に競合が発生した場合に、コア モジュールの別のブランチを使用することもできます。

于 2013-05-15T16:54:40.873 に答える
0

必要なのは、本質的にライブラリであるコンポーネントがあることを認識することです。このライブラリには、プロジェクトに対して完全に独立して中立的であるが、特定の機能を有効にするために必要な部分のみが含まれています。このようなライブラリは、サブモジュールまたはツリーとして追加され、独立して維持および開発されます。両方の顧客プロジェクトの開発者は、このライブラリを最新の状態に保ち、使用する方法を知っているだけで間違いを犯すことはありませんが、直接変更することはありません。彼らは彼らのためにカスタマイズされた特定のバージョンを再実装するかもしれませんが、これはクライアント プロジェクト内にとどまるため、コミットされることはありません。

于 2013-05-15T16:54:45.410 に答える