web-dev-qa-db-ja.com

git + LaTeXワークフロー

LaTeXで非常に長いドキュメントを書いています。仕事用のコンピューターとラップトップがあり、両方で仕事をしています。 2台のコンピューター間ですべてのファイルの同期を維持する必要があります。また、改訂履歴も保持したいと思います。 DVCSとしてgitを選択し、サーバーでリポジトリをホストしています。また、Kile + Okularを使用して編集を行っています。 Kileにはgitプラグインが統合されていません。また、このテキストについては誰とも協力していません。何らかの理由でサーバーにアクセスできない場合は、codasetに別のプライベートリポジトリを配置することも考えています。

この場合の推奨されるワークフローのプラクティスは何ですか?この作業スキームにどのように分岐を適合させることができますか?同じファイルの2つのバージョンを比較する方法はありますか?スタッシュの使用はどうですか?

257
Ivan

LaTeXワークフローの変更:

Git + latexワークフローを効率的に管理するための最初のステップは、LaTeXの習慣にいくつかの変更を加えることです。

  • まず、各文を別々の行に書きます。 Gitはバージョン管理のソースコードに記述されており、各行は明確で特定の目的があります。 LaTeXでドキュメントを作成するとき、多くの場合、段落の観点から考えて、自由に流れるドキュメントとして作成します。ただし、gitでは、段落内の単一のWordへの変更は、段落全体への変更として記録されます。

    解決策の1つは、git diff --color-wordsを使用することです( 私の答えを参照 例を示している同様の質問に)ただし、マージの競合が非常に少ないことがわかったため、別々の行に分割する方がはるかに優れたオプションであることを強調する必要があります(その答えを渡すことで言及しました)。

  • コードの差分を確認する必要がある場合は、gitのネイティブ差分を使用します。 2つの任意のコミット(バージョン)の違いを確認するには、各コミットのshasを使用して確認できます。詳細については ドキュメント を、また この質問 をご覧ください

    一方、formatted outputの差分を見る必要がある場合は、 latexdiff を使用します。これは、2つのラテックスファイルと次のようなPDFで適切な差分出力を生成します( image source ):

    git-latexdiff を使用して、1つのコマンドでgitlatexdiff(および必要に応じてlatexpand)を組み合わせることができます(例:git latexdiff HEAD^を使用して、ワークツリーと最後の1つのコミット間の差分を表示します)。

  • LaTeXで長いドキュメントを書いている場合は、 異なる章を独自のファイルに分割する を提案し、\include{file}コマンドを使用してメインファイルで呼び出します。これにより、作業のローカライズされた部分を編集するのが簡単になります。また、1つの大きなログからそれを把握する必要がなく、各章に加えられた変更を知っているため、バージョン管理も簡単になりますファイル。

Gitを効率的に使用する:

  • ブランチを使用してください!おそらく、これ以上のアドバイスはありません。テキストまたは作品の「異なる状態」の「異なるアイデア」を追跡するために、ブランチが非常に役立つことがわかりました。 masterブランチは、作業のメインボディである必要があります。最新の「公開準備完了」状態、つまり、すべてのブランチの場合、名前を付けたいものがある場合は、マスターブランチになります。 。

    ブランチもextremelyあなたが大学院生の場合に役立ちます。大学院生なら誰でも証言するように、アドバイザーは多くの修正を行う必要がありますが、そのほとんどはあなたが同意しません。しかし、議論の後で後で元に戻されたとしても、atleastしばらくの間それらを変更することが期待されるかもしれません。そのため、このような場合、新しいブランチadvisorを作成し、好みに変更を加えると同時に、独自の開発ブランチを維持できます。次に、2つをマージして、必要なものを選択します。

  • また、各セクションを別のブランチに分割し、現在のブランチに対応するセクションのみにフォーカスすることをお勧めします。新しいセクションを作成するときにブランチを作成するか、最初のコミットを作成するときにダミーセクションを作成します(実際に選択します)。ブランチ上にないときに別のセクション(3など)を編集する衝動に抵抗します。編集する必要がある場合は、これをコミットしてから、分岐する前にもう一方をチェックアウトします。これは、セクションの履歴を独自のブランチに保持し、一部のセクションが(ツリーから)一目でわかるため、非常に役立ちます。おそらく、セクション5の調整が必要な資料をセクション3に追加したのでしょう...もちろん、これらは、おそらくすべての注意深い読書の間に観察されますが、私ができるようにこれを一目で確認することは役立つと思いますセクションに飽きたらギアをシフトします。

    これが最近の論文のブランチとマージの例です(OS XではSourceTreeを使用し、Linuxではコマンドラインからgitを使用しています)。あなたはおそらく私が世界で最も頻繁なコミッターではないことに気付くでしょうし、いつも有益なコメントを残していませんが、それはあなたがそれらの良い習慣に従わない理由ではありません。主なメッセージは、ブランチでの作業が役立つことです。私の考え、アイデア、開発は非線形に進行しますが、ブランチを介してそれらを追跡し、満足したらマージすることができます(後でどこにも削除されなかった他のブランチもありました)。また、何か意味がある場合にコミットに「タグ付け」することもできます(例:ジャーナルへの最初の提出/改訂された提出など)。ここでは、「バージョン1」というタグを付けました。これは、現在のドラフトの場所です。ツリーは、1週間分の作業を表します。

    enter image description here

  • 別の便利なことは、ドキュメント全体の変更(\alphaをどこでも\betaに変更するなど)を自分でコミットすることです。そうすれば、他の何かをロールバックすることなく変更を元に戻すことができます(gitを使用してこれを行う方法はありますが、それを避けることができれば、なぜですか?)前文への追加についても同じことが言えます。

  • リモートリポジトリを使用して、変更を定期的にアップストリームにプッシュします。 githubやbitbucket(後者では無料のアカウントでプライベートリポジトリを作成することもできます)などの無料サービスプロバイダーでは、git/Mercurialを使用している場合にこれらを使用しない理由はありません。少なくとも、ラテックスファイルと、別のマシンでの作業を続けられるようにするサービスのセカンダリバックアップ(プライマリバックアップが必要です!)として検討してください。

371
abcd

同様のワークフローもあります。一度に1つのブランチが作業されていますが、作業の状態ごとに別々のブランチを持つことは有益であると思います。たとえば、アドバイザに論文の大まかな下書きを送ることを想像してください。その後、あなたはクレイジーなアイデアを得る!いくつかのコアコンセプトの変更を開始したり、いくつかの主要なセクションを作り直したりするなど。マスターブランチは常に「解放可能」な状態(またはその瞬間に近い状態)にあります。したがって、他のブランチが狂って大幅な変更を加えている間、別の出版社があなたが持っているものを見たい場合、またはあなたが会議に提出している学生である場合、マスターブランチは常に解放可能で、すぐに行くことができますアドバイザー)。午前中に博士号アドバイザーがドラフトを最初に見たい場合は、はい、現在の変更を隠し/ステージ/コミットし、タグを使用するか、ログを検索できますが、別のブランチを保持しないのはなぜですか?

あなたのマスターブランチがあなたの仕事の「解放可能な」状態にあるとしましょう。それぞれが同じコンテンツに対して異なる書式設定要件を持つ複数の査読付きジャーナルに提出したいと考えています。読者に合わせて論文を編集する方法などについて、いくつかの小さな批判が戻ってくることを期待しています。ジャーナルごとにブランチを簡単に作成し、ジャーナル固有の変更を行い、送信し、フィードバックを受け取ったら、各ブランチで変更を加えることができます。

また、Dropboxとgitを使用して、上記のシステムを作成しました。 Dropboxフォルダーに必要最低限​​のリポジトリを作成できます。その後、いずれかのコンピューターからDropboxにプッシュ/プルして、すべての端末を最新の状態に保つことができます。このシステムは通常、共同作業者の数が少ない場合にのみ機能します。これは、人々が同時にDropboxリポジトリにプッシュしようとすると破損する可能性があるためです。

技術的には、1つのリポジトリをdropboxフォルダー内に保持し、そこからすべての作業を行うこともできます。しかし、私はこれを落胆させるでしょう。人々がdropboxには絶えず変化しているファイル(git内部ファイル)の同期に問題があると言っているからです。

11
Diego

これをbash関数として実装しようとしました。それを~/.bashrcに含めて、常に利用できるようにしました。

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

この関数には、latexdiffをインストールする必要があります(パス上にあることに注意してください)。 pdflatexおよびokularを見つけることも重要です。

最初はmy prefered LaTeXを処理する方法なので、latexに変更することもできます。 2番目は私のPDFリーダーです。gnomeまたは他のソリューションでevinceを使用したいと思うでしょう。

これは、単一のドキュメントを念頭に置いて作成されたクイックバージョンです。これは、gitを使用すると、マルチファイルLaTeXドキュメントの追跡に多くの時間と労力が費やされるためです。 gitにこのタスクを実行させることもできますが、必要に応じて、\includeの使用を継続することもできます

7
Rafareino

別のオプションは Authorea を使用することです。これは科学論文用のGithubの一種です。 Authoreaのすべての記事はGitリポジトリです。そして、作成するLaTeXはHTML5にレンダリングされます(コンパイル時にPDFもレンダリングされます)。

3
Alberto Pepe

これをversion diffに使用します。Windowsを使用している場合、分割払いではなく、単純なbatスクリプトのみです。windows10、miktex2.9で完全に動作します。

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

0
redreamality