You drank the Kool-Aid. You're now using Git as the version control (VCS) system for managing your Drupal projects. It works well enough, but wasn't it supposed to be the ultimate solution to versioning your code? Is it? If you're asking those questions, then you're probably wondering why you still need to deal with the following issues.
- Drupal.org is using Git for contributed modules, but you can't use Git to merge upstream changes into contributed module folders in your single Git repository. You have to manually download a new version of each, unpack and then commit.
- You can't see upstream version history (commits) in your Git log. All you can see are local changes and "Upgraded Blah from 2.3 to 2.4." log messages. Youi're not sure if specific upstream commits are included or not.
- You upgrade a module. A while later, you realize that some custom changes you've made have disappeared. Then you realize that you forgot to reapply custom commits (cherry-picking) after you upgraded the module.
Well, it turns out that these problems are entirely avoidable. You've simply been using Git in a less-than-optimal way. To deal with all of these issues, you need to take advantage of Git submodules which let you handle contributed modules (or themes, etc., if you're into that sort of thing) as nested Git repositories within your main project repository.
I'll briefly discuss some of the conventional methods for managing Drupal projects (the single Git repo, Drush makefiles, etc.) along with their pros and cons, and then I'll explain how you can get set up with submodules and work your standard processes. Afterwards, you'll be firmly convinced that it's the way to go. Rejoice!