quy trình làm việc git + LaTeX


270

Tôi đang viết một tài liệu rất dài bằng LaTeX. Tôi có máy tính làm việc và máy tính xách tay của tôi, và tôi làm việc trên cả hai. Tôi cần giữ tất cả các tệp được đồng bộ hóa giữa hai máy tính và cũng muốn giữ lịch sử sửa đổi. Tôi đã chọn git làm DVCS của mình và tôi đang lưu trữ kho lưu trữ của mình trên máy chủ của mình. Tôi cũng đang sử dụng Kile + Okular để chỉnh sửa. Kile không có plugin git tích hợp. Tôi cũng không hợp tác với bất cứ ai trong văn bản này. Tôi cũng đang suy nghĩ về việc đưa một kho lưu trữ riêng tư khác vào codaset, nếu máy chủ của tôi vì một số lý do không thể truy cập được.

Thực hành quy trình công việc được đề nghị trong trường hợp này là gì? Làm thế nào phân nhánh có thể được trang bị trong chương trình làm việc này? Có cách nào để so sánh hai phiên bản của cùng một tệp không? Còn việc sử dụng stash thì sao?

Câu trả lời:


390

Thay đổi quy trình làm việc LaTeX của bạn:

Bước đầu tiên trong việc quản lý hiệu quả quy trình làm việc Git + LaTeX là thực hiện một vài thay đổi đối với thói quen LaTeX của bạn.

  • Để bắt đầu, hãy viết mỗi câu trên một dòng riêng biệt . Git được ghi vào mã nguồn kiểm soát phiên bản, trong đó mỗi dòng là riêng biệt và có một mục đích cụ thể. Khi bạn viết tài liệu bằng LaTeX, bạn thường nghĩ về các đoạn văn và viết nó dưới dạng một tài liệu tự do. Tuy nhiên, trong git, các thay đổi thành một từ trong đoạn văn được ghi lại dưới dạng thay đổi toàn bộ đoạn.

    Một giải pháp là sử dụng git diff --color-words(xem câu trả lời của tôi cho một câu hỏi tương tự Làm thế nào để sử dụng Mercurial để kiểm soát phiên bản của tài liệu văn bản? Nơi tôi trình bày một ví dụ). Tuy nhiên, tôi phải nhấn mạnh rằng tách thành các dòng riêng biệt là một lựa chọn tốt hơn nhiều (tôi chỉ đề cập đến nó trong câu trả lời đó), vì tôi đã thấy nó dẫn đến xung đột hợp nhất rất nhỏ.

  • Nếu bạn cần xem mã diff, hãy sử dụng diff của Git. Để thấy sự khác biệt giữa hai lần xác nhận (phiên bản) tùy ý, bạn có thể làm như vậy với shas của mỗi lần xác nhận. Xem tài liệu để biết thêm chi tiết và cũng Hiển thị tệp nào đã thay đổi giữa hai lần sửa đổi .

    Mặt khác, nếu bạn cần xem độ lệch của đầu ra được định dạng của mình , hãy sử dụng latexdiffmột tiện ích tuyệt vời (được viết bằng perl) có hai tệp latex và tạo đầu ra khác biệt gọn gàng trong pdf như thế này ( nguồn hình ảnh ):

    Bạn có thể kết hợp gitlatexdiff(cộng latexpandnếu cần) trong một lệnh bằng cách sử dụng git-latexdiff (ví dụ: git latexdiff HEAD^để xem sự khác biệt giữa bàn làm việc của bạn và cam kết cuối cùng).

  • Nếu bạn đang viết một tài liệu dài bằng LaTeX, tôi khuyên bạn nên chia các chương khác nhau thành các tệp riêng của họ và gọi chúng trong tệp chính bằng \include{file}lệnh. Bằng cách này, bạn sẽ dễ dàng chỉnh sửa một phần được bản địa hóa trong tác phẩm của mình và cũng dễ kiểm soát phiên bản hơn, vì bạn biết những thay đổi đã được thực hiện cho mỗi chương, thay vì phải tìm ra từ nhật ký của một lớn tập tin.

Sử dụng Git hiệu quả:

  • Sử dụng cành cây! . Có lẽ không có lời khuyên nào tốt hơn tôi có thể đưa ra. Tôi thấy các chi nhánh rất hữu ích để theo dõi "các ý tưởng khác nhau" cho văn bản hoặc cho "các trạng thái khác nhau" của tác phẩm. Cácmaster chi nhánh nên cơ thể chính làm việc của bạn, trong hầu hết của nó hiện tại "đã sẵn sàng để xuất bản" tức là nhà nước, nếu tất cả các chi nhánh, nếu có một người là bạn sẵn sàng để đưa tên bạn trên đó, nó phải là chi nhánh tổng thể.

    Chi nhánh cũng cực kỳ hữu ích nếu bạn là một sinh viên tốt nghiệp. Vì bất kỳ học sinh tốt nghiệp nào cũng sẽ chứng thực, cố vấn chắc chắn sẽ có nhiều sửa chữa, hầu hết trong số đó bạn không đồng ý. Tuy nhiên, bạn có thể sẽ ít nhất thay đổi chúng trong thời điểm hiện tại, ngay cả khi chúng được hoàn nguyên sau khi thảo luận. Vì vậy, trong những trường hợp như vậy, bạn có thể tạo một nhánh mới advisorvà thay đổi theo ý thích của họ, đồng thời duy trì nhánh phát triển của riêng bạn. Sau đó, bạn có thể hợp nhất hai và anh đào chọn những gì bạn cần.

  • Tôi cũng sẽ đề nghị tách từng phần thành một nhánh khác nhau và chỉ tập trung vào phần tương ứng với nhánh mà bạn đang ở. Tạo ra một nhánh khi bạn tạo một phần mới hoặc các phần giả khi bạn thực hiện cam kết ban đầu (sự lựa chọn của bạn, thực sự). Chống lại sự thôi thúc chỉnh sửa một phần khác (giả sử, 3) khi bạn không ở trong chi nhánh của nó. Nếu bạn cần chỉnh sửa, hãy cam kết cái này và sau đó kiểm tra cái kia trước khi phân nhánh. Tôi thấy điều này rất hữu ích vì nó giữ lịch sử của phần trong nhánh riêng của nó và cũng cho bạn biết trong nháy mắt (từ cây) bao nhiêu phần tuổi. Có lẽ bạn đã thêm tài liệu vào phần 3 yêu cầu điều chỉnh đến phần 5 Tất nhiên, tất cả các khả năng này sẽ được quan sát trong khi đọc cẩn thận, nhưng tôi thấy thật hữu ích khi nhìn thấy điều này trong nháy mắt để tôi có thể thay đổi bánh răng nếu tôi'

    Đây là một ví dụ về các nhánh của tôi và hợp nhất từ ​​một bài báo gần đây (Tôi sử dụng SourceTree trên OS X và Git từ dòng lệnh trên Linux). Có lẽ bạn sẽ nhận thấy rằng tôi không phải là người thường xuyên đi lại trên thế giới và tôi cũng không để lại những bình luận hữu ích, nhưng đó không phải là lý do để bạn không tuân theo những thói quen tốt đó. Thông điệp takeaway chính là làm việc trong các chi nhánh là hữu ích. Suy nghĩ, ý tưởng và phát triển của tôi tiến hành phi tuyến tính, nhưng tôi có thể theo dõi chúng thông qua các chi nhánh và hợp nhất chúng khi tôi hài lòng (tôi cũng có các chi nhánh khác không dẫn đến nơi nào bị xóa sau này). Tôi cũng có thể "gắn thẻ" cam kết nếu chúng có ý nghĩa gì đó (ví dụ: lần gửi đầu tiên cho tạp chí / bài nộp được sửa đổi / v.v.). Ở đây, tôi đã gắn thẻ "phiên bản 1", đó là nơi dự thảo hiện tại. Cây đại diện cho một tuần '

  • Một điều hữu ích để làm sẽ được thực hiện thay đổi rộng tài liệu (ví dụ như thay đổi \alphađể \betaở khắp mọi nơi) cam kết trên của mình. Bằng cách đó, bạn có thể hoàn nguyên các thay đổi mà không phải quay lại một cái gì đó cùng với nó (có nhiều cách bạn có thể làm điều này bằng git, nhưng này, nếu bạn có thể tránh nó, thì tại sao không?). Cũng vậy với các bổ sung cho lời mở đầu.

  • Sử dụng repo từ xa và đẩy các thay đổi của bạn lên thượng nguồn thường xuyên. Với các nhà cung cấp dịch vụ miễn phí như GitHub và Bitbucket (cả hai đều cho phép bạn tạo repos riêng bằng tài khoản miễn phí), không có lý do gì để không sử dụng những thứ này nếu bạn đang làm việc với Git / Mercurial. Ít nhất, hãy coi nó như một bản sao lưu thứ cấp (tôi hy vọng bạn có một bản chính!) Cho các tệp LaTeX của bạn và một dịch vụ cho phép bạn tiếp tục chỉnh sửa từ nơi bạn để lại trên một máy khác.


6
@Diego: Ban đầu phải làm quen một chút, bởi vì tâm trí của bạn chỉ muốn đọc nó liên tục. Tuy nhiên, nó thực sự dễ dàng hơn bởi vì tôi (và hầu hết mọi người) nhìn vào đầu ra latex gọn gàng để xem các câu có ý nghĩa và bằng chứng đọc nó không. Sử dụng các ngắt này không ảnh hưởng đến đầu ra, và làm cho việc phân biệt dễ dàng hơn rất nhiều. Ngoài ra, bạn có thể liên kết đầu ra latex với tệp nguồn, vì vậy nếu bạn phát hiện ra lỗi hoặc lỗi chính tả, tất cả những gì bạn cần làm là nhấp vào nó và nó sẽ đưa bạn đến đúng điểm tương ứng trong nguồn.
abcd

1
Tôi sử dụng cách tiếp cận tương tự, nhưng làm thế nào để bạn xử lý các số liệu hoặc các tệp nhị phân khác, git có thể xử lý chúng hay không hoặc có cách tiếp cận nào khác cho các tệp nên được đưa vào repo mà không theo dõi phiên bản không?
liborw

6
Đây là những mẹo hữu ích, ngoại trừ một mẹo mà tôi không thấy sử dụng: một nhánh trên mỗi phần. Bạn có thể dễ dàng thấy các thay đổi trên cơ sở mỗi tệp, vậy tại sao lại tăng độ phức tạp của công việc bằng cách thêm một lớp tách biệt? git [log|show|add] some_file.textất cả công việc, không cần thêm chuyển đổi chi nhánh liên tục ở đây. Bạn vẫn có thể tự cam kết từng tệp nếu muốn.
rubenvb

1
@rubenvb Nếu bạn chia từng phần thành các tệp khác nhau, thì ừ. Tôi thường (và rất nhiều người trong giới học thuật) chỉ làm việc với một tệp tex duy nhất cho mỗi bài viết. Các tệp riêng lẻ có ý nghĩa đối với sách / luận văn, trong đó mỗi chương có một khối tài liệu đáng kể. Tất nhiên, đây chỉ là những gợi ý ... mỗi người nên chọn và từ chối các mẹo theo những gì phù hợp với quy trình làm việc của họ :)
abcd

2
@yoda ah tôi hiểu rồi. Vâng, sau đó có ý nghĩa. Tôi có xu hướng buộc nhiều tập tin tex trên các tạp chí dù sao ;-).
rubenvb

12

Tôi có một quy trình làm việc tương tự là tốt. Mặc dù một chi nhánh đang được làm việc tại một thời điểm, tôi thấy có lợi khi có các chi nhánh riêng biệt cho các trạng thái công việc khác nhau. Ví dụ, hãy tưởng tượng gửi một bản nháp thô của bài báo cho cố vấn của bạn. Sau đó, bạn có được một ý tưởng điên rồ! Bạn muốn bắt đầu thay đổi một số khái niệm cốt lõi, làm lại một số phần chính, v.v. Vì vậy, bạn rẽ nhánh và bắt đầu làm việc. Chi nhánh chính của bạn luôn ở trong trạng thái có thể tin cậy được của người Viking (hoặc gần như bạn đang ở trong thời điểm đó). Vì vậy, trong khi chi nhánh khác của bạn là điên rồ và có một số thay đổi mạnh mẽ, nếu nhà xuất bản khác muốn xem những gì bạn có hoặc bạn là sinh viên gửi đến một hội nghị, chi nhánh chính luôn sẵn sàng, sẵn sàng để đi (hoặc sẵn sàng để hiển thị cố vấn). Nếu cố vấn tiến sĩ của bạn muốn xem dự thảo điều đầu tiên vào buổi sáng,

Hãy nói rằng chi nhánh chính của bạn có trạng thái "đáng tin cậy" trong công việc của bạn. Bây giờ bạn muốn gửi nó cho một số tạp chí được đánh giá ngang hàng, mỗi tạp chí có các yêu cầu định dạng khác nhau cho cùng một nội dung và bạn đang mong đợi họ quay lại với một số lời chỉ trích nhỏ khác nhau về cách bạn có thể chỉnh sửa bài viết để phù hợp với độc giả của họ, v.v. Bạn có thể dễ dàng tạo một chi nhánh cho mỗi tạp chí, thực hiện các thay đổi cụ thể của tạp chí, gửi và khi bạn nhận được phản hồi thực hiện các thay đổi trên từng chi nhánh riêng biệt.

Tôi cũng đã sử dụng Dropbox và git để tạo hệ thống mà bạn mô tả ở trên. Bạn có thể tạo một kho lưu trữ xương trong thư mục dropbox của bạn. Sau đó, bạn có thể đẩy / kéo từ một trong hai máy tính vào hộp thả của mình để cập nhật tất cả các kết thúc. Hệ thống này thường chỉ hoạt động khi số lượng cộng tác viên ít vì có khả năng tham nhũng nếu mọi người cố gắng đẩy vào repo dropbox cùng một lúc.

Về mặt kỹ thuật bạn cũng có thể chỉ cần giữ MỘT kho lưu trữ bên trong thư mục dropbox và thực hiện tất cả công việc của bạn từ đó. Tuy nhiên, tôi sẽ không khuyến khích điều này, vì mọi người đã đề cập rằng dropbox có một số vấn đề khi đồng bộ hóa các tệp liên tục thay đổi (gits các tệp nội bộ).


3
Chỉ cần lưu ý rằng việc gửi một bài báo để đánh giá ngang hàng cho một số tạp chí / hội nghị cùng một lúc thường không được coi là đạo đức!
Siêu nhiên

7

Tôi đã cố gắng thực hiện điều này như là một hàm bash, tôi đã đưa nó vào trong ~/.bashrcđể làm cho nó luôn có sẵn.

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

Lưu ý rằng chức năng này cần latexdiffđược cài đặt (và được tìm thấy trên đường dẫn). Nó cũng quan trọng để nó tìm pdflatexokular.

Đầu tiên là cách ưa thích của tôi để xử lý LaTeX, vì vậy bạn cũng có thể sử dụng nó latex. Thứ hai là trình đọc PDF của tôi, tôi cho rằng bạn sẽ muốn sử dụng evincetheo gnome hoặc một số giải pháp khác.

Đây là một phiên bản nhanh, được tạo ra với một tài liệu duy nhất và đó là bởi vì với git, bạn sẽ mất rất nhiều thời gian và công sức để theo dõi một tài liệu LaTeX nhiều tệp. Bạn cũng có thể để git thực hiện nhiệm vụ này, nhưng nếu bạn muốn, bạn cũng có thể tiếp tục sử dụng\include


Hãy nhớ rằng các tham chiếu LaTeX sẽ không phù hợp với các hình ảnh được tạo. Và cũng là tập tin được tạo sẽ bị xóa ở cuối chức năng. Như tôi đã nói đó là một phiên bản nhanh.
Rafareino

1
Đề xuất sử dụng latexdiff được gọi là người trợ giúp gif hoàn chỉnh hơn trong câu trả lờilatexdiff
juandesant

Bạn có ý nghĩa gì bởi "người trợ giúp gif", @juandesant?
Rafareino

1
Xin lỗi, @Rafareino, ý tôi là "người trợ giúp git": người trợ giúp git là một công cụ có thể được git gọi cho một số thao tác. Trong trường hợp này, bạn có thể sử dụng latexdiffcông cụ dòng lệnh chỉ bằng cách sử dụng git diff, nếu bạn định cấu hình đúng.
juandesant

3

Một lựa chọn khác là sử dụng Authorea , một loại Github cho các bài báo khoa học. Mỗi bài viết trong Authorea là một repo Git. Và LaTeX bạn soạn thảo được kết xuất thành HTML5 (cũng như PDF, khi bạn biên dịch).


Đây là một chủ đề cũ, và ý tưởng là để lưu trữ mọi thứ trong khuôn viên. Authorea là mát mẻ, nhưng không phải những gì tôi đang tìm kiếm.
Ivan

5
Bạn nên làm rõ rằng bạn là người đồng sáng lập
Authorea

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.