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).