Git + Latex workflow

Question

Git + Latex workflow

Piszę bardzo długi dokument w Latexie. Mam komputer służbowy i laptopa, i pracuję na nich obu. Muszę synchronizować wszystkie pliki między dwoma komputerami, a także chciałbym zachować historię wersji. Wybrałem git jako moje DVCS, i jestem hosting moje repozytorium na moim serwerze. Do edycji używam również Kile + Okular. Kile nie ma zintegrowanej wtyczki git. Nie współpracuję też z nikim przy tym tekście. Zastanawiam się też nad umieszczeniem inne prywatne repozytorium na codaset, jeśli mój serwer z jakiegoś powodu nie jest dostępny.

Jaka jest zalecana praktyka workflow w tym przypadku? Jak można zamontować rozgałęzienia w tym schemacie roboczym? Czy istnieje sposób na porównanie dwóch wersji tego samego pliku? A co z użyciem skrytki?

280

git latex git-workflow

Author: ebosi, 2011-05-31

Source

5 answers

Mam podobny obieg pracy. Mimo że jedna gałąź jest w trakcie pracy na raz, uważam, że korzystne jest posiadanie oddzielnych gałęzi dla różnych stanów pracy. Na przykład wyobraź sobie, że wysyłasz dobry wstępny projekt swojego artykułu do doradcy. Wtedy wpadniesz na szalony pomysł! Chcesz zacząć zmieniać niektóre podstawowe pojęcia, przerobić niektóre główne sekcje itp. itd. Więc rozgałęziasz się i zaczynasz pracować. Twoja gałąź master jest zawsze w stanie "uwolnienia" (lub tak blisko, jak jesteś w tym momencie). Więc podczas gdy twoja druga gałąź jest szalona i ma drastyczne zmiany, jeśli inny wydawca chce zobaczyć, co masz lub jesteś studentem zgłaszającym się na konferencję, gałąź master jest zawsze dostępna do wydania, gotowa do pracy (lub gotowa do pokazania doradcy). Jeśli twój Doradca Doktor chce zobaczyć projekt z samego rana, tak, możesz ukryć/etap / zatwierdzić bieżące zmiany, użyć tagów lub przeszukać dziennik, ale dlaczego nie zachować oddzielnych gałęzi?!

Powiedzmy, że Twoja gałąź master ma "releasable" stan twojej pracy. Teraz chcesz przesłać go do kilku recenzowanych czasopism, z których każdy ma inne wymagania formatowania dla tej samej treści i oczekujesz, że powrócą z kilkoma różnymi drobnymi krytykami na temat tego, jak możesz edytować artykuł, aby pasował do swoich czytelników itp. Możesz łatwo utworzyć gałąź dla każdego dziennika, wprowadzić zmiany dla każdego dziennika, przesłać, a po otrzymaniu opinii wprowadź zmiany w każdej oddzielnej gałęzi.

Ja również używałem Dropbox i git, aby stworzyć system, który opisałeś powyżej. Możesz utworzyć repozytorium bez kości w folderze dropbox. Możesz następnie przesuwać / ciągnąć z dowolnego komputera do dropbox, aby być na bieżąco ze wszystkimi końcami. Ten system działa zazwyczaj tylko wtedy, gdy liczba współpracowników jest niewielka, ponieważ istnieje możliwość uszkodzenia, jeśli ludzie próbują jednocześnie nacisnąć na zwrot z dropbox.

Technicznie możesz również po prostu zachować jedno repozytorium w folderze dropbox i wykonać całą swoją pracę stamtąd. Odradzałbym to jednak, ponieważ ludzie wspominali, że dropbox ma pewne problemy z synchronizacją plików, które stale się zmieniają (wewnętrzne pliki gits).

12

Author: Diego,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-05-31 14:28:20

Próbowałem zaimplementować to jako funkcję bash, umieściłem ją w moim ~/.bashrc, aby zawsze była dostępna.

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

Zauważ, że ta funkcja potrzebuje latexdiff do zainstalowania (i znalezienia na ścieżce). Ważne jest również, aby znaleźć pdflatex i okular.

Pierwszy to mój preferowany sposób przetwarzania lateksu, więc możesz go również przerobić na latex. Drugi to mój czytnik PDF, domyślam się, że będziesz chciał użyć {[6] } pod gnome, lub jakieś inne rozwiązanie.

To jest szybka wersja, wykonana z myślą o jednym dokumencie, a to dlatego, że z git, stracisz dużo czasu i wysiłku śledzenia wielu plików dokumentu LaTeX. Możesz pozwolić gitowi również wykonać to zadanie, ale jeśli chcesz, możesz również kontynuować używanie \include

8

Author: Rafareino,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-09-27 12:22:55

Inną opcją jest użycie Authorea, który jest rodzajem Githuba dla prac naukowych. Każdy artykuł w Authorea jest repo Git. A LaTeX, który tworzysz, jest renderowany do HTML5 (jak również PDF, podczas kompilacji).

3

Author: Alberto Pepe,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-04-26 14:23:46

Użyj tego dla version diff w przypadku, gdy jesteś na windows, bez raty, po prostu prosty skrypt bat Działa doskonale na windows10, miktex2. 9:

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

0

Author: redreamality,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-01-30 03:22:22

score 405 · Accepted Answer

Zmiany w przepływie pracy LaTeX-a:

Pierwszym krokiem w efektywnym zarządzaniu przepływem pracy Git+LaTeX jest wprowadzenie kilku zmian do nawyków Latexowych.

Na początek napisz każde zdanie w osobnej linijce . Git został napisany do kodu źródłowego kontroli wersji, gdzie każda linia jest odrębna i ma określony cel. Kiedy piszesz dokumenty w Latexie, często myślisz w kategoriach akapitów i piszesz je jako dokument o swobodnym przepływie. Jednak w git zmiany na pojedyncze słowo w akapicie jest rejestrowane jako zmiana całego akapitu.

Jednym z rozwiązań jest użycie git diff --color-words (zobacz moją odpowiedź na podobne pytanie Jak używać Mercurial do kontroli wersji dokumentów tekstowych? gdzie pokazuję przykład). Jednak muszę podkreślić, że podział na osobne linie jest znacznie lepszą opcją (wspomniałem o tym tylko przelotnie w tej odpowiedzi), ponieważ stwierdziłem, że powoduje to bardzo minimalne konflikty scalania.
Jeśli musisz spojrzeć na diff kodu, użyj natywnego diff Gita. Aby zobaczyć różnicę pomiędzy dwoma arbitralnymi zatwierdzeniami (wersjami), możesz to zrobić za pomocą shaS każdego z zatwierdzeń. Więcej informacji można znaleźć w dokumentacji , a także pokazującej, które Pliki uległy zmianie pomiędzy dwiema wersjami .

Z drugiej strony, jeśli chcesz spojrzeć na różnice z sformatowanego wyjścia, użyj latexdiff który jest doskonałym narzędziem (napisanym w Perlu), które pobiera dwa pliki latex i produkuje zgrabne diffed wyjście w pdf jak to ( źródło obrazu):

Możesz połączyć git i latexdiff (plus latexpand w razie potrzeby) w jednym poleceniu używając git-latexdiff (np. git latexdiff HEAD^ aby wyświetlić różnicę między Twoim drzewem roboczym a ostatnim commitem, ale jednym).
Jeśli piszesz długi dokument w Latexie, sugerowałbympodzielenie różnych rozdziałów na własne pliki i wywołanie ich w głównym pliku za pomocą polecenia \include{file}. W ten sposób łatwiej jest Ci edytować zlokalizowaną część pracy, a także łatwiej jest kontrolować wersję, ponieważ wiesz, jakie zmiany zostały wprowadzone do każdego rozdziału, zamiast musieć to rozgryźć na podstawie dzienników jednego dużego pliku.

Efektywne używanie Gita:

Użyj gałęzi!. Być może nie ma lepszej Rady, której mógłbym udzielić. Uważam, że gałęzie są bardzo pomocne w śledzeniu "różnych pomysłów" dla tekstu lub "różnych stanów" pracy. Na master branch powinien być twoim głównym dziełem, w jego najbardziej aktualnym stanie "gotowym do publikacji", tzn. jeśli ze wszystkich gałęzi, jeśli jest jedna, którą chcesz umieścić na niej swoje imię, powinna to być gałąź master.
Oddziały są również bardzo pomocne, jeśli jesteś studentem. Jak zaświadczy każdy absolwent, doradca musi mieć wiele poprawek, z których większość się nie zgadza. Jednak, można się spodziewać przynajmniej zmienić je na czas, nawet jeśli zostaną one przywrócone później po dyskusji. W takich przypadkach można więc utworzyć nową gałąź advisor i wprowadzić zmiany do ich upodobań, jednocześnie utrzymując własną gałąź deweloperską. Następnie można połączyć dwa i cherry wybrać to, czego potrzebujesz.
Sugerowałbym również podzielenie każdej sekcji na inną gałąź i skupienie się tylko na sekcji odpowiadającej gałęzi, na której się znajdujesz. Odradzanie gałęzi podczas tworzenia nowej sekcji lub sekcji atrapy kiedy dokonujesz początkowego commita (twój wybór, naprawdę). Oprzyj się pokusie edytowania innej sekcji (powiedzmy, 3), gdy nie jesteś na jej gałęzi. Jeśli chcesz edytować, Zatwierdź tę, a następnie sprawdź drugą przed rozgałęzieniem. Uważam to za bardzo pomocne, ponieważ przechowuje historię sekcji we własnej gałęzi, a także informuje na pierwszy rzut oka (z drzewa), jak stara jest jakaś sekcja. Być może dodałeś materiał do sekcji 3, który wymaga poprawienia do sekcji 5... oczywiście będą one, we wszystkich prawdopodobieństwo, być przestrzegane podczas uważnej lektury, ale uważam, że pomocne, aby zobaczyć to na pierwszy rzut oka, tak, że mogę zmienić bieg, jeśli jestem znudzony sekcji.

Oto przykład moich gałęzi i mergów z ostatniego artykułu (używam SourceTree na OS X i Git z wiersza poleceń na Linuksie). Prawdopodobnie zauważysz, że nie jestem najczęstszym committerem na świecie ani nie zostawiam przydatnych komentarzy cały czas, ale to nie powód, abyś nie podążał za tymi dobrymi nawykami. Główne dania na wynos wiadomość jest taka, że praca w gałęziach jest pomocna. Moje myśli, pomysły i rozwój postępują nieliniowo, ale mogę śledzić je za pomocą gałęzi i łączyć je, gdy jestem zadowolony (miałem również inne gałęzie, które doprowadziły donikąd, które zostały później usunięte). Mogę również" tagować " commity, jeśli coś znaczą (np. wstępne zgłoszenia do czasopism/poprawione zgłoszenia / itp.). Tutaj, otagowałem go "Wersja 1" , czyli tam, gdzie obecnie znajduje się szkic. Drzewo reprezentuje tydzień wartości praca.
Inną użyteczną rzeczą do zrobienia byłoby wprowadzenie zmian w całym dokumencie (np. zmiana \alpha na \beta wszędzie) commity same z siebie. W ten sposób, możesz cofnąć zmiany bez konieczności cofania czegoś innego wraz z nimi (są sposoby, aby to zrobić używając Gita, ale hej, jeśli możesz tego uniknąć, to dlaczego nie?). To samo dotyczy dodatków do preambuły.
Użyj zdalnego repo i regularnie wypychaj zmiany pod prąd. W przypadku darmowych dostawców usług, takich jak GitHub i Bitbucket (obaj pozwalają na tworzenie prywatnych transakcji z darmowym kontem), nie ma powodu, aby ich nie używać, jeśli pracujesz z Git/Mercurial. Przynajmniej potraktuj go jako zapasowy (mam nadzieję, że masz podstawowy!) dla plików LaTeX i usługi, która pozwala na kontynuowanie edycji z miejsca, w którym zostawiłeś na innym komputerze.