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

Ответ 1

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

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

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

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

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

  С другой стороны, если вам нужно посмотреть на отличие отформатированного вывода, используйте 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. По крайней мере, рассмотрите его как дополнительную резервную копию (надеюсь, у вас есть основной) для ваших латексных файлов и службы, которая позволяет продолжить редактирование с того места, где вы оставили на другой машине.

Ответ 2

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

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

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

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

Ответ 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

Ответ 4

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

Ответ 5

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

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