I usually set up a screen session for each project. Vim is in window 0, and I use window 1 for a shell session. If I'm coding in a language that has a decent REPL I usually run that in window 2. Of course, you don't need screen to do this; you could do it with different terminal windows or with tabs in a multitab terminal. I do find screen to be more stable than other alternatives: if your terminal app crashes, you can just start another terminal and reconnect to your still-running screen session. screen is also very quick to navigate in once you learn it (much like vim itself).
I mostly end up using the shell session for complicated version control activities like rebasing or merging: simpler things can be done from vim's command line (e.g. :!git commit % -m 'Added info aboutscreen.') or by using the fugitive addon. I find fugitive's :Gmove (rename the current buffer both in vim and in the git index) and :Gdiff (invoke vimdiff on the current buffer with a previous point in its history) particularly useful. You can also do things like building up a commit message in a scratch buffer, copying in text from various parts of your code, and then committing with :%!git commit -F /dev/stdin
I'll also use the shell session for functional/integration testing if that's applicable to whatever I'm working on, for example if I'm writing a command-line utility.
Vim's quickfix functionality is useful for debugging, though there seems to be a different addon required for each language you might want to work in. They also seem to use a variety of invocation techniques, mapping to function keys or to key sequences starting with \ or ,, or to custom commands, or by being automatically invoked when a buffer is saved. So far I haven't really bothered to suss this out, and just read unit test or lint results into a scratch buffer using e.g. :r !python -m doctest whatever.py. Modify code, switch back to the scratch buffer, u to undo, then hit :r and the up arrow (most of the time) to get that command back. But it may be worth your while to seek out an addon for this, depending on what language you work in.
For popular compiled languages like C, java, etc., :make will do a build, and support for the quickfix list is well established. So you can then do :copen to display the quickfix buffer. It will show a list of errors, one per line; hitting Enter on a line will jump your other window to that point in that file.
If you're working with multiple projects at a time, you can do :lmake to arrange for a list of errors to be stored in the location list: this is like the quickfix list but is associated with a single window rather than being a singleton within your vim instance. :lopen will open a location list for the current window.
