Импортировать историю изменений документа Google Docs в Git-репозиторий?

Я хотел бы просмотреть историю изменений документа Google Docs с помощью более гибких инструментов, таких как Git, и, возможно, перенести некоторый контент из Google Docs в проект Git.

Документы Google имеют API с доступом к истории изменений, поэтому это должно быть возможно для любого из поддерживаемых форматов экспорта. Я отмечаю, однако, что были некоторые проблемы API с историей ревизий, которые означают, что список участников каждой ревизии может быть неполным, хотя они рассматривают исправление этого:

Иногда существует более одного редактора (для конкретной ревизии). Тем не менее, API всегда дает мне один редактор на ревизию.

Есть ли какой-либо код или совет по этому вопросу? Также будет интересен экспорт в другую систему контроля версий, такую ​​как bzr, Mercurial, SVN или CVS.

Это связано с вопросом переполнения стека Управление версиями с помощью Google Docs Best Practices? , который был закрыт как не по теме там.

Ларс Келлог-Стедман (Lars Kellog-Stedman) создал отличное маленькое приложение на python под названием gitdriver, которое я нашел в ответе на StackOverflow . Он делает то, что вы ищете. Он аутентифицируется в Google с помощью OAuth и извлекает все ревизии документа, передавая их в репозиторий git.

При этом вы можете получить версионную копию вашего Google Doc, а затем работать с ней, используя традиционные инструменты git.

Revisionator еще одна системы онлайна документа (например , Google Docs) , но со встроенной системой контроля версий. Он напоминает более гибкие инструменты, такие как git, в том, что он поддерживает диффузию, ветвление и трехстороннее объединение (но с интерфейсом веб-интерфейса).

ИМХО, история изменений документации Google не подходит для импорта в git-проект. Проблема в том, что нет понятия рабочей копии. Когда люди вносят изменения, они немедленно отражаются в документе и добавляются в историю изменений. Просмотр истории оказывается безобразным беспорядком.

Revisionator (например, bzr, mercurial, git и т. Д.) Имеет понятие рабочей копии. Следовательно, вы можете работать над изменением, пока оно не будет готово к выпуску. Когда выпущено, оно появляется как одна ревизия в истории ревизий (намного более читаемая).