git + LaTeX工作流程 [英] git + LaTeX workflow

问题描述

我在LaTeX上写了一个非常长的文档。我有我的工作电脑和笔记本电脑，并且我都在他们身上工作。我需要保持两台计算机之间的所有文件同步，并且还想保留修订历史记录。我选择了git作为我的DVCS，并将我的存储库托管在我的服务器上。我还使用Kile + Okular进行编辑。 Kile没有集成的git插件。我也没有和任何人合作。如果我的服务器出于某种原因无法访问，我还想考虑在codaset上放置另一个私有存储库。

这种情况下推荐的工作流程实践是什么？在这个工作方案中如何安装分支？有没有办法比较同一个文件的两个版本？如何使用存储？

解决方案

改变您的LaTeX工作流程：

有效管理git + latex工作流程的第一步是对LaTeX习惯进行一些更改。

• 首先，将每个句子写在另一行上。 Git被写入版本控制源代码，其中每行不同并且具有特定目的。当您在LaTeX中编写文档时，您通常会根据段落进行思考并将其编写为自由流动的文档。但是，在git中，对段落中单个单词的更改会记录为对整个段落的更改。
  
  

  一个解决方案是使用 git diff --color-words （ （例如。 git latexdiff HEAD ^ 查看您的工作树和最后一个提交之间的区别）。




• 如果你正在用乳胶书写一个长文档，我建议将不同的章节分成自己的文件并使用 \include {file} 命令在主文件中调用它们。通过这种方式，您可以更轻松地编辑工作的本地化部分，而且版本控制也更容易，因为您知道对每章进行了哪些更改，而不必从一个大的日志中找出它文件。

高效使用git：

• 使用分支机构。也许没有更好的建议，我可以给。我发现分支机构对记录文本或工作不同状态的不同想法非常有帮助。 master 分支应该是您最主要的工作主体，即最新的准备发布状态，即如果所有分支中有，您是否愿意把你的名字，它应该是主分支。

  
  
  

  如果您是研究生，分支也非常有用。正如任何研究生会证明的那样，这位顾问肯定会有很多更正，其中大部分你都不同意。然而，即使它们在讨论后回复，也可能会被他们暂时改变。因此，在这种情况下，您可以创建一个新的分支顾问并根据他们的喜好进行更改，同时维护您自己的开发分支。然后你可以将两者合并，然后选择你需要的东西。

我也建议将每个部分分成不同的分支，并且只关注对应于分支，你在。当您进行初始提交时（您的选择，实际），当您创建新的部分或虚拟部分时产生分支。当你不在其分支时，抵制编辑另一部分（比如3）的冲动。如果你需要编辑，提交这个，然后在分支之前签出另一个。我觉得这非常有帮助，因为它将该部分的历史记录保留在其自己的分支中，并且还会一目了然地告诉您（某棵树）某个部分的年龄。也许你已经将材料添加到第3部分，需要对第5部分进行调整......当然，在仔细阅读过程中，很可能会观察到这些内容，但是我发现有助于一目了然地看到此内容，以便我可以如果我厌倦了某个部分，换档。




下面是我的分支和最近一篇论文的合并示例（我在OS X上使用SourceTree，从Linux上的命令行）。你可能会注意到，我并不是世界上最常见的提交者，也不会一直留下有用的评论，但这不是你遵循这些良好习惯的理由。主要的外带信息是在分支机构工作很有帮助。我的想法，想法和发展都是非线性的，但我可以通过分支机构跟踪它们，并在满意时合并它们（我还有其他分支机构，这些分支机构无处不在，后来被删除）。如果它们有意义，我也可以标记提交（例如，最初提交给期刊/修改的提交/等）。在这里，我将它标记为版本1，这是草稿现在的位置。树代表了一周的工作。







• 另一个有用的做法是对文档进行全面更改（例如更改 \alpha 到 \ beta 到处）提交。这样，你可以恢复更改而不必回滚其他任何东西（有办法可以使用git来做到这一点，但是，嘿，如果你可以避免它，那么为什么不呢？）。这同样适用于序言部分。




• 使用远程仓库并定期将更改推送到上游。有了像github和bitbucket这样的免费服务提供商（后者甚至允许您使用免费账户创建私人回购协议），如果您使用git / mercurial，没有理由不使用这些服务。至少，考虑将它作为辅助备份（我希望你有一个主要的备份！），用于你的胶乳文件和一项服务，它允许你从不同机器上的位置继续编辑。

I'm writing a very long document in LaTeX. I have my work computer and my laptop, and I work on them both. I need to keep all the files synchronized between the two computers, and also would like to keep a revision history. I chose git as my DVCS, and I'm hosting my repository on my server. I'm also using Kile + Okular to do the editing. Kile doesn't have an integrated git plugin. I'm also not collaborating with anyone on this text. I'm also thinking about putting another private repository on codaset, if my server for some reason is not accessible.

What is the recommended workflow practice in this case? How can branching be fitted in this working scheme? Is there a way to compare two versions of the same file? What about using a stash?

解决方案

Changes to your LaTeX workflow:

The first step in efficiently managing a git+latex workflow is to make a few changes to your LaTeX habits.

• For starters, write each sentence on a separate line. Git was written to version control source code, where each line is distinct and has a specific purpose. When you write documents in LaTeX, you often think in terms of paragraphs and write it as a free flowing document. However, in git, changes to a single word in a paragraph get recorded as a change to the entire paragraph.

  One solution is to use git diff --color-words (see my answer to a similar question where I show an example). However, I must emphasize that splitting into separate lines is a much better option (I only mentioned it in passing in that answer), as I've found it to result in very minimal merge conflicts.

• If you need to look at the code diff, use git's native diff. To see the difference between two arbitrary commits (versions), you can do so with the shas of each of the commits. See the documentation for more details and also this question

  On the other hand, if you need to look at the diff of your formatted output, use latexdiff which is an excellent utility (written in perl) that takes two latex files and produces a neat diffed output in pdf like this (image source):

  You can combine git and latexdiff (plus latexpand if needed) in a single command using git-latexdiff (e.g. git latexdiff HEAD^ to view the diff between your worktree and the last-but-one commit).

• If you're writing a long document in latex, I'd suggest splitting different chapters into their own files and call them in the main file using the \include{file} command. This way it is easier for you to edit a localized part of your work, and it is also easier for version control, as you know what changes have been made to each chapter, instead of having to figure it out from the logs of one big file.

Using git efficiently:

• Use branches!. There is perhaps no better advice I can give. I've found branches to be very helpful to keep track of "different ideas" for the text or for "different states" of the work. The master branch should be your main body of work, in its most current "ready to publish" state i.e., if of all the branches, if there is one that you are willing to put your name on it, it should be the master branch.

  Branches are also extremely helpful if you are a graduate student. As any grad student will attest, the advisor is bound to have numerous corrections, most of which you don't agree with. Yet, you might be expected to atleast change them for the time being, even if they are reverted later after discussions. So in such cases, you could create a new branch advisor and make changes to their liking, at the same time maintaining your own development branch. You can then merge the two and cherry pick what you need.

• I would also suggest splitting each section into a different branch and focus only the section corresponding to the branch that you're on. Spawn a branch when you create a new section or dummy sections when you make your initial commit (your choice, really). Resist the urge to edit a different section (say, 3) when you're not on its branch. If you need to edit, commit this one and then checkout the other before branching. I find this very helpful because it keeps the history of the section in its own branch and also tells you at a glance (from the tree) how old some section is. Perhaps you've added material to section 3 that requires tweaking to section 5... Of course, these will, in all probability, be observed during a careful reading, but I find it helpful to see this at a glance so that I can shift gears if I'm getting bored of a section.

  Here's an example of my branches and merges from a recent paper (I use SourceTree on OS X and git from the command line on Linux). You'll probably notice that I'm not the world's most frequent committer nor do I leave useful comments all the time, but that's no reason for you not to follow those good habits. The main takeaway message is that working in branches is helpful. My thoughts, ideas and development proceeds non-linearly, but I can keep track of them via branches and merge them when I'm satisfied (I also had other branches that led nowhere that were later deleted). I can also "tag" commits if they mean something (e.g., initial submissions to journals/revised submissions/etc.). Here, I've tagged it "version 1", which is where the draft is as of now. The tree represents a week's worth of work.

• Another useful thing to do would be to make document wide changes (such as changing \alpha to \beta everywhere) commits on their own. That way, you can revert changes without having to rollback something else along with it (there are ways you can do this using git, but hey, if your can avoid it, then why not?). The same goes for additions to the preamble.

• Use a remote repo and push your changes upstream regularly. With free service providers like github and bitbucket (the latter even allows you to create private repos with a free account), there is no reason to not be using these if you're working with git/mercurial. At the very least, consider it as a secondary backup (I hope you have a primary one!) for your latex files and a service that allows you to continue editing from where you left on a different machine.

这篇关于git + LaTeX工作流程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！