git + LaTeX workflow


270

Saya sedang menulis dokumen yang sangat panjang di LaTeX. Saya memiliki komputer kerja dan laptop saya, dan saya mengerjakan keduanya. Saya perlu menjaga semua file disinkronkan antara dua komputer, dan juga ingin menyimpan riwayat revisi. Saya memilih git sebagai DVCS saya, dan saya hosting repositori saya di server saya. Saya juga menggunakan Kile + Okular untuk melakukan pengeditan. Kile tidak memiliki plugin git terintegrasi. Saya juga tidak berkolaborasi dengan siapa pun dalam teks ini. Saya juga berpikir tentang meletakkan repositori pribadi lain di codaset, jika server saya karena beberapa alasan tidak dapat diakses.

Apa praktik alur kerja yang disarankan dalam kasus ini? Bagaimana percabangan bisa dipasang dalam skema kerja ini? Apakah ada cara untuk membandingkan dua versi dari file yang sama? Bagaimana dengan menggunakan simpanan?

Jawaban:


390

Perubahan pada alur kerja LaTeX Anda:

Langkah pertama dalam mengelola alur kerja Git + LaTeX secara efisien adalah membuat beberapa perubahan pada kebiasaan LaTeX Anda.

  • Sebagai permulaan, tulis setiap kalimat pada baris yang berbeda . Git ditulis ke kode sumber kontrol versi, di mana setiap baris berbeda dan memiliki tujuan tertentu. Ketika Anda menulis dokumen di LaTeX, Anda sering berpikir dalam bentuk paragraf dan menulisnya sebagai dokumen yang mengalir bebas. Namun, dalam git, perubahan pada satu kata dalam satu paragraf dicatat sebagai perubahan pada seluruh paragraf.

    Salah satu solusinya adalah menggunakan git diff --color-words(lihat jawaban saya untuk pertanyaan serupa. Bagaimana cara menggunakan Mercurial untuk kontrol versi dokumen teks? Di mana saya menunjukkan contoh). Namun, saya harus menekankan bahwa memisahkan ke dalam baris yang terpisah adalah pilihan yang jauh lebih baik (saya hanya menyebutkannya dalam menyampaikan jawaban itu), karena saya telah menemukan itu menghasilkan konflik penggabungan yang sangat minim.

  • Jika Anda perlu melihat kode diff, gunakan diff asli Git. Untuk melihat perbedaan antara dua komit (versi) sewenang-wenang, Anda dapat melakukannya dengan shas dari masing-masing komit. Lihat dokumentasi untuk detail lebih lanjut dan juga Menampilkan file mana yang telah berubah di antara dua revisi .

    Di sisi lain, jika Anda perlu melihat perbedaan output terformat Anda , gunakan latexdiffutilitas yang sangat baik (ditulis dalam perl) yang mengambil dua file lateks dan menghasilkan output diffed rapi dalam pdf seperti ini ( sumber gambar ):

    Anda dapat menggabungkan gitdan latexdiff(ditambah latexpandjika diperlukan) dalam satu perintah menggunakan git-latexdiff (mis. git latexdiff HEAD^Untuk melihat perbedaan antara worktree Anda dan commit last-but-one).

  • Jika Anda menulis dokumen panjang di LaTeX, saya sarankan memisahkan bab yang berbeda ke dalam file mereka sendiri dan memanggil mereka di file utama menggunakan \include{file}perintah. Dengan cara ini lebih mudah bagi Anda untuk mengedit bagian terlokalisasi dari pekerjaan Anda, dan juga lebih mudah untuk kontrol versi, karena Anda tahu perubahan apa yang telah dibuat untuk setiap bab, daripada harus mencari tahu dari log dari satu besar mengajukan.

Menggunakan Git secara efisien:

  • Gunakan cabang! . Mungkin tidak ada saran yang lebih baik yang bisa saya berikan. Saya menemukan cabang sangat membantu untuk melacak "berbagai ide" untuk teks atau "kondisi berbeda" dari karya tersebut. The mastercabang harus tubuh utama Anda bekerja, di yang paling saat ini "siap untuk menerbitkan" yaitu negara, jika semua cabang, jika ada satu bahwa Anda bersedia untuk menempatkan nama Anda di atasnya, itu harus cabang master.

    Cabang juga sangat membantu jika Anda seorang mahasiswa pascasarjana. Seperti yang akan dibuktikan oleh setiap mahasiswa pascasarjana, penasihat tersebut pasti memiliki banyak koreksi, yang sebagian besar tidak Anda setujui. Namun, Anda mungkin diharapkan setidaknya mengubahnya untuk saat ini, bahkan jika mereka dikembalikan kemudian setelah diskusi. Jadi dalam kasus seperti itu, Anda bisa membuat cabang baru advisordan membuat perubahan sesuai keinginan mereka, sekaligus mempertahankan cabang pengembangan Anda sendiri. Anda kemudian dapat menggabungkan keduanya dan memilih apa yang Anda butuhkan.

  • Saya juga menyarankan pemisahan setiap bagian menjadi cabang yang berbeda dan fokus hanya bagian yang sesuai dengan cabang tempat Anda berada. Tumbuhkan cabang ketika Anda membuat bagian baru atau bagian dummy ketika Anda membuat komit awal Anda (pilihan Anda, benar-benar). Tahan keinginan untuk mengedit bagian yang berbeda (misalnya, 3) ketika Anda tidak berada di cabangnya. Jika Anda perlu mengedit, komit yang ini dan kemudian checkout yang lain sebelum bercabang. Saya menemukan ini sangat membantu karena menyimpan sejarah bagian di cabang sendiri dan juga memberitahu Anda sekilas (dari pohon) berapa umur beberapa bagian. Mungkin Anda telah menambahkan materi ke bagian 3 yang memerlukan penyesuaian pada bagian 5 ... Tentu saja, ini akan, dalam semua kemungkinan, diamati selama pembacaan yang cermat, tetapi saya merasa sangat membantu untuk melihat ini secara sekilas sehingga saya dapat menggeser persneling jika saya'

    Berikut adalah contoh dari cabang dan penggabungan dari makalah baru-baru ini (saya menggunakan SourceTree pada OS X dan Git dari baris perintah di Linux). Anda mungkin akan memperhatikan bahwa saya bukan pengendara yang paling sering di dunia dan saya juga tidak meninggalkan komentar yang bermanfaat sepanjang waktu, tetapi itu bukan alasan bagi Anda untuk tidak mengikuti kebiasaan baik itu. Pesan takeaway utama adalah bahwa bekerja di cabang sangat membantu. Pikiran, ide, dan pengembangan saya berkembang secara non-linear, tetapi saya bisa melacaknya melalui cabang dan menggabungkannya ketika saya puas (saya juga punya cabang lain yang tidak mengarah ke mana pun yang kemudian dihapus). Saya juga dapat "menandai" komitmen jika itu berarti sesuatu (misalnya, pengiriman awal ke jurnal / pengiriman yang direvisi / dll.). Di sini, saya telah menandai itu "versi 1", yang merupakan konsep sampai sekarang. Pohon itu mewakili satu minggu '

  • Hal lain yang bermanfaat untuk dilakukan adalah membuat perubahan besar pada dokumen (seperti mengubah \alphake \betamana - mana) dilakukan sendiri. Dengan begitu, Anda dapat mengembalikan perubahan tanpa harus mengembalikan sesuatu yang lain dengannya (ada cara Anda bisa melakukan ini menggunakan git, tapi hei, jika Anda bisa menghindarinya, lalu mengapa tidak?). Hal yang sama berlaku untuk penambahan pada pembukaan.

  • Gunakan repo jarak jauh dan dorong perubahan Anda ke atas secara teratur. Dengan penyedia layanan gratis seperti GitHub dan Bitbucket (keduanya memungkinkan Anda membuat repo pribadi dengan akun gratis), tidak ada alasan untuk tidak menggunakan ini jika Anda bekerja dengan Git / Mercurial. Paling tidak, anggap itu sebagai cadangan sekunder (saya harap Anda memiliki yang utama!) Untuk file LaTeX Anda dan layanan yang memungkinkan Anda untuk terus mengedit dari tempat Anda meninggalkan di mesin yang berbeda.


6
@Diego: Memang butuh sedikit membiasakan pada awalnya, karena pikiran Anda hanya ingin membacanya terus menerus. Namun, sebenarnya lebih mudah karena saya (dan kebanyakan orang) melihat keluaran lateks yang rapi untuk melihat apakah kalimat itu masuk akal dan untuk membacanya. Menggunakan jeda ini tidak berpengaruh pada output, dan membuat perbedaan jauh lebih mudah. Juga, Anda dapat menautkan output lateks ke file sumber, jadi jika Anda menemukan kesalahan atau kesalahan ketik, yang perlu Anda lakukan adalah mengkliknya dan itu akan membawa Anda langsung ke titik yang sesuai di sumber.
abcd

1
Saya menggunakan pendekatan yang sama, tetapi bagaimana Anda menangani angka atau file biner lainnya, dapat git menanganinya juga atau apakah ada pendekatan lain untuk file yang harus dimasukkan dalam repo tanpa pelacakan versi?
liborw

6
Ini adalah tips praktis, kecuali yang tidak saya lihat penggunaannya: cabang per bagian. Anda dapat dengan mudah melihat perubahan pada basis per file, jadi mengapa menambah kompleksitas alur kerja dengan menambahkan lapisan pemisahan tambahan? git [log|show|add] some_file.texsemua pekerjaan, tidak perlu menambahkan cabang konstan yang berpindah di sini. Anda masih dapat melakukan setiap file sendiri jika Anda mau.
rubenvb

1
@rubenvb Jika Anda membagi setiap bagian menjadi file yang berbeda, maka ya. Saya biasanya (dan banyak orang di kalangan akademis) bekerja dengan hanya satu file tex per artikel. File individual masuk akal untuk buku / tesis, di mana setiap bab memiliki sejumlah besar bahan. Tentu saja, ini hanya saran ... masing-masing harus memilih dan menolak tip sesuai dengan alur kerja mereka :)
abcd

2
@yoda ah saya mengerti. Ya, itu masuk akal. Saya cenderung memaksa banyak file tex pada jurnal ;-).
rubenvb

12

Saya memiliki alur kerja yang serupa juga. Meskipun satu cabang sedang dikerjakan pada satu waktu, saya merasa bermanfaat untuk memiliki cabang yang terpisah untuk kondisi kerja yang berbeda. Misalnya, bayangkan mengirimkan draf kasar dari makalah Anda kepada penasihat Anda. Lalu, Anda mendapat ide gila! Anda ingin mulai mengubah beberapa konsep inti, mengerjakan kembali beberapa bagian utama, dll. Jadi, Anda bercabang dan mulai bekerja. Cabang utama Anda selalu dalam kondisi "dapat dirilis" (atau sedekat Anda pada saat itu). Jadi, sementara cabang Anda yang lain gila dan memiliki beberapa perubahan drastis, jika penerbit lain ingin melihat apa yang Anda miliki, atau Anda seorang siswa yang mengirimkan ke konferensi, cabang utama selalu dapat dirilis, siap untuk pergi (atau siap untuk menunjukkan kepada Anda penasihat). Jika penasihat PhD Anda ingin melihat konsep hal pertama di pagi hari,

Katakanlah cabang master Anda memiliki status "dapat dirilis" dari pekerjaan Anda. Anda sekarang ingin mengirimkannya ke beberapa jurnal peer-review, masing-masing memiliki persyaratan format yang berbeda untuk konten yang sama dan Anda mengharapkan mereka untuk kembali dengan beberapa kritik kecil yang berbeda tentang bagaimana Anda dapat mengedit kertas agar sesuai dengan pembaca mereka, dll. Anda dapat dengan mudah membuat cabang untuk setiap jurnal, membuat perubahan khusus jurnal, mengirim, dan ketika Anda menerima umpan balik, buat perubahan pada setiap cabang yang terpisah.

Saya juga menggunakan Dropbox dan git untuk membuat sistem yang Anda jelaskan di atas. Anda dapat membuat repositori kosong di folder dropbox Anda. Anda kemudian dapat mendorong / menarik dari salah satu komputer ke dropbox Anda untuk tetap up to date di semua ujungnya. Sistem ini biasanya hanya berfungsi ketika jumlah kolaborator kecil karena ada kemungkinan korupsi jika orang mencoba mendorong repo dropbox pada saat yang sama.

Secara teknis Anda juga bisa menyimpan SATU repositori di dalam folder dropbox dan melakukan semua pekerjaan Anda dari sana. Saya akan mencegah ini, karena orang-orang telah menyebutkan bahwa dropbox memiliki beberapa masalah sinkronisasi file yang terus berubah (gits file internal).


3
Catat saja bahwa mengirimkan makalah untuk peer review ke beberapa jurnal / konferensi pada saat yang sama biasanya tidak dianggap etis!
Supernormal

7

Saya mencoba menerapkan ini sebagai fungsi bash, saya sudah memasukkannya ~/.bashrcke dalam agar selalu tersedia.

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

Perhatikan bahwa fungsi ini perlu latexdiffdiinstal (dan ditemukan di jalan). Penting juga untuk menemukan pdflatexdan okular.

Yang pertama adalah cara yang saya sukai untuk memproses LaTeX, jadi Anda juga bisa menggunakannya latex. Yang kedua adalah pembaca PDF saya, saya kira Anda ingin menggunakan di evincebawah gnome, atau solusi lain.

Ini adalah versi cepat, dibuat dengan satu dokumen dalam pikiran, dan itu karena dengan git, Anda akan kehilangan banyak waktu dan upaya melacak dokumen multi-file LaTeX. Anda dapat membiarkan git melakukan tugas ini juga, tetapi jika mau, Anda juga dapat terus menggunakan\include


Perlu diingat bahwa referensi LaTeX tidak akan cocok dengan visualisasi yang dihasilkan. Dan juga file yang dihasilkan dihapus di akhir fungsi. Seperti yang saya katakan itu adalah versi cepat.
Rafareino

1
Proposal untuk menggunakan latexdiff disebut sebagai pembantu gif lebih lengkap dalam jawaban untuk Menggunakan latexdiffdengan git
juandesant

Apa yang Anda maksud dengan "pembantu pembantu", @juandesant?
Rafareino

1
Maaf, @Rafareino, maksud saya "git helper": a git helper adalah alat yang dapat dipanggil oleh git untuk beberapa operasi. Dalam hal ini, Anda dapat menggunakan latexdiffalat baris perintah hanya dengan menggunakan git diff, jika Anda mengonfigurasinya dengan benar.
juandesant

3

Pilihan lain adalah menggunakan Authorea yang merupakan semacam Github untuk karya ilmiah. Setiap artikel di Authorea adalah repo Git. Dan LaTeX yang Anda buat akan dirender ke HTML5 (dan juga PDF, saat Anda kompilasi).


Ini adalah utas yang agak kuno, dan idenya adalah untuk meng-host segala sesuatu di tempat. Authorea itu keren, tapi bukan yang saya cari.
Ivan

5
Anda harus menjelaskan bahwa Anda adalah salah satu pendiri
Authorea

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.