問題タブ [monorepo]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
version-control - ソース管理における多言語プロジェクトの賢明な構造とは?
職場では、かなりの数のフロントエンド、バックエンド、およびサポート コンポーネントを含む大規模なアプリケーションを開発しています。通常、フロントエンドは C# で開発され、バックエンドは Java で開発されますが、バックエンドの一部は C# で開発され、その後 C++ で開発されることもあります。
言語とプラットフォームの選択は任意ではありません。私たちは、開発時間、ツールチェーンのコスト、特定の開発チームによる言語への習熟度など、それぞれの相対的なメリットを比較検討しようとしています。ただし、これらすべてのコンポーネントに共通しているのは、それらがすべて完全な操作に必要であるということです。製品であり、独立した (しかし非常にコミュニケーションの取れた) チームによって同時に開発されていること。
以前は、.NET コードに Team Foundation Server を使用し、Java コードに Subversion を使用していました。チームの責任が明確に分離されていたため、あるソース ツリーから生成されたバイナリ (この場合は WAR) を別のソース ツリーに配置する不便さと、ブランチとリビジョンの同期を維持するための高い手動オーバーヘッド以外の問題はほとんどありませんでした。このプロジェクトでは、チーム間の分離の程度は意図的に非常に小さくなり、分岐/マージの量はかなり多くなることが予想されます。その結果、統合された VCS、より具体的には Subversion に移行しています。
これが問題の本質につながります。Java と C# のコードを効果的に混在させるにはどうすればよいでしょうか。実際には、Java コードベースに依存する .NET コードを使用します。Java バイナリは、単体テスト コード以外のものを実行するために必要です (統合テストには既にバイナリが必要であり、QA、受け入れテストなどにも確かに必要です)。現在考えていることは次のようなものです。
ソース ツリー全体が 1 つのブランチの下に配置されるという考え方です。.NET コードは Java コードに依存しているため、(ほとんどの場合) Java コンポーネントの ant スクリプトを呼び出すビルド後の手順をソリューションに追加します。これにより、コードベース全体 (.NET 開発者の場合) または Java コンポーネントのみ (Java 開発者の場合) の分岐が可能になります。
このソリューションの問題点は次のとおりです。
- 2 つのコードベースのいずれかが非常に大きくなり、ブランチごとにコピーを作成することが現実的ではなくなった場合はどうなりますか? (私たちの考え: 分割して .NET と Java コードのリポジトリを分離し、svn:externals を使用します。これに関する意見をいただければ幸いです)。
- Java開発にはEclipseを使用しています。「共有」ワークスペースをどのように管理しますか (つまり、どのコンポーネントにどのプロジェクトが必要か、依存関係グラフなど)? これまで、Java コンポーネントは比較的少なかったので、各開発者はそれらすべてを同時にワークスペースに保持することができました。Java コンポーネントと Java 開発者の増加に伴い、どうすればそれを続けられるかわかりません。2 つのコードベース間の同期を維持しながら、ワークスペースのバージョン管理 (ソリューション ファイルのようなもの) を維持する方法について何か提案はありますか?
ご意見をお待ちしております。
git - ブランチやタグを失うことなく、サブフォルダー内の git リポジトリをマージする方法は?
この質問は重複しているか、以前の多くの質問 (および同様の主題を扱った数十のブログ投稿) のように思われますが、スクリプトを作成できるアプローチを探していることを認識しておく必要があります。
- すべてのブランチとタグはマージされるはずです
- 重複を避けるために、ブランチとタグにはプレフィックスを付ける必要があります
- 新しいサブフォルダーにインポートするため、ファイルが重複することはありません。
- 増分マージ プロセス: 一度に 1 つのリポジトリでゆっくりと monorepo セットアップに移行する予定であるため、後で新しいリポジトリをマージできるようにします。
私が構築しようとしているスクリプトは、次のように動作するはずです。
これは、ターゲット リポジトリ (monorepo) がmonorepo/
フォルダー内で既に複製されており、ローカルの変更がないことを前提としています。
たとえば、foo.git に 2 つのブランチmaster
とdevelop
1 つのタグ名がある場合、マージを実行した後、 monorepo リポジトリ内にブランチとタグv1.0
が表示されることを期待します。foo-master
foo-develop
foo-v1.0
何十もの記事 (またはスクリプト) を読みましたが、これまでのところ、これを取得する方法を説明する記事を見つけることができませんでした。
明確化
- foo.git レポジトリのルート内に README.txt がある場合、このファイルは .txt 内にあるはずです
monorepo/subdir/foo/README.txt
。これらが大きなレポのサブディレクトリ(以前は存在しなかったサブディレクトリ)になる場合、競合することなくリポジトリをマージできる唯一のアプローチです。
アップデート
問題が解決したとはまだ言えませんが、ソース リポジトリにパッチを適用した後にマージを実行することになっているこの bash スクリプトを作成することになりました。それを見てください https://github.com/ssbarnea/monorepo/blob/master/git-monorepo-add.sh
PS。多くのリポジトリでテストされた信頼できるソリューションが得られたら、すぐに適切な回答を返します。
git - サブツリー/サブフォルダーに触れる Git コミット
の下proj
のフォルダーにサブツリーを使用する monorepo プロジェクトがあります。と の両方に触れる大量のコミットを行いました。関連する変更をアップストリームに効果的に公開するにはどうすればよいですか?sub
proj/sub
proj
sub
sub
通常、私はすべてのコミットをチェリーピックする必要があります
git cherry-pick -x --strategy=subtree -Xsubtree=sub/ commit-ref
しかし、私は無数のコミットを行ったので、これは実行不可能です。sub
変更を一度に統合するにはどうすればよいですか? たとえばsub
、モノレポと同じ状態にする 1 つの大きな押しつぶされたコミットを作成します。
関連:サブフォルダーに変更を加えるコミットを表示する、コミットの範囲をチェリーピックして別のブランチにマージする方法
git - Git サブツリー vs モノレポ
最近、TFVC から Git に移行することを決定し、新しい Git アーキテクチャを設計するための最良の方法を見つけようとしています。
私たちのコードは、独立しているが緊密に結合されたモジュールで構成されています。次のプロジェクトを見てみましょう。
CommonLib1
CommonLib2
ApplicationA
(使用CommonLib1
)ApplicationB
(CommonLib1
&を使用CommonLib2
)
CommonLib1
/は完全に独立していますが、 /CommonLib2
のほとんどすべての新機能はApplicationA
/ApplicationB
を変更する必要があります。CommonLib1
CommonLib2
さらに、新しい機能を追加するときは、すべてのプロジェクトにまたがる単一のブランチを作成したいと考えています。
私が理解している限り、2 つの主なオプションが残っています。
プロジェクトごとにリポジトリを作成し、
CommonLib1
/CommonLib2
をサブツリーとしてApplicationA
/に追加しますApplicationB
。すべてのプロジェクトに対して 1 つの Monorepo を作成します。
私の状況に最適な Git プラクティスは何でしょうか?
reactjs - create-react-app パッケージを使用して monorepo で jest を実行する
ここで質問です。
一部のパッケージをモノレポにマージしようとしています。私が使っていてyarn
、それがworkspaces-experimental
特徴です。したがって、リポジトリのフォルダー構造は次のようになります。
現在、目標の 1 つはテストを簡素化することです。jest
すべてのパッケージの単体テストを実行できるように、ルート ディレクトリで実行したいと考えています。そして、それはnode.jsアプリである以上で機能myapp1
します。myapp2
ただし、 (イジェクトなし)myreactapp1
でビルドされ、 create-react-app
ES6 機能 (などimport
) と jsdom レンダリングも使用されます。コードをパイプするmyreactapp1
dirからテストを実行すると、テストは正常に機能します(よく理解していれば)。しかし、ルート jest は最初のステートメントで失敗します。yarn test
babel
import
どうすればできますか?
PS インストールしようとしましbabel-jest
たが、コンソール (Windows) から直接起動できないようです。