git + flusso di lavoro LaTeX

Sto scrivendo un documento molto lungo in LaTeX. Ho il mio computer di lavoro e il mio laptop, e lavoro su entrambi. Devo mantenere tutti i file sincronizzati tra i due computer e vorrei anche mantenere una cronologia delle revisioni. Ho scelto git come DVCS e sto ospitando il mio repository sul mio server. Sto anche usando Kile + Okular per fare il montaggio. Kile non ha un plugin git integrato. Inoltre, non sto collaborando con nessuno su questo testo. Sto anche pensando di mettere un altro repository privato su codaset, se il mio server per qualche motivo non è accessibile.

Qual è la pratica del flusso di lavoro consigliata in questo caso? Come si possono inserire le ramificazioni in questo schema di lavoro? C'è un modo per confrontare due versioni dello stesso file? Che ne dici di usare una scorta?

Modifiche al flusso di lavoro LaTeX:

Il primo passo nella gestione efficiente di un flusso di lavoro Git + LaTeX è apportare alcune modifiche alle abitudini di LaTeX.

• Per cominciare, scrivi ogni frase su una riga separata . Git è stato scritto nel codice sorgente del controllo versione, in cui ogni riga è distinta e ha uno scopo specifico. Quando scrivi documenti in LaTeX, spesso pensi in termini di paragrafi e lo scrivi come un documento a flusso libero. Tuttavia, in git, le modifiche a una singola parola in un paragrafo vengono registrate come modifiche all'intero paragrafo.

  Una soluzione è quella di usare git diff --color-words(vedi la mia risposta a una domanda simile Come usare Mercurial per il controllo della versione dei documenti di testo? Dove mostro un esempio). Tuttavia, devo sottolineare che la suddivisione in righe separate è un'opzione molto migliore (l'ho menzionata solo passando in quella risposta), poiché l'ho trovata per provocare conflitti di fusione molto minimi.

• Se hai bisogno di guardare il codice diff, usa il diff nativo di Git. Per vedere la differenza tra due commit arbitrari (versioni), puoi farlo con la shas di ciascuno dei commit. Vedere la documentazione per maggiori dettagli e anche Mostrare quali file sono stati modificati tra due revisioni .

  D'altra parte, se hai bisogno di guardare il diff dell'output formattato , usa latexdiffun'utilità eccellente (scritta in perl) che prende due file in lattice e produce un output diffuso in pdf come questo ( fonte di immagine ):

  

  Puoi combinare gite latexdiff(più latexpandse necessario) in un singolo comando usando git-latexdiff (ad esempio git latexdiff HEAD^per visualizzare la differenza tra il tuo worktree e l'ultimo-ma-uno commit).

• Se stai scrivendo un lungo documento in LaTeX, suggerirei di dividere diversi capitoli nei propri file e di chiamarli nel file principale usando il \include{file}comando. In questo modo è più facile per te modificare una parte localizzata del tuo lavoro ed è anche più facile per il controllo della versione, poiché sai quali modifiche sono state apportate a ciascun capitolo, invece di doverlo capire dai registri di un grande file.

Usare Git in modo efficiente:

• Usa i rami! . Forse non esiste un consiglio migliore che posso dare. Ho trovato molto utili i rami per tenere traccia di "idee diverse" per il testo o per "stati diversi" dell'opera. Il masterramo dovrebbe essere il tuo corpo principale di lavoro, nel suo stato più attuale di "pronto per la pubblicazione", cioè, se di tutti i rami, se ce n'è uno che sei disposto a mettere il tuo nome su di esso, dovrebbe essere il ramo principale.

  Le filiali sono anche estremamente utili se sei uno studente laureato. Come attesterà qualsiasi studente laureato, il consulente è tenuto ad avere numerose correzioni, la maggior parte delle quali non sei d'accordo. Tuttavia, ci si potrebbe aspettare almeno li cambino per il momento, anche se vengono ripristinati più tardi dopo le discussioni. Pertanto, in questi casi, è possibile creare un nuovo ramo advisore apportare modifiche a proprio piacimento, mantenendo allo stesso tempo il proprio ramo di sviluppo. Puoi quindi unire i due e scegliere quello che ti serve.

• Suggerirei anche di dividere ogni sezione in un ramo diverso e focalizzare solo la sezione corrispondente al ramo su cui ti trovi. Genera un ramo quando crei una nuova sezione o sezioni fittizie quando effettui il commit iniziale (la tua scelta, davvero). Resistete alla tentazione di modificare una sezione diversa (diciamo, 3) quando non siete sul suo ramo. Se devi modificare, esegui il commit di questo e poi verifica l'altro prima di diramare. Lo trovo molto utile perché mantiene la storia della sezione nel suo ramo e ti dice anche a colpo d'occhio (dall'albero) quanti anni ha una sezione. Forse hai aggiunto materiale alla sezione 3 che richiede modifiche alla sezione 5 ... Naturalmente, questi, con tutta probabilità, saranno osservati durante un'attenta lettura, ma trovo utile vederlo a colpo d'occhio in modo da poter cambiare marcia se io'

  Ecco un esempio dei miei rami e si fonde da un recente documento (utilizzo SourceTree su OS X e Git dalla riga di comando su Linux). Probabilmente noterai che non sono il committer più frequente al mondo, né lascio sempre commenti utili, ma non è un motivo per non seguire queste buone abitudini. Il messaggio principale da asporto è che è utile lavorare nei rami. I miei pensieri, idee e sviluppo procedono in modo non lineare, ma posso tenerne traccia tramite i rami e unirli quando sono soddisfatto (ho avuto anche altri rami che non hanno portato da nessuna parte che sono stati successivamente eliminati). Posso anche "taggare" i commit se significano qualcosa (ad esempio, invii iniziali a riviste / invii modificati / ecc.). Qui, l'ho taggato "versione 1", che è dove la bozza è fin d'ora. L'albero rappresenta una settimana '

  

• Un'altra cosa utile da fare sarebbe apportare modifiche ampie al documento (come passare \alphaa \betaovunque) per conto proprio. In questo modo, puoi ripristinare le modifiche senza dover eseguire il rollback di qualcos'altro insieme ad esso (ci sono modi in cui puoi farlo usando git, ma ehi, se puoi evitarlo, allora perché no?). Lo stesso vale per le aggiunte al preambolo.

• Utilizzare un repository remoto e inviare periodicamente le modifiche a monte. Con fornitori di servizi gratuiti come GitHub e Bitbucket (entrambi consentono di creare repository privati ​​con un account gratuito), non c'è motivo di non utilizzarli se si lavora con Git / Mercurial. Per lo meno, consideralo come un backup secondario (spero che tu ne abbia uno primario!) Per i tuoi file LaTeX e un servizio che ti permetta di continuare la modifica da dove hai lasciato su una macchina diversa.

Ho anche un flusso di lavoro simile. Anche se si sta lavorando a un ramo alla volta, trovo utile avere rami separati per diversi stati di lavoro. Ad esempio, immagina di inviare una buona bozza del tuo documento al tuo consulente. Quindi, hai un'idea folle! Volete iniziare a cambiare alcuni concetti chiave, rielaborare alcune sezioni principali, ecc. Ecc. Quindi vi ramificate e iniziate a lavorare. Il tuo ramo principale è sempre in uno stato "rilasciabile" (o vicino come sei in quel momento). Quindi, mentre l'altro tuo ramo è pazzo e ha alcuni cambiamenti drastici, se un altro editore vuole vedere quello che hai, o sei uno studente che si sottopone a una conferenza, il ramo principale è sempre rilasciabile, pronto a partire (o pronto a mostrare il tuo consulente). Se il tuo dottorando vuole vedere la bozza per prima cosa al mattino,

Supponiamo che il tuo ramo principale abbia lo stato "rilasciabile" del tuo lavoro. Ora vuoi inviarlo a diverse riviste peer-reviewed, ognuna con requisiti di formattazione diversi per lo stesso contenuto e ti aspetti che tornino con diverse e piccole critiche su come modificare il documento per adattarlo ai loro lettori, ecc. È possibile creare facilmente una filiale per ogni giornale, apportare modifiche specifiche al giornale, inviare e, quando si riceve il feedback, apportare le modifiche su ciascun ramo separato.

Ho anche usato Dropbox e git per creare il sistema che descrivi sopra. È possibile creare un repository bare-bones nella cartella dropbox. Puoi quindi spingere / estrarre da entrambi i computer nel tuo dropbox per rimanere aggiornato su tutti i fronti. Questo sistema di solito funziona solo quando il numero di collaboratori è ridotto poiché esiste la possibilità di corruzione se le persone provano a inviare contemporaneamente al repository dropbox.

Tecnicamente potresti anche mantenere UN solo repository all'interno della cartella dropbox e fare tutto il tuo lavoro da lì. Vorrei scoraggiare questo, tuttavia, poiché la gente ha detto che Dropbox ha qualche problema a sincronizzare i file che cambiano costantemente (gits file interni).

Ho provato a implementarlo come una funzione bash, l'ho incluso nel mio ~/.bashrcper renderlo sempre disponibile.

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; 
}

Nota che questa funzione deve latexdiffessere installata (e trovata sul percorso). È anche importante trovare pdflatexe okular.

Il primo è il mio modo preferito per elaborare LaTeX, in modo da poterlo seguire anche tu latex. Il secondo è il mio lettore PDF, suppongo che vorrai usare evincesotto gnome, o qualche altra soluzione.

Questa è una versione rapida, creata pensando a un singolo documento, e questo perché con git, perderai molto tempo e fatica nel tracciare un documento LaTeX a più file. Puoi lasciare che git esegua anche questa attività, ma se vuoi, puoi anche continuare a usare\include

Un'altra opzione è quella di utilizzare Authorea che è una specie di Github per articoli scientifici. Ogni articolo di Authorea è un repository Git. E il LaTeX che componi viene reso in HTML5 (così come in PDF, quando lo compili).

utilizzare questo per la versione diff nel caso in cui ci si trovi su Windows, nessuna rata, solo un semplicebat script Funziona perfettamente su Windows 10, miktex2.9:

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