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

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

Яка рекомендована практика робочого процесу в цьому випадку? Як розгалуження можна вписати в цю робочу схему? Чи є спосіб порівняти дві версії одного файлу? А як щодо використання сховища?

Зміни у вашому робочому процесі LaTeX:

Перший крок у ефективному управлінні робочим процесом git + - це внести кілька змін у свої звички LaTeX.

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

  Одне рішення - використовувати git diff --color-words( див. Мою відповідь на подібне запитання, де я показую приклад). Однак я мушу підкреслити, що розділення на окремі рядки є набагато кращим варіантом (я згадував це лише у цій відповіді), оскільки я виявив, що це призводить до мінімальних конфліктів злиття.

• Якщо вам потрібно розібратися в коді diff, використовуйте натиснуту програвач git. Щоб побачити різницю між двома довільними комітами (версіями), ви можете зробити це за допомогою shas кожного з комітетів. Детальнішу інформацію див. У документації, а також це питання

  З іншого боку, якщо вам потрібно розглянути різницю вашого форматованого виводу , використовуйте 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. Як мінімум, розгляньте це як вторинну резервну копію (сподіваюся, у вас є первинна!) Для ваших файлів латексу та послугу, яка дозволяє продовжувати редагування з того місця, де ви залишилися на іншій машині.

У мене також схожий робочий процес. Незважаючи на те, що одночасно працює над одним відділенням, я вважаю вигідним мати окремі відділення для різних станів роботи. Наприклад, уявіть, що ви надсилаєте своєму радникові гарний чорновий проект документа. Тоді ви отримуєте шалену ідею! Ви хочете почати змінювати деякі основні поняття, переробляти деякі основні розділи тощо. Отже, ви відгалужуєтесь і починаєте працювати. Ваша головна гілка завжди перебуває у "звільненому" стані (або настільки ж близько, як ви знаходитесь у цей момент). Тож поки ваша інша філія божевільна і має кардинальні зміни, якщо інший видавець хоче побачити, що у вас є, або ви студент, який подає на конференцію, головна гілка завжди випускається, готова до запуску (або готова показати свій радник). Якщо ваш доктор філософських наук хоче вранці побачити проект,

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

Я також використовував Dropbox і git для створення системи, яку ви описали вище. Ви можете створити сховище з голими кістками у папці, що випадає. Потім ви можете натиснути / потягнути з будь-якого комп’ютера на свій скриньку, щоб бути в курсі всіх кінців. Ця система, як правило, працює лише тоді, коли кількість співпрацівників невелика, оскільки існує можливість корупції, якщо люди одночасно намагаються перейти на репо-скриньку.

Технічно ви також можете просто зберігати ОДНЕ сховище всередині папки, що випадає, і виконувати всю свою роботу звідти. Однак, я б заперечував це, оскільки люди згадували, що в папці "скринька" виникають певні проблеми з синхронізацією файлів, які постійно змінюються (gits внутрішні файли).

Я намагався реалізувати це як функцію 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

Іншим варіантом є використання Authorea, який є певною мірою Github для наукових робіт. Кожна стаття в Authorea - це Gito repo. І LaTeX, який ви складаєте, перетворюється на HTML5 (як і PDF, коли ви компілюєте).

використовувати це для версії розл якщо ви перебуваєте на Windows, без розстрочки, просто простий batскрипт. Він прекрасно працює на windows10, miktex2.9:

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