In its simplest form, you can do as kilrah suggests, or even simpler, just wait for a CR (0x0D) and throw away the LF (0x0A) in your string parser.
If you want your device to be able to do things while that string's being received, or when the GPS isn't connected, then you need to look at how to deal with that.
Typically this is done in a "super loop" where main() has a while (1) loop which is continually checking the receive buffer for characters, and also doing other things, but key is that it doesn't block waiting for those characters. If there's a character, it adds it to a string, but it will always yield. If the character was a CR, it can parse the string, but it needs to be quick, it should not then sit around waiting to pump out characters for example.
You might have another task that flashes an LED for example, toggling it when a timer has reached a preset point, but again that task doesn't block, it only toggles if the timer state has reached that point since the last time it was polled.
Another way to do this is to implement the receiver in an interrupt service routine (ISR) triggered by an incoming character. It is generally considered good practice to keep the code in an ISR to a minimum, so although adding a character to a line buffer is a reasonable thing to do, parsing that string probably isn't, and I'd do that in my main super loop using a volatile flag set in the ISR when a CR is found. In this case I'd also operate two line buffers and flip between them so that the line that's being parsed isn't overwritten by new incoming characters.
In practice you'll usually find a combination of super loop and interrupts in all but the most trivial embedded real time implementations.