There are many command line development tools that will be useful to the prospective Gnome developer. These are perhaps less likely to be used by those who are developing their own applications using Gnome libraries, but I feel that most would still be very useful. Among these tools are:
In order to contribute to most any Gnome application or library, Gnome developers will need to become familiar with cvs. It is fairly big and takes a little while to learn so you do not need to learn it yet, but you will probably need to learn at least the basics before long. Gnome has a good tutorial on CVS at http://developer.gnome.org/tools/cvs.html. Before that page had all the useful information that it does now, I wrote up my own tutorial (which was meant for a slightly different audience and which also includes information on how to set up your own CVS server for access over ssh).
cvs has many features and a lot of annoying quirks. Running 'info cvs' or reading a long tutorial such as http://cvsbook.red-bean.com/cvsbook.html can help if you find that you need to know more.
It may also be useful to learn an alternative revision control system, such as Gnu Arch. Gnu Arch overcomes the many shortcomings of CVS and provides a lot of new capabilities as well. A number of projects are starting to use it, either in addition to or instead of CVS. (This tutorial is such an example.)
Devhelp is a bit different than the other tools listed here. It is an API documentation browser for Gnome. It can be great for viewing API documentation locally, though personally I tend to just look at in on the web at http://developer.gnome.org/doc/API/ (and perhaps combine it with some Google searches). More info about devhelp can be found at http://www.imendio.com/projects/devhelp/.
diff is important to learn for making and understanding patches, which is absolutely necessary for those who want to contribute to existing Gnome applications and libraries. I have a short overview.
find is oftentimes useful when looking for specific files or trying to execute a certain command on a whole bunch of files. You could easily skip it, but it is a command that I have found very useful under many circumstances. I have a short overview.
Unfortunately, grep has been completely indispensable to me. I say that because I have used grep to overcome incomplete, missing, or outdated documentation. I really hope that the documentation situation improves so that grep does not need to be so useful to others in the future. Running grep many times on various keywords and function names has helped me unravel how many things worked.
grep can still very useful in becoming familiar with the code for a specific application, even when the code and the application are well documented. If you are just trying to fix a bug in an application but do not want to spend much time becoming familiar with the entire codebase, grep can help you: find where a certain string occurs, locate where variables or functions are declared, find locations in the code where functions or variables are used, and a number of other things.
locate is similar to find in that it is oftentimes useful when looking for a specific file. locate will be much faster than find at this, but it will only work if the database of your files was updated after the file you are searching for was made. Some linux systems do not have the slocate database even set to be generated every night. However, if it is set up to run, then this can make searching for files very quick. I have a short overview. As a tip for advanced usage, lookup xargs in the man pages sometime; locate combined with xargs can be used to run a command on a whole bunch of files.
make is one of the programs used very heavily in order to build software. You might be able to get away with knowing nothing more than the fact that running "make" and "make install" will usually build software for now, but you will almost definitely need to eventually learn at least the basics of creating makefiles. A good basic tutorial that I have shown to others can be found at http://www.cs.utah.edu/classes/cs5630/resources/ElementsOfMake.ps.
Hand written makefiles tend to be simple and straightforward and can serve as good examples to learn from, but it is a bad idea to try to use makefiles that are automatically generated by configure as examples as they tend to be very long and complicated due to the necessities of being portable and having flexible build options.
patch is used to apply a patch (which is created by diff). I have a short overview.
pkg-config is used to obtain compilation and linking flags needed for various libraries. These are often very long and pkg-config was just a simple tool to make it easier to get all of these so that users didn't have to do large amounts of cutting-and-pasting or typing (and repeated fixing when those flags changed later). It is pretty simple to learn and use. I have a short overview.
Shell scripting is not something that you will need to know (at least not right away), but it is something that can come in handy in a variety of situations and which can make you more productive. The most common shell is bash, for which a simple HOWTO such as http://www.tldp.org/HOWTO/Bash-Prog-Intro-HOWTO.html will cover the relevant details.