Can GCM be used in incremental mode? I want to sync blobs over the network and the most frequent change will be appending to blob. To minimize data amount sent I would prefer to encrypt appended data, send it over the network, append to encrypted blob and then decrypt whole blob at once when needed. Changes are very frequent and small, so storing each change independently possibly will have some performance issues.

Can I store counter along with blob and append to encryption using GCM with stored counter value (assuming it won't overflow/reset counter, which is obviously insecure)? Would GCM still provide authentication? Will this construction be secure (assuming correct implementation and key/IV selection)? What other options do I have?

P. S. I imagine this is easy done with CTR mode or any stream cipher, but they won't provide authentication.
I don't see any obvious way to do this without violating the security of GCM; at least, if you are at all concerned with an evesdropper (and if you're not, why are you encrypting at all?)

Here is a distallation of your requirements: you want to have the sender send the ciphertext (including nonce, ciphertext and tag).  Then, you want the sender to be able to send the edits to the ciphertext; the receiver applies these edits to its copy of the ciphyertext.  Then, the receiver decrypts this editted ciphertext, it gets an editted plaintext (and the editted tag authenticates if nothing was modified by a third party).  In your case, the edits to the plaintext are appending arbitrary texts; that's not important for this analysis.

However, one of the requirements for GCM is that you never allow an attacker access to two different ciphertexts generated with the same nonce/key pair.

So, if the modified ciphertext uses the same nonce (and key), then this is an obvious violation; someone listening into the exchange will gain the original ciphertext, and the editted version; that allows him to deduce the internal 'H' value (and thus allow him to generate his own ciphertexts).

On the other hand, if the modified ciphertext uses a different nonce (or key), the keystream used to encrypt the plaintext changes; the two keystreams are (one hopes) computationally indistinguishable from random, and so any edit will not be more efficient than just producing a new ciphertext to replace the old one.  Obviously, this would not meet the spirit of your requirements.

So, it appears that what you're trying to achieve would not be doable with GCM.

However, it turns out that, if you are not concerned with evesdropper, you could actually incrementally recompute the tag; I won't go into the details (in part because, as I said above, it generally is a bad idea).