24

他のプロジェクトを含むように Git プロジェクトを設定するにはどうすればよいですか?

例えば。私はオンライン マッピング アプリに取り組んでいます。SFの衣装と一緒にGPSツールを開発しました。同時に、別の関心事 (ジオマッピングのみを気にする) と共に Python Geomapping スクリプトを開発しました。私たち自身のコア ファイルは 2 つを結合し、必要なアプリのためにそれらの上に構築します。

各プロジェクトは単独で存在する必要があります。GPS に関心のある人は GPS にのみ関心があります。ただし、他のすべてのプロジェクトを含む「親」プロジェクトは、プロジェクトとしてアクセスできる必要があります。

サブモジュールを理解するために時間を費やしましたが、必要なものに対して独立性が高すぎるようです。

また、可能であれば、それらの各プロジェクトに 1 つまたは 2 つの重複するスクリプトを含めることができればよいでしょう。1 つの Git プロジェクトに、その「ルート」の一部ではないファイルを含めて、このファイルがいずれかのチームによって更新されたときに両方のチームが利益を得られるようにすることはできますか?

これは Git で実行できますか? マーキュリアルで？ホスト (GitHub、Gitorious) は重要ですか?

「親」に Subversion を使用する考えがあります - .git フォルダーを無視し、プロジェクトに Git を使用します (.svn フォルダーを無視します) - しかし、それは最後の手段にすぎません。

編集：

サブモジュールが不要な理由を説明するには:

  1. ユーザーがダウンロードすると、zip にはサブモジュールが含まれません (こことここ)。共同作業者でさえプロジェクトをセットアップしようとする場合も同様です。これはショーストッパーです。
  2. サブモジュールは凍結されています - それらは (簡単に) 指摘されているプロジェクトの最新バージョンを取得しません。
  3. 以下の素晴らしい回答とNoPugsでのこのモノローグで指摘されている他の理由。

サブツリーのマージ (下記の Paul によって紹介されました) はうまくいきません: [サブツリーの] ソースをマージ先のプロジェクト内から更新することは困難であり、そのソースはプロジェクトの「ルート」フォルダーの外に存在する必要があります。プロジェクト。Web アプリであるため、すべてのページがその中のフォルダーに内部的にリンクされ、テストと更新がそのフォルダー内で直接行われることが重要です。（これが明確で他の人にとって役立つことを願っています。）

「リモートブランチ」の設定についてはまだ勉強中ですが、他のアイデアはまだ歓迎されています。

4

6 に答える 6

15

私が取り組んできた（小さな）プロジェクトでは、サブモジュールが特に役立つとは思いませんでした。それらを設定したら、プロジェクト全体で作業するには、ほぼすべてのコマンドに追加のパラメーターを追加する必要があり、構文は完全に規則的ではありません。より多くのサブモジュールを含む大規模なプロジェクトに取り組んだ場合、より有益なトレードオフになると思います。

サブプロジェクトを独立した git リポジトリとして保持し、そこからメイン (統合) リポジトリにプルする可能性は 2 つあります。

  • サブツリー マージ を使用し て、コア ファイルを含むメイン リポジトリ内の個別のサブディレクトリに外部プロジェクトを移動します。これにより、外部プロジェクトからメイン プロジェクトを簡単に更新できますが、変更を外部プロジェクトに送り返すのは複雑です。これはプロジェクトの依存関係を含める良い方法だと思いますが、共有ファイルではうまく機能しません。 別の簡単な説明 (リンク固定) .

  • 各プロジェクトをメイン リポジトリのリモート ブランチとして設定し、各プロジェクトからmaster、コア ファイルも含む (統合) ブランチにマージします。これにはある程度の規律が必要です。メイン リポジトリの外部プロジェクトに変更を加える場合は、ブランチで変更してからマスターにマージする必要があります。プロジェクトブランチにマージしたくありません。これにより、変更を外部プロジェクトに簡単に送り返すことができ、Git でのブランチの使用として完全に受け入れられます。

    共有スクリプトは、外部パートナーがリモート ブランチとしてプルおよびプッシュできる、メイン ディレクトリ内の別の独立したブランチとして処理できます。

SVN と Git を同じディレクトリで実行しようとすると、どちらのシステムでも分岐を使用することが非常に難しくなります。これは、Git がポインターを追跡している間に SVN がファイル ディレクトリをコピーして分岐を行うためです。どちらのシステムも、他のシステムで作成したブランチを自動的に認識しません。「解決策」は価値があるというよりは面倒だと思います。

于 2009-04-06T18:16:49.430 に答える
3

git を使用して、自分の github でホストされているプロジェクトと、使用したい外部 UI ライブラリをつなぎ合わせました。ライブラリは、sourceforge の Subversion リポジトリでホストされています。

私は git-submodule と git-svn を使用しましたが、かなりうまく機能しました。欠点は次のとおりです。

  1. ライブラリ リポジトリを最新の状態に保つために、新しいコミットを実行して、サブモジュールの git ハッシュ "ポインター" を更新する必要がありました。これは、svn:externals とは異なり、git サブモジュールが特定のコミット ID に固定されているためです。実際に安定版を固定したい場合、これは実際の欠点ではないかもしれません。私は WIP のコードで作業していました。

  2. サブモジュールを含む git リポジトリの最初のプルには、「git submodule init」を使用した追加の手順が必要です。これはあなたにとっては問題ではありませんが、あなたのコードを使用している他の人は、コードをコンパイル/実行/テストする前に、この手順を覚えておくか、実行するように指示する必要があります。

  3. コマンドラインを使用する場合、git-add でリポジトリを台無しにするのは簡単です。これは、入力して を補完git add subm<tab>するためですが、末尾のスラッシュに注意してください。末尾にスラッシュを付けてコマンドを実行すると、サブモジュールがブリッツされ、代わりにそれに含まれるすべてのファイルが追加されます。これは、git-gui を使用するか、スラッシュを削除するように自分自身をトレーニングすることで軽減されます (スラッシュを削除するようにトレーニングするのに十分な回数が発生しました)。git add submodulegit add submodule/git add .

  4. サブモジュールのコミットは git rebase -i を台無しにする可能性があります。正確な詳細は忘れましたが、「汚れた」サブモジュールがあり、rebase-interactive を実行した場合は特に悪いです。通常、ダーティ ツリーではリベースできませんが、サブモジュールはチェックされません。リベース グループに複数のサブモジュール コミットがあることも問題を引き起こします。最後のサブモジュール ハッシュは、リストの最初の選択にコミットされます。これを後で修正するのは非常に困難です。これは、より慎重なワークフロー (つまり、サブモジュールのコミットを行うタイミングを慎重に決定するなど) で回避できますが、PITA になる可能性があります。

これを設定する手順は、次のようなものでした。

  1. 走るgit svn clone https://project.svn.sourceforge.net/svnroot/project/project/trunk
  2. それを「実際の」gitプロジェクトとしてgithubなどにプッシュします
  3. 独自の git リポジトリで、次を実行します。git submodule init
  4. git submodule add git://github.com/project subproject
  5. 今度は自分のレポにもプッシュしてください。

多かれ少なかれ、それだけです。新しいディレクトリ「サブプロジェクト」が作成されます。この場合、これはジオマッピング ライブラリになります。

ジオマッピング コードを更新する必要があるたびに、次のように実行します。

cd subproject
git svn rebase
git svn push  # this updates the git mirror of the subproject
cd ..
git add subproject # careful with the trailing slash!
git commit -m "update subproject"
git push # this pushes the commit that updates the subproject

git サブモジュールのワークフローに関するチュートリアルはあまり見たことがないので、これがあなたの決定に役立つことを願っています。

于 2009-04-06T19:00:03.710 に答える
1

私がExternalsについて読んだ小さなことから、それはGITへのSVN'externals'の移植であるように見えます。

これにより、最新バージョンへの自動更新など、GITサブモジュールに関するいくつかの問題が解決されます。

私はSVNの外部やこのプロジェクトの経験はありませんが、投稿された他のどのプロジェクトよりも優れたソリューションになる可能性があります。

または、次のソフトウェア（GitHubで使用できるようです）。猫の皮を剥ぐ別の方法かもしれません： ブレード（Softpediaページ）

于 2009-04-16T16:48:55.067 に答える
0

作業しているプロジェクトの種類と、SCM と対話するために必要なツール (存在する場合) によって異なります。たとえば、Rails はしばしば Capistrano を使用してデプロイします。Capistrano は、ディレクトリ構造がリポジトリのルートに対してどのように見えるかについて、特定の仮定を行います。この場合、相互に関連する Rails アプリが複数ある場合は、サブモジュールを使用する必要があります。各アプリは独自のリポジトリを取得し、独立した各リポジトリをサブモジュールとして管理するより大きなリポジトリを作成します。

この種の仮定を行うツールを持っていなくても、将来大きなプロジェクトのサブセクションを独立して使用したり、再利用したりする可能性がわずかでもある場合は、リポジトリを適切に設計するには、物事を少し分割する必要があります。独立したプロジェクト内の大量のコード。

バージョン履歴を維持しながら、リポジトリの一部のサブセクションを独自の個別のエンティティとして抽出することは、git では難しいため、事前に計画することをお勧めします。

あなたの特定の質問については、正直なところ、いくつかのサブモジュールが理想的な場所の完璧な例と言えます。スクリプトの共有に関して、何らかの理由で実際に問題があることが判明した場合は、いつでもシンボリック リンクを使用できます。

于 2009-04-16T16:52:44.310 に答える