Git + LaTeX рабочий процесс

Question

Я пишу очень длинный документ на LaTeX. У меня есть рабочий компьютер и ноутбук, и я работаю над ними обоими. Мне нужно, чтобы все файлы были синхронизированы между двумя компьютерами, а также я хотел бы сохранить историю изменений. Я выбрал git в качестве DVCS, и я размещаю свой репозиторий на своем сервере. Я также использую Kile + Okular для редактирования. У Кайла нет встроенного git-плагина. Я также не сотрудничаю ни с кем в этом тексте. Я также подумываю о том, чтобы добавить другой частный репозиторий в набор коде, если мой сервер по какой-то причине недоступен.

Какова рекомендуемая практика рабочего процесса в этом случае? Как ветвление может быть приспособлено в этой рабочей схеме? Есть ли способ сравнить две версии одного и того же файла? Как насчет использования тайника?

Answer 1

Изменения в вашем рабочем процессе LaTeX:

Первым шагом в эффективном управлении рабочим процессом git + latex является внесение нескольких изменений в ваши привычки LaTeX.

• Для начала напишите каждое предложение в отдельной строке . Git был написан в исходный код контроля версий, где каждая строка отличается и имеет определенное назначение. Когда вы пишете документы в LaTeX, вы часто думаете с точки зрения абзацев и пишете это как свободно распространяющийся документ. Однако в git изменения одного слова в абзаце записываются как изменения всего абзаца.

  Одним из решений является использование git diff --color-words ( см. Мой ответ на аналогичный вопрос, где я показываю пример). Тем не менее, я должен подчеркнуть, что разбиение на отдельные строки - гораздо лучший вариант (я упомянул об этом только в этом ответе), поскольку я нашел, что это приводит к очень минимальным конфликтам слияния.

• Если вам нужно взглянуть на код различий, используйте родной язык различий. Чтобы увидеть разницу между двумя произвольными коммитами (версиями), вы можете сделать это с sha s каждого из коммитов. См. документацию для получения более подробной информации, а также этот вопрос

  С другой стороны, если вам нужно взглянуть на разность вашего отформатированного вывода , используйте latexdiff, который является отличной утилитой (написанной на perl), которая занимает два латексные файлы и производит четкий вывод в формате PDF, как это ( источник изображения ):

  

  Вы можете объединить git и latexdiff (плюс latexpand при необходимости) в одну команду, используя git-latexdiff (например, git latexdiff HEAD^, чтобы просмотреть разницу между вашим рабочим деревом и последним -но один коммит).

• Если вы пишете длинный документ в латексе, я бы предложил разбить различные главы на их собственные файлы и вызвать их в основном файле с помощью команды \include{file}. Таким образом, вам легче редактировать локализованную часть вашей работы, а также легче управлять версиями, поскольку вы знаете, какие изменения были внесены в каждую главу, вместо того, чтобы выяснять это из журналов одного большого файл.

Эффективное использование git:

• Используйте ветки! . Возможно, нет лучшего совета, который я могу дать. Я обнаружил, что ветки очень полезны для отслеживания «разных идей» для текста или «разных состояний» работы. Ветвь master должна быть вашей основной частью работы, в ее наиболее актуальном состоянии «готовность к публикации», т. Е. Если из всех ветвей есть одна, на которую вы хотите поставить свое имя, это должна быть мастер ветка.

  Филиалы также чрезвычайно полезны, если вы аспирант. Как засвидетельствует любой аспирант, советник должен иметь множество исправлений, с большинством из которых вы не согласны. Тем не менее, можно ожидать, что по крайней мере пока что их изменит, даже если они будут отменены позже после обсуждений. Таким образом, в таких случаях вы можете создать новую ветку advisor и внести изменения по своему вкусу, в то же время поддерживая свою собственную ветку разработки. Затем вы можете объединить их и выбрать то, что вам нужно.

• Я бы также предложил разделить каждый раздел на отдельную ветвь и сосредоточить внимание только на том разделе, в котором вы находитесь. Создайте ветку, когда вы создаете новый раздел, или фиктивные, когда вы делаете первоначальный коммит (ваш выбор действительно). Не поддавайтесь желанию редактировать другой раздел (скажем, 3), когда вы не находитесь в его ветке. Если вам нужно отредактировать, передайте это, а затем извлеките другое, прежде чем переходить. Я нахожу это очень полезным, потому что он хранит историю раздела в своей собственной ветке, а также с первого взгляда сообщает вам (из дерева), сколько лет некоторому разделу. Возможно, вы добавили материал к разделу 3, который требует доработки к разделу 5 ... Конечно, они, по всей вероятности, будут наблюдаться во время внимательного прочтения, но я считаю полезным увидеть это с первого взгляда, чтобы я мог переключать передачи, если мне надоест участок.

  Вот пример моих веток и слияний из недавней статьи (я использую SourceTree в OS X и git из командной строки в Linux). Вы, вероятно, заметите, что я не самый частый коммиттер в мире, и при этом я не оставляю полезные комментарии все время, но это не причина для вас не следовать этим хорошим привычкам. Основная мысль о том, что работа в ветках полезна. Мои мысли, идеи и разработки развиваются нелинейно, но я могу отслеживать их через ветви и объединять их, когда я удовлетворен (у меня также были другие ветви, которые ни к чему не привели, которые впоследствии были удалены). Я также могу «пометить» коммиты, если они что-то значат (например, первоначальные публикации в журналы / пересмотренные публикации / и т. Д.). Здесь я пометил его как «версия 1», где и находится черновик. Дерево представляет собой труд на неделю.

  

• Еще одна полезная вещь, которую нужно сделать, - это сделать изменения в пределах документа (например, изменить \alpha на \beta везде) фиксацию самостоятельно. Таким образом, вы можете отменить изменения, не откатывая что-то еще вместе с ним (есть способы сделать это с помощью git, но, эй, если вы можете избежать этого, то почему бы и нет?). То же самое касается дополнений к преамбуле.

• Используйте удаленное репо и регулярно отправляйте свои изменения в апстрим. С такими бесплатными поставщиками услуг, как github и bitbucket (последний даже позволяет создавать частные репозитории с бесплатной учетной записью), нет никаких причин не использовать их, если вы работаете с git / mercurial. По крайней мере, рассмотрите это как вторичную резервную копию (я надеюсь, у вас есть основная!) Для ваших латексных файлов и сервис, который позволяет вам продолжить редактирование с того места, где вы ушли на другом компьютере.

Answer 2

У меня похожий рабочий процесс. Несмотря на то, что одновременно работает одна ветвь, я считаю полезным иметь отдельные ветки для разных состояний работы. Например, представьте, что отправляете хороший черновик своего документа своему консультанту. Тогда вы получите сумасшедшую идею! Вы хотите начать изменять некоторые основные концепции, переработать некоторые основные разделы и т. Д. И т. Д. Итак, вы переходите и начинаете работать. Ваша основная ветка всегда находится в состоянии «высвобождения» (или так близко, как вы находитесь в тот момент). Таким образом, в то время как ваша другая ветвь сумасшедшая и имеет некоторые радикальные изменения, если другой издатель хочет посмотреть, что у вас есть, или вы являетесь студентом, отправляющим на конференцию, основная ветка всегда доступна, готова к работе (или готова показать вашу консультант). Если ваш доктор PhD консультант хочет первым делом увидеть черновик утром, да, вы могли бы спрятать / поставить / зафиксировать свои текущие изменения, использовать теги или выполнить поиск по журналу, но почему бы не сохранить отдельные ветви?!

Допустим, ваша основная ветвь имеет «высвобождаемое» состояние вашей работы. Теперь вы хотите отправить его в несколько рецензируемых журналов, каждый из которых имеет разные требования к форматированию для одного и того же контента, и вы ожидаете, что они вернутся с несколькими различными небольшими критическими замечаниями о том, как вы можете редактировать статью, чтобы она подходила их читателям и т. Д. Вы можете легко создать ветку для каждого журнала, внести изменения в журнал, отправить их, а после получения отзыва внести изменения в каждую отдельную ветку.

Я также использовал Dropbox и git для создания системы, которую вы описали выше. Вы можете создать пустой репозиторий в папке Dropbox. Затем вы можете нажать / вытащить с любого компьютера на Dropbox, чтобы оставаться в курсе всех сторон. Эта система обычно работает только тогда, когда число соавторов невелико, поскольку существует вероятность повреждения, если люди пытаются одновременно запустить репозиторий Dropbox.

Технически вы также можете просто оставить ОДИН репозиторий в папке dropbox и выполнять всю свою работу оттуда. Однако я бы не одобрял это, так как люди упоминали, что у dropbox есть некоторые проблемы с синхронизацией файлов, которые постоянно меняются (gits внутренние файлы).

Answer 3

Я пытался реализовать это как функцию bash, я включил ее в ~/.bashrc, чтобы она всегда была доступна.

function git-latexdiff {    
    if [[ $# != 2 ]];    
    then      
        printf "\tusage: git-latexdiff <file> <back-revision>  \n";    
    elif [[ $2 -lt 0 ]];     
    then     
        printf "\t<Back-revision> must be positive\n";   
    else      
        dire=$(dirname $PWD/$1);      
        based=$(git rev-parse --show-toplevel);      
        git show HEAD~$2:$(echo $dire| sed 's!'$(echo $based)'/!!')/$1 > $1_diff.tmp;      
        latexdiff $1 $1_diff.tmp > $1_diff.tex;      
        pdflatex $1_diff.tex;     
        okular $1_diff.pdf;      
        rm $1_diff*;   
    fi; 
}

Обратите внимание, что для этой функции необходимо установить latexdiff (и найти ее в пути). Для него также важно найти pdflatex и okular.

Первый - мой предпочтительный способ обработки LaTeX, так что вы также можете переключить его на latex. Второй - мой читатель PDF, я полагаю, вы захотите использовать evince в gnome или другое решение.

Это быстрая версия, созданная для одного документа, и потому, что с помощью git вы потеряете много времени и усилий, отслеживая многофайловый документ LaTeX. Вы также можете разрешить git выполнять эту задачу, но при желании вы также можете продолжить использовать \include

Answer 4

Другой вариант - использовать Authorea , который является своего рода Github для научных работ.Каждая статья в Authorea - это Git-репо.И создаваемый вами LaTeX отображается в HTML5 (а также в PDF при компиляции).

Answer 5

используйте это для версии diff , если у вас Windows, без рассрочки, просто простой bat скрипт Отлично работает на windows10, miktex2.9:

https://github.com/redreamality/git-latexdiff