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


270

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

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

Ответы:


390

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


6
@ Диего: Сначала понадобилось немного привыкнуть, потому что твой разум просто хочет читать это постоянно. Тем не менее, это на самом деле проще, потому что я (и большинство людей) смотрю на аккуратный вывод латекса, чтобы увидеть, имеют ли предложения смысл, и для доказательства прочитайте его. Использование этих разрывов никак не влияет на результат и значительно упрощает анализ. Кроме того, вы можете связать вывод латекса с исходным файлом, поэтому, если вы обнаружите ошибку или опечатку, все, что вам нужно сделать, это щелкнуть по ней, и вы попадете прямо к соответствующей точке в источнике.
abcd

1
Я использую подобный подход, но как вы обрабатываете фигуры или другие двоичные файлы, может ли git обрабатывать их также или есть другой подход для файлов, которые должны быть включены в репо без отслеживания версий?
liborw 30.11.11

6
Это полезные советы, кроме одного, который я не вижу смысла: ветвь на раздел. Вы можете легко увидеть изменения для каждого файла, так зачем увеличивать сложность рабочего процесса, добавляя дополнительный уровень разделения? git [log|show|add] some_file.texвсе работает, нет необходимости добавлять постоянное переключение веток здесь. Вы все еще можете зафиксировать каждый файл самостоятельно, если хотите.
rubenvb

1
@rubenvb Если вы разбиваете каждый раздел на разные файлы, то да. Я обычно (и многие люди в академических кругах) работаю только с одним текстовым файлом на статью. Отдельные файлы имеют смысл для книг / тезисов, где каждая глава имеет значительный кусок материала. Конечно, это были только предложения ... каждый должен выбирать и отклонять советы в зависимости от того, что подходит их рабочему процессу :)
abcd

2
@ йода ах понятно. Да, тогда это имеет смысл. В любом случае, я склоняюсь к созданию нескольких текстовых файлов в журналах ;-).
rubenvb

12

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

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

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

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


3
Просто отметьте, что подача статьи для рецензирования в несколько журналов / конференций одновременно обычно не считается этичной!
Сверхъестественное

7

Я попытался реализовать это как функцию 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


Имейте в виду, что ссылки на LaTeX не будут вписываться в сгенерированные визуализации. А также, что сгенерированный файл удаляется в конце функции. Как я уже сказал, это быстрая версия.
Рафарино

1
Предложение об использовании latexdiff, называемого помощником gif, более полно в этом ответе на Использование latexdiffс git
juandesant

Что вы имеете в виду под "gif helper", @juandesant?
Рафарино,

1
Извините, @Rafareino, я имел в виду «git helper»: git helper - это инструмент, который может вызываться git для некоторых операций. В этом случае вы можете использовать latexdiffинструмент командной строки просто с помощью git diff, если вы настроите его правильно.
juandesant

3

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


Это старый поток, и идея состоит в том, чтобы разместить все на месте. Автора это круто, но не то, что я искал.
Иван

5
Вы должны ясно дать понять, что вы соучредитель
Authorea

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.