その1でsubmoduleをaddし、git-submodule statusコマンドでステータスを確認するところまでの作業をしました。
今度はaddした以外の人がpullして、submoduleを確認するところを書いてみます。

submoduleを取得：init & update

   1  git pull --rebase #submoduleを追加したコミットを取得
   2  git submodule 
   3  -e110f2056783465b8d719bdb1ab5fd14e7650f56 vendor/plugins/rspec

(-がついているので)この時点ではrspec submoduleが初期化されていません。よって下記のコマンドで初期化します：

   1  git submodule init
   2  git submodule update

又は

   1  git submodule update --init

updateすることによりソースファイルを取得します。
これで、addした以外の人もsubmoduleを追加することができました。しかし、まだこれで終わりではなくて実はいくつか検討すべき点があります：

• submoduleに修正を加えないかどうか
• どのバージョンを使うか：commit hash
• (railsの)deployはどうするか：Capistrano
• submoduleの削除

外部のrepoをそのままか、forkしてからか

submoduleをaddする前に検討すべき事項です(!)：
追加するremoteリポジトリを変更したくなる可能性があるかどうか検討する必要があります。例えばrailsやrspecなら変更を加えるというのはほとんどないように思われますが、完成度の低いpluginだと自分で修正したり、追加したりすることが考えられます。そのような場合、下記のようなシナリオが考えられます：

1. remoteをsubmodule(変更しない)
2. Githubであればforkして、それをsubmoduleにする
3. 自分のローカルにcloneして、それをsubmoduleにする
4. サーバにrepoを作ってremoteのファイルを追加、それをsubmoduleにする

1,2はなんとなく想像できますが、3,4は運用が面倒そうです...
また、railsまでsubmoduleにする記事もあったのですが、毎回deploy時にコピーすることになるのでdeployに時間がかかるだろうし、容量も食うので運用には向いていないかもしれません。

どのコミットをsubmoduleとして採用するか

submoduleを利用する際、外部のbleeding edgeブランチを積極的に採用したくはありません。なので、タグか特定のバージョン(コミット)を利用するのが適切です：

   1   cd vendor/plugins/rspec/rspec
   2   git tag 
   3  1.1.10
   4  (略)
   5  1.2.1
   6  1.2.2
   7   git checkout 1.2.2
   8   cd ../../..

rspecのタグ1.2.2を採用しました。このあとRAILS_ROOTに戻ってcommit, pushすればokです。
この後、他の人がこの変更を反映するには下記の作業を行います：

   1  git pull --rebase #submoduleを追加したコミットを取得
   2  git submodule update

Capistranoでsubmoduleを使えるようにする

一行追加するだけ！

   1  set :git_enable_submodules, 1

via http://github.com/guides/deploying-with-capistrano

submoduleの削除

rspecを例に：

1. .gitmodulesファイルから該当する行を削除
   

      1  [submodule "vendor/plugins/rspec"]        
      2  path = vendor/plugins/rspec        
      3  url = git://github.com/dchelimsky/rspec.git
   

2. .git/configファイルから該当する行を削除
   

      1  [submodule "vendor/plugins/rspec"]        
      2  url = git://github.com/dchelimsky/rspec.git
   

3. git rm --cached path_to_submodule
   パスの最後に/(スラッシュ)がない状態で：
   

      1  git rm --cached vendor/plugins/rspec
   

4. git commit、pushでおしまい

via http://git.or.cz/gitwiki/GitSubmoduleTutorial

.gitmodulesファイル

初めてsubmoduleを追加すると、下記のファイルが追加されます：

   1  .gitmodules

その他に.git/configも変更されます。

submoduleをもっとよく理解するRefs

• ここの解説が一番わかりやすかったです：
  http://woss.name/2008/04/09/using-git-submodules-to-track-vendorrails/
• vendor/railsにsubmodule使おうぜ！という...！
  http://woss.name/2008/04/11/using-git-submodules-to-track-vendorrails-2/
• submoduleがうまく動かなかったレポート
  http://blog.buildingwebapps.com/2008/5/20/got-git-submodules-not-a-go-go