私は LaTeX で非常に長い文書を書いています。仕事用のコンピューターとラップトップがあり、両方で作業しています。2 台のコンピューター間ですべてのファイルを同期しておく必要があり、また、リビジョン履歴も保存したいと考えています。DVCS として git を選択し、リポジトリをサーバー上にホストしています。編集には Kile + Okular も使用しています。Kile には統合された git プラグインがありません。また、このテキストでは誰とも共同作業していません。また、何らかの理由でサーバーにアクセスできない場合に備えて、codaset に別のプライベート リポジトリを置くことも考えています。
この場合、推奨されるワークフロー方法は何ですか? この作業スキームにブランチを適合させるにはどうすればよいですか? 同じファイルの 2 つのバージョンを比較する方法はありますか? スタッシュを使用するとどうなりますか?
ベストアンサー1
LaTeX ワークフローの変更:
Git + LaTeX ワークフローを効率的に管理するための最初のステップは、LaTeX の習慣にいくつかの変更を加えることです。
まず、各文を別々の行に書きます。Git はソース コードのバージョン管理用に作成されており、各行は独立しており、特定の目的があります。LaTeX で文書を書くときは、段落を基準に考え、自由に記述できる文書として書くことがよくあります。ただし、Git では、段落内の 1 つの単語の変更は、段落全体の変更として記録されます。
git diff --color-words解決策の1つは、（同様の質問に対する私の回答を参照）を使用することです。テキストドキュメントのバージョン管理に Mercurial を使用するにはどうすればよいでしょうか?ここで例を示します。ただし、別々の行に分割する方がはるかに優れたオプションであることを強調する必要があります (その回答では、これについて簡単に触れただけです)。これにより、マージの競合が最小限に抑えられることがわかったためです。shaコードの差分を見る必要がある場合は、Gitのネイティブな差分を使用してください。任意の2つのコミット（バージョン）の違いを見るには、各コミットの を使用します。ドキュメンテーション詳細については2つのリビジョン間で変更されたファイルを表示する。一方、フォーマットされた出力の差分を確認する必要がある場合は、
latexdiffこれは優れたユーティリティ（Perlで書かれています）で、2つのLaTeXファイルを受け取り、次のようなPDFできれいな差分出力を生成します（画像ソース):
gitとlatexdiff（latexpand必要な場合はプラス記号）を1つのコマンドで組み合わせることができます。git-latexdiff(例:git latexdiff HEAD^ワークツリーと最後から 2 番目のコミット間の差分を表示する場合)。LaTeXで長い文書を書く場合は、異なる章を独自のファイルに分割するコマンドを使用してメイン ファイルで呼び出します
\include{file}。この方法により、作業のローカライズされた部分を編集しやすくなります。また、1 つの大きなファイルのログから変更内容を把握する代わりに、各章にどのような変更が加えられたかがわかるため、バージョン管理も簡単になります。
Git を効率的に使用する:
ブランチを使用してください。おそらく、これよりよいアドバイスはありません。テキストの「さまざまなアイデア」や作業の「さまざまな状態」を追跡するには、ブランチが非常に役立つことがわかりました。ブランチは、
master最新の「公開準備完了」状態の作業の本体である必要があります。つまり、すべてのブランチの中で、自分の名前を付けてもよいと思うブランチがある場合は、それがマスター ブランチである必要があります。大学院生の場合、ブランチは非常に役立ちます。大学院生なら誰でも証言するように、指導教官は数多くの修正を行う必要があり、そのほとんどはあなたが同意できないものです。しかし、議論の後で元に戻されるとしても、少なくとも当面は変更することが求められる場合があります。そのため、そのような場合は、新しいブランチを作成して指導教官
advisorの好みに合わせて変更を加え、同時に自分の開発ブランチを維持することができます。その後、2 つをマージして必要なものだけを厳選できます。また、各セクションを別のブランチに分割し、現在のブランチに対応するセクションのみに焦点を当てることをお勧めします。新しいセクションを作成するときにブランチを生成するか、最初のコミットを行うときにダミー セクションを生成します (実際には、選択は自由です)。ブランチにいないときに、別のセクション (たとえば、セクション 3) を編集したいという衝動を抑えます。編集する必要がある場合は、このセクションをコミットし、ブランチを作成する前に他のセクションをチェックアウトします。これは、セクションの履歴を独自のブランチに保持し、また、(ツリーから) セクションの古さを一目で確認できるため、非常に便利です。セクション 3 に資料を追加したため、セクション 5 に調整が必要になったなどです... もちろん、これらは注意深く読んでいる間におそらく気付くでしょうが、セクションに飽きてきたらギアを変えることができるように、これを一目で確認できると便利です。
最近の論文のブランチとマージの例を次に示します (OS X では SourceTree を使用し、Linux ではコマンド ラインから Git を使用しています)。私が世界で最も頻繁にコミットする人ではないことや、常に役立つコメントを残す人ではないことに気付くかもしれませんが、だからといって、これらの良い習慣に従わない理由にはなりません。ここでの重要なメッセージは、ブランチでの作業が役立つということです。私の考え、アイデア、開発は非線形に進みますが、ブランチを介して追跡し、満足のいくときにマージすることができます (他に、どこにもつながらず、後で削除されたブランチもありました)。コミットに意味がある場合は、コミットに「タグ」を付けることもできます (例: ジャーナルへの最初の投稿/修正された投稿など)。ここでは、現時点での下書きである「バージョン 1」というタグを付けました。ツリーは 1 週間分の作業を表しています。
\alphaもう 1 つ便利なのは、ドキュメント全体の変更 (すべての場所への変更など\beta) を単独でコミットすることです。こうすることで、他の何かをロールバックすることなく変更を元に戻すことができます (git を使用してこれを行う方法もありますが、回避できるのであれば、そうしない手はありません)。同じことが、プリアンブルへの追加にも当てはまります。リモート リポジトリを使用して、変更を定期的にアップストリームにプッシュします。GitHub や Bitbucket (どちらも無料アカウントでプライベート リポジトリを作成できます) などの無料サービス プロバイダーがあるため、Git/Mercurial を使用している場合は、これらを使用しない理由はありません。少なくとも、LaTeX ファイルのセカンダリ バックアップ (プライマリ バックアップがあることを願います!) として、また別のマシンで中断したところから編集を続行できるサービスとして考えてください。