git + LaTeX iş akışı

LaTeX'te çok uzun bir belge yazıyorum. İş bilgisayarım ve dizüstü bilgisayarım var ve her ikisinde de çalışıyorum. Tüm dosyaları iki bilgisayar arasında senkronize tutmam gerekiyor ve ayrıca bir düzeltme geçmişi tutmak istiyorum. Git'i DVCS'im olarak seçtim ve depomu sunucumda barındırıyorum. Ayrıca düzenleme yapmak için Kile + Okular kullanıyorum. Kile'ın entegre bir git eklentisi yok. Ben de bu metinde kimseyle işbirliği yapmıyorum. Ayrıca sunucum bir nedenle erişilebilir değilse, codaset başka bir özel depo koymak düşünüyorum.

Bu durumda önerilen iş akışı uygulaması nedir? Dallanma bu çalışma şemasına nasıl yerleştirilebilir? Aynı dosyanın iki sürümünü karşılaştırmanın bir yolu var mı? Zulası kullanmaya ne dersiniz?

LaTeX iş akışınızdaki değişiklikler:

Git + LaTeX iş akışını verimli bir şekilde yönetmenin ilk adımı, LaTeX alışkanlıklarınızda birkaç değişiklik yapmaktır.

• Yeni başlayanlar için her cümleyi ayrı bir satıra yazın . Git, her satırın ayrı ve belirli bir amacı olan sürüm kontrolü kaynak koduna yazılmıştır. LaTeX'te belge yazarken, genellikle paragraflar açısından düşünür ve bunu serbestçe akan bir belge olarak yazarsınız. Ancak git'te, bir paragraftaki tek bir sözcükte yapılan değişiklikler, tüm paragrafta değişiklik olarak kaydedilir.

  Bir çözüm kullanmaktır git diff --color-words(benzer bir soruya verdiğim cevaba bakınız) Metin belgelerinin sürüm kontrolü için Mercurial nasıl kullanılır? Burada bir örnek göstereceğim). Bununla birlikte, ayrı satırlara bölmenin çok daha iyi bir seçenek olduğunu vurgulamalıyım (sadece bu cevabı geçerken bahsetmiştim), çünkü çok az birleşme çatışmasıyla sonuçlandığını buldum.

• Farklı kodlara bakmanız gerekiyorsa Git'in özgün farkını kullanın. İki keyfi işlem (sürüm) arasındaki farkı görmek için, bunu shaher işlemin s değeriyle yapabilirsiniz. Daha fazla ayrıntı ve ayrıca iki düzeltme arasında hangi dosyaların değiştiğini gösteren belgelere bakın .

  Öte yandan, size ait fark bakmak gerekirse biçimlendirilmiş çıktı , kullanım latexdiffiki lateks dosyalarını alır ve bu (gibi pdf düzgün diffed çıktı üretir (perl ile yazılmış) mükemmel bir yardımcı programdır resim kaynağı ):

  

  Git-latexdiff komutunu kullanarak tek bir komutta birleştirebilir gitve latexdiff(artı latexpandgerekirse) (örneğin , çalışma ağacınızla son-ama-one taahhüdü arasındaki farkı görüntülemek için).git latexdiff HEAD^

• LaTeX'te uzun bir belge yazıyorsanız, farklı bölümleri kendi dosyalarına bölmenizi ve \include{file}komutu kullanarak bunları ana dosyada çağırmanızı öneririm . Bu şekilde, çalışmanızın yerelleştirilmiş bir bölümünü düzenlemeniz daha kolay olur ve bir bölümün kayıtlarından anlamak yerine her bölümde hangi değişikliklerin yapıldığını bildiğiniz için sürüm kontrolü için de daha kolaydır. dosya.

Git'i verimli kullanmak:

• Dalları kullanın! . Belki verebileceğim daha iyi bir tavsiye yoktur. Metin veya işin "farklı durumları" için "farklı fikirleri" takip etmek için şubelerin çok yardımcı olduğunu gördüm. masterŞube, eğer bütün dalların, devlet ie "yayına hazır" bunu adınızı koymak için istekli olduklarını varsa, o ana dal olmalı en güncel içinde, işin ana gövdesi olmalıdır.

  Lisansüstü bir öğrenciyseniz şubeler de son derece faydalıdır. Herhangi bir mezun öğrencinin kanıtlayacağı gibi, danışmanın çoğu kabul etmediğiniz birçok düzeltmeye sahip olması gerekir. Yine de, tartışmalardan sonra daha sonra geri çevrilseler bile, bunları şimdilik en azından değiştirmeniz beklenebilir . Bu gibi durumlarda, yeni bir dal oluşturabilir advisorve aynı zamanda kendi geliştirme dalınızı koruyarak beğenilerinde değişiklikler yapabilirsiniz. Daha sonra iki ve kiraz seçimini birleştirebilirsiniz.

• Ayrıca her bölümü farklı bir şubeye bölmeyi ve yalnızca bulunduğunuz şubeye karşılık gelen bölümü odaklamayı öneririm. Yeni bir bölüm oluşturduğunuzda veya ilk taahhüdünüzü yaptığınızda (gerçekten seçiminiz) kukla bölümler oluşturduğunuzda dal oluşturun. Dalında değilken farklı bir bölümü (diyelim, 3) düzenleme isteğine karşı koy. Düzenlemeniz gerekiyorsa, bunu yapın ve dallanmadan önce diğerini kontrol edin. Bunu çok yararlı buluyorum çünkü bölümün tarihini kendi dalında tutuyor ve bir bakışta (ağaçtan) bazı bölümlerin kaç yaşında olduğunu anlatıyor. Belki de bölüm 3'e, bölüm 5'e ince ayar yapılmasını gerektiren materyaller eklediniz… Tabii ki, bunlar büyük olasılıkla dikkatli bir okuma sırasında gözlemlenecek, ancak vitesleri değiştirebilmem için bunu bir bakışta görmenin yararlı olduğunu düşünüyorum Eğer ben'

  İşte şubelerime ve yakın tarihli bir makaleden birleştirme (OS X'te SourceTree ve Linux'taki komut satırından Git kullanıyorum). Muhtemelen dünyanın en sık rastlanan komutanı olmadığımı veya her zaman yararlı yorumlar bırakmadığımı fark edeceksiniz, ancak bu iyi alışkanlıklara uymamanız için bir neden yok. Ana paket servisi olan restoran mesajı şubelerde çalışmanın yardımcı olmasıdır. Düşüncelerim, fikirlerim ve gelişimim doğrusal olmayan bir şekilde ilerliyor, ancak onları şubeler aracılığıyla takip edebilir ve memnun olduğumda birleştirebilirim (daha sonra silinen başka hiçbir yere götüren başka şubelerim de vardı). Ayrıca bir şey ifade ederse "etiket" yapabilirim (örn. Dergilere ilk gönderimler / gözden geçirilmiş gönderiler / vb.). Burada, taslak şu an olduğu yerde "sürüm 1" etiketledim. Ağaç bir haftayı temsil eder '

  

• Yapılması gereken bir başka yararlı şey de, belgede geniş değişikliklerin ( her yerde değişiklik \alphayapılması gibi \beta) kendi başına yapılmasıdır. Bu şekilde, başka bir şeyi geri almak zorunda kalmadan değişiklikleri geri alabilirsiniz (git'i kullanarak bunu yapmanın yolları vardır, ancak hey, eğer önleyebiliyorsanız, neden olmasın?). Aynı şey önsözde eklemeler için de geçerlidir.

• Uzak bir repo kullanın ve değişikliklerinizi düzenli olarak yukarı doğru itin. GitHub ve Bitbucket gibi ücretsiz hizmet sağlayıcılarla (her ikisi de ücretsiz bir hesapla özel depolar oluşturmanıza izin verir), Git / Mercurial ile çalışıyorsanız bunları kullanmamanız için bir neden yoktur. En azından, LaTeX dosyalarınız için ikincil bir yedekleme (umarım birincil bir tane var!) Ve farklı bir makinede bıraktığınız yerden düzenlemeye devam etmenizi sağlayan bir hizmet olarak düşünün.

Ben de benzer bir iş akışım var. Her seferinde bir şube üzerinde çalışılsa da, farklı çalışma durumları için ayrı şubelere sahip olmanın faydalı olduğunu düşünüyorum. Örneğin, makalenize iyi bir kaba taslak göndererek danışmanınıza düşünün. O zaman, çılgın bir fikir elde edersiniz! Bazı temel kavramları değiştirmeye başlamak, bazı önemli bölümleri yeniden çalışmak vb. İstersiniz. Böylece dallanır ve çalışmaya başlarsınız. Ana dalınız her zaman “serbest bırakılabilir” durumda (veya o anda olduğunuz kadar yakın). Diğer dalınız deliyse ve bazı ciddi değişiklikler olsa da, başka bir yayıncı sahip olduklarınızı görmek istiyorsa veya konferansa gönderilen bir öğrenciyseniz, ana dal her zaman serbest bırakılabilir, gitmeye hazırdır (veya danışman). Doktora danışmanınız taslağı sabah ilk iş olarak görmek istiyorsa,

Diyelim ki ana dalınız işinizin "serbest bırakılabilir" durumuna sahip. Şimdi, her biri aynı içerik için farklı biçimlendirme gereksinimlerine sahip olan birkaç hakemli dergiye göndermek istiyorsunuz ve makaleleri okuyucularına uyacak şekilde nasıl düzenleyebileceğiniz konusunda birkaç farklı eleştiriyle geri gelmelerini bekliyorsunuz. Her dergi için kolayca bir şube oluşturabilir, dergiye özel değişiklikler yapabilir, gönderebilir ve geri bildirim aldığınızda her bir ayrı dalda değişiklik yapabilirsiniz.

Yukarıda açıkladığınız sistemi oluşturmak için Dropbox ve git'i de kullandım. Dropbox klasörünüzde çıplak kemikli bir havuz oluşturabilirsiniz. Daha sonra, tüm uçlardan haberdar olmak için her iki bilgisayardan dropbox'ınıza itebilir / çekebilirsiniz. Bu sistem genellikle yalnızca ortak çalışan sayısı az olduğunda çalışır, çünkü insanlar aynı anda dropbox repo'sine zorlamaya çalışırlarsa yolsuzluk olasılığı vardır.

Teknik olarak ayrıca ONE havuzunu dropbox klasörü içinde tutabilir ve tüm işinizi oradan yapabilirsiniz. Ancak, insanların dropbox'ın sürekli değişen dosyaları senkronize etme konusunda sorun yaşadıklarından bahsettiği gibi, bu cesaret kırıcı olur (dahili dosyalara uyuyor).

Bunu bir bash işlevi olarak uygulamaya çalıştım, ~/.bashrcher zaman kullanılabilir hale getirmek için buna dahil ettim .

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

Bu işlevin latexdiffyüklenmesi (ve yolda bulunması) gerektiğini unutmayın. Bulması pdflatexve bulması da önemlidir okular.

Birincisi, LaTeX'i işlemek için tercih ettiğim yol, böylece onu da değiştirebilirsiniz latex. İkincisi PDF okuyucum, sanırım evincegnome altında kullanmak isteyeceksiniz ya da başka bir çözüm.

Bu, tek bir belge göz önünde bulundurularak yapılan hızlı bir sürümdür, çünkü git ile çok dosyalı bir LaTeX belgesini izlemek için çok fazla zaman ve çaba kaybedersiniz. Git'in bu görevi de yapmasına izin verebilirsiniz, ancak isterseniz kullanmaya devam edebilirsiniz\include

Başka bir seçenek de bilimsel makaleler için bir çeşit Github olan Authorea kullanmaktır . Authorea'daki her makale bir Git deposudur. Ve oluşturduğunuz LaTeX, HTML5'e (ayrıca derlediğinizde PDF'ye) dönüştürülür.

Eğer windows, taksit, sadece basit bir komut dosyası olması durumunda sürüm diff için bunu kullanın batWindows10, miktex2.9 mükemmel çalışır:

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