リポジトリ内のGitリポジトリ
https://github.com/getyouridx/pychargify をDjangoプロジェクトにコピーします。時々更新する必要があります。
わかりやすくするために、Djangoプロジェクトの.gitignore: pychargify/.gitまたは他に注意すべき落とし穴はありますか？
あるgitリポジトリを別のgitリポジトリの「内側」にするには、gitサブモジュールを見てください。 http://git-scm.com/book/en/Git-Tools-Submodules
PychargifyをDjangoプロジェクトのサブモジュールにすることにより、Djangoプロジェクトの特定のリビジョンをpychargifyプロジェクトの特定のリビジョンに関連付けることができます。 。
あなたが説明するアプローチの危険性は正確にはわかりませんが、匂いテストには合格しません。私は、この種のことに特化して設計されたGit機能（サブモジュール）を使用することをお勧めします。
Gitには、別のリポジトリ内にリポジトリを保持する機能があります： submodules 。
git submodule add https://github.com/getyouridx/pychargify.git
サブモジュールの使用にはいくつかの癖があるので、サブモジュールに関するドキュメント全体を必ずお読みください。また、サブモジュールを初期化するために独自のリポジトリの新しいクローンを作成する際に実行する必要がある追加の手順があります。
また、すべてのサブモジュールコマンドは、リポジトリのルートディレクトリで実行する必要があることに注意してください。
Gitは自動的に無視し、.gitという名前のファイル/フォルダーを追加することさえ許可しません。したがって、レポ内にレポを追加して作業するだけです。ただし、内部リポジトリフォルダーpychargifyは無視する必要があります。
サブモジュールは、レポを複製する他の人とレポを共有したい場合に必要です。内部レポの複製を見て、他の誰も関与せずにローカルレポで作業している場合、またはレポを持ちたくない場合他の場所でも、サブモジュールは本当に必要ありません。
Gitサブツリー
Git submodules は一般的な方法であり、他の回答が持っているように、プロジェクト（レポ）を別のプロジェクト（レポ）に追加したい状況に対処するために、導入以来多くの基盤を獲得しています正しく説明されています。
それにもかかわらず、サブモジュールの方法が唯一の方法ではなく、時には確立されたワークフローに応じて適切な方法ではないことを主張することもできます。 this および this 。最も重要なのは間違いなくこれです：
Gitが競合解決モードに落ちても、サブモジュールポインターは更新されません。つまり、競合を解決した後にマージをコミットすると、同じ問題が発生します...：git submodule updateを実行し忘れた場合、 'マージしたブランチが行ったかもしれないサブモジュールのコミットを元に戻しました。
もちろん、完璧な作業フローでは、これは決して起こりません。
別の重要な理由は、人気のあるPyCharm IDE（これが書かれているとき;そのために非常に 古い問題 があります）そしておそらく他も同様にgitを完全に実装しないことですサブモジュールとコーダーは、サブモジュール内のすべての変更された行を表示するIDEの気の利いた機能をとりわけ失います。
したがって、この問題に対処する別の方法は、subtreesを使用することです。サブツリーと サブツリーのマージ はまったく同じではありませんが、これもまた別の問題です。優れた Progit book の第2版では、後者について簡単に説明していますが、前者についての単一のリファレンスではありません。
したがって、実際の例では、懸念される状況に対処するために、subprojectで消費されるprojectを想定します。
$ git remote add subproject_remote (url)
# subproject_remote is the new branch name and (url) where to get it from, it could be a path to a local git repo
$ git subtree add —-prefix=subproject/ subproject_remote master
# the prefix is the name of the directory to place the subproject
$ git commit -am "Added subproject"
# possibly commit this along with any changes
サブプロジェクトが変更された場合、それらをprojectにプルするには：
git subtree pull —prefix=subproject subproject_remote master
...またはその逆（subproject内のprojectで変更が行われた場合）：
git subtree Push —prefix=subproject subproject_remote new_branch
この link の分析的ではあるがかなり雑然としたチュートリアル。
この機能にはいくつかの欠点もあります。たとえば、多くの人は作業フローが面倒で複雑であると感じていますが、これも特定の確立されたワークフローに依存します。
別のgitプロジェクト内にgitプロジェクトを含むフォルダーを追加すると、期待どおりに機能します。それらの間に直接の相互作用はなく、いずれかのディレクトリで作業することにより、変更を個別にコミットできます。 「親」プロジェクトに内部フォルダーを完全に無視させるか、親フォルダーの一部であるかのように子フォルダーから選択したファイルをコミットすることができます。
後者の場合、ファイルを変更すると、両方のgitプロジェクトによって変更されたと見なされ、いずれかのディレクトリで作業するだけで、それらの変更を個別に管理（変更をコミット）できます。
ここでコマンドラインツールを使用していると仮定していますが、XCode 7は状況を理解し、ファイルが一方または両方のgitリポジトリによって変更されていると見なされる限り、ファイルに変更注釈を表示する可能性があると思います。
上記の手順はサブモジュールを処理するよりも簡単ですが、他の人はサブモジュールを使用する方法についてコメントしているので、比較してください。