git + LaTeX Arbeitsablauf

Question

Ich schreibe gerade ein sehr langes Dokument in LaTeX. Ich habe einen Arbeitscomputer und einen Laptop, und ich arbeite an beiden Computern. Ich muss alle Dateien zwischen den beiden Computern synchronisieren und möchte auch eine Revisionshistorie führen. Ich habe mich für Git als DVCS entschieden, und mein Repository liegt auf meinem Server. Außerdem verwende ich Kile und Okular für die Bearbeitung. Kile hat kein integriertes Git-Plugin. Ich arbeite auch mit niemandem an diesem Text zusammen. Ich denke auch darüber nach, ein weiteres privates Repository auf codaset einzurichten, falls mein Server aus irgendeinem Grund nicht erreichbar ist.

Was ist in diesem Fall die empfohlene Vorgehensweise? Wie kann die Verzweigung in dieses Arbeitsschema eingepasst werden? Gibt es eine Möglichkeit, zwei Versionen der gleichen Datei zu vergleichen? Wie sieht es mit der Verwendung eines Stash aus?

Answer 1

Änderungen an Ihrem LaTeX-Arbeitsablauf:

Der erste Schritt zur effizienten Verwaltung eines Git+LaTeX-Workflows besteht darin, ein paar Änderungen an Ihren LaTeX-Gewohnheiten vorzunehmen.

• Für den Anfang, jeden Satz in eine eigene Zeile schreiben . Git wurde für die Versionskontrolle von Quellcode geschrieben, bei der jede Zeile eindeutig ist und einen bestimmten Zweck erfüllt. Wenn man Dokumente in LaTeX schreibt, denkt man oft in Absätzen und schreibt es als ein frei fließendes Dokument. In Git werden jedoch Änderungen an einem einzelnen Wort in einem Absatz als Änderung des gesamten Absatzes aufgezeichnet.

  Eine Lösung ist die Verwendung von git diff --color-words (siehe meine Antwort auf eine ähnliche Frage Wie kann man Mercurial für die Versionskontrolle von Textdokumenten verwenden? wo ich ein Beispiel zeige). Ich muss jedoch betonen, dass die Aufteilung in getrennte Zeilen eine viel bessere Option ist (ich habe sie in dieser Antwort nur am Rande erwähnt), da ich festgestellt habe, dass sie zu sehr geringen Konflikten beim Zusammenführen führt.

• Wenn Sie sich den Code-Diff ansehen möchten, verwenden Sie das Git-eigene Diff. Um den Unterschied zwischen zwei beliebigen Commits (Versionen) zu sehen, können Sie das mit der sha s der einzelnen Commits. Siehe die Dokumentation für weitere Einzelheiten und auch Anzeigen, welche Dateien sich zwischen zwei Revisionen geändert haben .

  Andererseits, wenn Sie sich die Diffs Ihrer formatierte Ausgabe verwenden latexdiff ist ein ausgezeichnetes (in Perl geschriebenes) Dienstprogramm, das zwei Latex-Dateien nimmt und eine saubere, differenzierte Ausgabe im PDF-Format erzeugt, etwa so ( Bildquelle ):

  

  Sie können kombinieren git y latexdiff (plus latexpand falls erforderlich) in einem einzigen Befehl mit git-latexdiff (z.B.. git latexdiff HEAD^ um den Unterschied zwischen Ihrem Arbeitsbaum und dem vorletzten Commit zu sehen).

• Wenn Sie ein langes Dokument in LaTeX schreiben, würde ich vorschlagen Aufteilung verschiedener Kapitel in eigene Dateien und rufen sie in der Hauptdatei mit der Option \include{file} Befehl. Auf diese Weise ist es für Sie einfacher, einen lokalisierten Teil Ihrer Arbeit zu bearbeiten, und es ist auch einfacher für die Versionskontrolle, da Sie wissen, welche Änderungen an den einzelnen Kapiteln vorgenommen wurden, anstatt dies aus den Protokollen einer großen Datei herausfinden zu müssen.

Git effizient nutzen:

• Verwenden Sie Zweige! . Es gibt vielleicht keinen besseren Rat, den ich geben kann. Ich habe festgestellt, dass es sehr hilfreich ist, "verschiedene Ideen" für den Text oder für "verschiedene Stadien" des Werks festzuhalten. Die master Zweig sollte Ihr Hauptwerk sein, in seinem aktuellsten "veröffentlichungsreifen" Zustand, d.h. wenn es von allen Zweigen einen gibt, den Sie bereit sind, mit Ihrem Namen zu versehen, sollte es der Master-Zweig sein.

  Zweigstellen sind auch extrem hilfreich, wenn Sie ein Doktorand sind. Wie jeder Doktorand bestätigen kann, wird der Betreuer sicherlich zahlreiche Korrekturen vornehmen, mit denen Sie meist nicht einverstanden sind. Dennoch könnte von Ihnen erwartet werden, dass Sie zumindest sie vorläufig zu ändern, auch wenn sie später nach Diskussionen rückgängig gemacht werden. In solchen Fällen könnten Sie also einen neuen Zweig erstellen advisor und Änderungen nach ihrem Geschmack vornehmen, während Sie gleichzeitig Ihren eigenen Entwicklungszweig pflegen. Sie können dann die beiden Zweige zusammenführen und sich das herauspicken, was Sie brauchen.

• Ich würde auch vorschlagen, jeden Abschnitt in einen anderen Zweig aufzuteilen und sich nur auf den Abschnitt zu konzentrieren, der dem Zweig entspricht, in dem Sie sich befinden. Legen Sie einen Zweig an, wenn Sie einen neuen Abschnitt erstellen, oder legen Sie Dummy-Abschnitte an, wenn Sie Ihre erste Übergabe machen (es ist Ihre Wahl). Widerstehen Sie dem Drang, einen anderen Abschnitt (z.B. 3) zu bearbeiten, wenn Sie sich nicht in dessen Zweig befinden. Wenn Sie etwas bearbeiten müssen, übertragen Sie diesen Abschnitt und checken dann den anderen aus, bevor Sie den Zweig wechseln. Ich finde das sehr hilfreich, weil so die Historie des Abschnitts in einem eigenen Zweig verbleibt und Sie außerdem auf einen Blick (im Baum) sehen können, wie alt ein Abschnitt ist. Vielleicht haben Sie in Abschnitt 3 Material hinzugefügt, das in Abschnitt 5 überarbeitet werden muss Natürlich wird man das mit großer Wahrscheinlichkeit bei einer sorgfältigen Lektüre feststellen, aber ich finde es hilfreich, das auf einen Blick zu sehen, damit ich einen Gang zurückschalten kann, wenn mir ein Abschnitt zu langweilig wird.

  Hier ist ein Beispiel für meine Verzweigungen und Zusammenführungen aus einer aktuellen Arbeit (ich verwende SourceTree unter OS X und Git von der Kommandozeile unter Linux). Sie werden wahrscheinlich feststellen, dass ich nicht der häufigste Committer der Welt bin und auch nicht ständig nützliche Kommentare hinterlasse, aber das ist kein Grund für Sie, diese guten Gewohnheiten nicht zu übernehmen. Die wichtigste Botschaft ist, dass das Arbeiten in Zweigen hilfreich ist. Meine Gedanken, Ideen und Entwicklungen verlaufen nicht linear, aber ich kann sie über Zweige verfolgen und sie zusammenführen, wenn ich zufrieden bin (ich hatte auch andere Zweige, die ins Leere führten und später gelöscht wurden). Ich kann Commits auch "taggen", wenn sie etwas bedeuten (z. B. erste Einreichungen bei Zeitschriften/überarbeitete Einreichungen/etc.). Hier habe ich sie als "Version 1" gekennzeichnet, was dem aktuellen Stand des Entwurfs entspricht. Der Baum repräsentiert die Arbeit von einer Woche.

  

• Eine weitere nützliche Maßnahme wäre es, Änderungen am gesamten Dokument vorzunehmen (z. B. die \alpha a \beta überall) verpflichtet sich von selbst. Auf diese Weise können Sie Änderungen rückgängig machen, ohne etwas anderes mit zurücknehmen zu müssen (es gibt Möglichkeiten, dies mit Git zu tun, aber hey, wenn Sie es vermeiden können, warum nicht?) Dasselbe gilt für Ergänzungen in der Präambel.

• Verwenden Sie ein entferntes Repo und pushen Sie Ihre Änderungen regelmäßig nach oben. Mit kostenlosen Dienstleistern wie GitHub und Bitbucket (beide ermöglichen es Ihnen, mit einem kostenlosen Konto private Repos zu erstellen), gibt es keinen Grund, diese nicht zu nutzen, wenn Sie mit Git/Mercurial arbeiten. Betrachten Sie es zumindest als sekundäres Backup (ich hoffe, Sie haben ein primäres!) für Ihre LaTeX-Dateien und einen Dienst, der es Ihnen ermöglicht, auf einem anderen Rechner mit der Bearbeitung fortzufahren, wo Sie aufgehört haben.

Answer 2

Auch ich habe einen ähnlichen Arbeitsablauf. Auch wenn immer nur an einem Zweig gearbeitet wird, finde ich es vorteilhaft, verschiedene Zweige für unterschiedliche Stadien der Arbeit zu haben. Stellen Sie sich zum Beispiel vor, Sie schicken einen guten Rohentwurf Ihrer Arbeit an Ihren Betreuer. Dann kommt Ihnen eine verrückte Idee! Sie wollen einige Kernkonzepte ändern, einige wichtige Abschnitte überarbeiten usw. usw. Also verzweigen Sie sich und beginnen zu arbeiten. Ihre Hauptverzweigung ist immer in einem "veröffentlichungsfähigen" Zustand (oder so nah dran, wie Sie in diesem Moment sind). Während Ihr anderer Zweig verrückt spielt und einige drastische Änderungen aufweist, ist der Master-Zweig immer releasefähig, wenn ein anderer Verlag Ihre Arbeit sehen will oder Sie als Student eine Konferenz einreichen (oder bereit, sie Ihrem Berater zu zeigen). Wenn Ihr Doktorvater den Entwurf morgens als erstes sehen will, können Sie zwar Ihre aktuellen Änderungen speichern, Tags verwenden oder das Protokoll durchsuchen, aber warum nicht getrennte Zweige behalten?!

Angenommen, Ihr Master-Zweig enthält den "veröffentlichungsfähigen" Zustand Ihrer Arbeit. Sie wollen sie nun bei mehreren begutachteten Zeitschriften einreichen, die jeweils unterschiedliche Formatierungsanforderungen für denselben Inhalt haben, und Sie erwarten, dass sie mit verschiedenen kleinen Kritikpunkten zurückkommen, wie Sie die Arbeit so bearbeiten können, dass sie für ihre Leser geeignet ist, usw. Sie könnten ganz einfach für jede Zeitschrift einen eigenen Zweig erstellen, die Änderungen für die jeweilige Zeitschrift vornehmen, die Arbeit einreichen und nach Erhalt der Rückmeldung die Änderungen in jedem einzelnen Zweig vornehmen.

Ich habe auch Dropbox und Git verwendet, um das System zu erstellen, das Sie oben beschrieben haben. Sie können ein Bare-Bones-Repository in Ihrem Dropbox-Ordner erstellen. Sie können dann Push/Pull von jedem Computer zu Ihrer Dropbox machen, um an allen Enden auf dem neuesten Stand zu bleiben. Dieses System funktioniert in der Regel nur, wenn die Anzahl der Mitarbeiter gering ist, da die Möglichkeit besteht, dass das Dropbox-Repository beschädigt wird, wenn mehrere Personen gleichzeitig an dem Projekt arbeiten wollen.

Sie könnten technisch gesehen auch nur EIN Repository im Dropbox-Ordner behalten und Ihre gesamte Arbeit von dort aus erledigen. Ich würde jedoch davon abraten, da einige Leute erwähnt haben, dass Dropbox Probleme mit der Synchronisierung von Dateien hat, die sich ständig ändern (gits-interne Dateien).

Answer 3

Ich habe versucht, dies als Bash-Funktion zu implementieren, ich habe es in mein ~/.bashrc um sie immer verfügbar zu machen.

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

Beachten Sie, dass diese Funktion latexdiff installiert werden (und im Pfad zu finden sein). Es ist auch wichtig, dass es findet pdflatex y okular .

Die erste ist mein Favorit Art und Weise, LaTeX zu verarbeiten, so dass Sie es in latex auch. Der zweite ist mein PDF-Reader, ich nehme an, Sie wollen ihn benutzen evince unter Gnome, oder eine andere Lösung.

Dies ist eine schnelle Version, die für ein einzelnes Dokument erstellt wurde, und zwar deshalb, weil Sie mit git viel Zeit und Mühe verlieren, wenn Sie ein LaTeX-Dokument mit mehreren Dateien verfolgen. Sie können diese Aufgabe auch git überlassen, aber wenn Sie wollen, können Sie auch weiterhin mit \include

Answer 4

Verwenden Sie dies für Versionsunterschied falls Sie mit Windows arbeiten, keine Installation, nur eine einfache bat Skript Es funktioniert perfekt auf Windows 10, miktex2.9:

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