Web Applications Stack Exchange is a question and answer site for power users of web applications. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'd like to view the revision history of a Google Docs document using more flexible tools like Git, and possibly migrate some content from Google Docs into a Git project.

Google Docs has an API with access to the revision history, so this should be possible, for any of the variety of export formats it supports. I note, though, that there have been some API problems with revision history that mean that the list of contributors to each revision may not be complete, though they're considering fixing that:

Sometimes there are more than one editor (for a particular revision). Yet, the API always gives me one editor per revision.

Is there any code or advice on doing this available? Export to a different version control system like bzr, Mercurial, SVN or CVS would also be of interest.

This is related to the Stack Overflow question Version Control with Google Docs Best Practices?, which was closed as off-topic there.

share|improve this question
up vote 3 down vote accepted

Lars Kellog-Stedman created a great little python app called gitdriver which I found on this answer at StackOverflow. It does what you're looking for. It authenticates to Google with OAuth and pulls down all the revisions of a document, committing them to a git repository.

With this, you could fetch a versioned copy of your Google Doc and then work with it using traditional git tools.

share|improve this answer
Thank you! Looks great. – nealmcb Nov 13 '13 at 4:51

The Revisionator is another online document system (like google docs) but with built-in revision control. It resembles more flexible tools like git in that it has support for diffing, branching, and 3-way merging (but with a web gui front end).

IMHO, the Google docs revision history wouldn't be suitable for importing to a git project anyway. The problem is that there is no notion of a working copy. As people make changes, they are immediately reflected in the document and appended to the revision history. Viewing the history turns out to be an unholy mess.

The Revisionator (like bzr, mercurial, git, etc) has a notion of a working copy. Therefore, you can work on a change until it is ready to be released. When released it appears as one revision in the revision history (much more readable).

share|improve this answer
I agree that it is a challenge to deal with a large number of revisions like that, but it would at least seem possible to batch them up into bundles when there is a pause in the editing, or a change in who is making changes. – nealmcb Aug 10 '12 at 21:39
Maybe, but not if different people are editing the document at the same time. And even if you bunch them by time, there is no guarantee that the bunches represent a single logical change to the document. IE, I work on a revision, get pulled away. Come back later and fix it. People see 2 bunches of changes in the revision history (and the broken document in between). – jpalmucci Sep 6 '12 at 23:29

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.