SQL Server : Log File Shrink
In addition to your Full and Incremental/Differential backups you should be doing a backup on the transaction log in a reasonable frequency to mark all locations in the log file with committed entries as available for reuse instead of doing a truncation on the log file.  With a correctly sized log file the transaction log backups will help to keep your log file from growing continuously and might only grow if it a larger volume of changes come in between backups windows then you predicted for.

Now on to log file shrinking.  Shrinking your log file is not necessarily bad it will just take a bit of planning to do it correctly.  (Make sure you are doing this in a maintenance window with a full backup before you begin and if at all possible without any other users connected.) You can use the DBCC shrink command on it to get it down to 1MB but right after you should regrow the log file back to a size that is appropriate for the rate of change that is happening in your database plus a free space buffer to handle larger than normal amounts of data changes.  Also growing the log file in specific consistent increments will create evenly sized VLFs that can help with log performance.  For example after you shrink it down to 1MB you regrow the log file in 1GB increments until you hit 5GB in size.  

Kimberly Tripp has a couple of good articles explaining VLFs and transaction log throughput that might be helpful to read over.  Do take note of her warning about a bug in growing the log file by 4GB.  

Here is another VLF reference from Brent Ozar that has some more details and also references Kimberly's posts. 

It's worth noting, Thanks @BradC, that shrinking and regrowing your log file should only have to be done once or only if your log file grows causing unevenly sized VLFs.  But if you set your auto growth size on the log file to the specific size increments that use used to originally grow it back from 1MB you shouldn't see uneven VLFs even after it auto grows.