同様の問題を解決しようとしているVisualStudioソリューションの外部プロジェクトで作業している人としての私の経験をあなたと共有したいと思います。私はgitに比較的慣れていないので、誰かが建設的な批判を持っているなら、それをいただければ幸いです。
Visual Studioを使用している場合、Git Source Control Provider拡張機能は無料で（http://visualstudiogallery.msdn.microsoft.com/63a7e40d-4d71-4fbb-a23b-d262124b8f4c）、テストしたときにサブモジュールを再帰的にコミットしているように見えました。アウト。
ただし、自宅でVS Web Developer Expressを開発に使用しているので、拡張機能に依存したくありません（内部で何が起こっているのかを把握しておくことも良いと思います）。したがって、私はコマンドを理解することを余儀なくされました、そして私は以下にいくつかのメモを追加しました。
ノート
まだ読んでいない場合は、 http： //git-scm.com/book/en/Git-Tools-Submodulesをよく読んでください。注意点はかなりありますので、このページに戻って参照します。これを読まずにサブモジュールを操作しようとすると、すぐに頭痛の種になります。
私のアプローチはこのチュートリアルに従いますが、いくつかの追加機能があります：http: //blog.endpoint.com/2010/04/git-submodule-workflow.html
スーパープロジェクトを初期化したら（例：git init&& git remote add origin ...）、次のようにサブモジュールの追加を開始します。
git submodule add git://github.com/you/extension1.git extension
git submodule init
git submodule update
.gitmodulesファイルがこの追加を反映していることを確認してください。
[submodule "extension1"]
path = extension
url = git://github.com/you/extension1.git
サブモジュールディレクトリに切り替えます（つまりcd extension）。走る：
git fetch #I use fetch here - maybe you can use pull?
git checkout -b somebranchname #See the Git-Tools-Submodules link above for an explanation of why you need to branch
ここでREADME.txtに変更を加えてコミットできるようにし（また、このコミットで行ったことの記録を残すため）、モジュールをコミットしてブランチを適用しました（サブモジュールディレクトリ内にあります）。
git add .
git commit -a -m "Branching for extension submodule"
次に、スーパープロジェクト（つまりcd ..）に入ります。ここでもコミットする必要があります（私が言及したgitサブモジュールページを見ると、これが必要な理由が説明されています）：
git status #will show you that your submodule has been modified
git commit -a -m "Commiting submodule changes from superproject"
これで、必要に応じて、プロジェクトを次のように反省的にプッシュできます。
git push --recurse-submodules=on-demand
すべてのサブモジュールについて、上記の手順を1回実行する必要があります。
すべてのサブモジュールに対してこれを実行し、コミットしてプッシュする変更を加え始めたら、次を使用できます。
git submodule foreach 'git add .' #recursively add files in submodules
残念ながら、git-slave（誰か？）のようなものを使用せずに再帰的にコミットする方法が見つからなかったため、各サブモジュールディレクトリに移動して、追加したファイルに対して通常のコミットを実行する必要があります。スーパープロジェクトでは：
git status #tells you that `extension` submodule has been modified
cd extension
git commit -a -m "Commiting extension changes in superproject edit session"
サブモジュールがコミットしたら、スーパープロジェクトも（再度）コミットする必要があります。したがって、次のようになります。
cd ..
git add .
git commit -a -m "Altered extension submodule"
git status #should now show 'working directory clean', otherwise commit other submodules in the same manner
これは少し面倒になる可能性がありますが（2回コミットすることになるため）、一度気付いたら、実際にはそれほど悪くはありません（各プロジェクトでコミットしていることを確認する必要があるため）。私の意見ですが、スーパープロジェクトの機能の一部をサブモジュールに分離している場合は、とにかく残りのプロジェクトから分離して機能するはずです（したがって、煩わしいときに異なる時間にコミットすることは、世界の終わりではありません）。
今、もう一度プッシュすることができます...
git push --recurse-submodules=on-demand
その後、サブモジュールに移動してもう一度プッシュしようとすると、最新のコミットがすでにプッシュされているため、サブモジュールは何も実行しないことがわかります。
スーパープロジェクトのクローン作成（またはリモートオリジンの使用）も非常に混乱する可能性があります。たとえば、のgit submodule update後に2回実行する必要がありgit submodule initます。http://git-scm.com/book/en/Git-Tools-Submodulesの「サブモジュールを使用したプロジェクトのクローン作成」セクションをお読みください。
スーパープロジェクトのクローンを作成するときに気付いたのは、サブモジュールの最新の変更を取得することでした。すべてのサブモジュールの最新の簡単な方法を参照してください
これの私の変形は、チェックアウトされたサブモジュールに「開発」ブランチを使用し（ただし、好きなように呼び出すことができます）、スーパープロジェクトでこれを使用することです。
git submodule foreach git pull origin development
これを設定すると、次のように、チェックアウトされたサブモジュールで変更をプッシュしたいブランチにもスワップします。
cd extension
git checkout -b development #This will tell you this is a new branch, but I believe this means a new branch of the local git repository - this will get pushed to the 'development' branch
#Make your changes, commit etc.
上記の手順を実行すると、クローン/リモートオリジンプロジェクトのサブモジュールへの変更（プッシュされた場合）が、同じプロジェクトの他のクローン/リモートオリジンに表示されたことを確認できます（最後のサブモジュールプルコマンドを忘れないでください）。
それがお役に立てば幸いです。