构建于VCS 与 LaTeX 文档的良好工作实践是什么?,是否有最佳实践格式化(La)TeX 源文件如何利用版本控制系统?
例如,我将简历以 LaTeX 格式保存在 git 存储库中,并在分支中保存各种针对工作机会的调整。当我更新主分支上的格式或基本信息时,我会尝试重新设置调整后的分支以适应,但操作往往不太顺利。我的 C 代码没有这个问题,所以我想知道如何使用 LaTeX 源代码做得更好。
答案1
这不是一个乐观的答案,也可能不是一个很好的答案。它基于我使用的经验git
,以及我在尝试使用 git 管理多个项目中的不同配置时遇到的意外。
为什么我认为 rebase 不是答案
我认为版本控制系统的理念是针对具有异步附带事件的线性开发。我的意思是流程始终向前,而不是横向。创建分支时,它们的用途旨在提供具有以下三个命运之一的半独立开发流:
它被合并回单一的主线开发流
它停止了。一个很好的例子可能是来自Loop Space 的出色描述,或产品发布。
在某些情况下,它会停止,但会不时添加修复程序。我认为,这种情况更有可能发生在发布后的错误修复中,而不是存档文档中,因为存档文档的生命周期非常不同,使用方式也非常不同。
Rebase 是一种合并形式;从某种意义上来说,二者都旨在通过以下方式将开发流“重新整合”起来:全部历史,而当开发流实际上是不同的配置时,这并不是你想要的。模型 1 和 2 不适用于处理配置,而且,在我尝试这样做的三四次中,我总是最终不得不从备份中恢复我的完整项目和存储库。我承认这可能被视为粗心大意——我仍然在艰难地学习 git!
为什么我认为 cherry-picking 比 rebase 更好,但仍然不是答案
我尝试过的另一种选择是使用采摘樱桃。在这里,您可以选择单个提交(从概念上讲是补丁)并将它们应用于其他分支的头部。这种方法效果更好一些,但必须将更改给定配置的提交与应用于许多或所有配置的提交分开。(这可能很明显,但我经历了几次失败才学会。)
我目前正在使用这种方法来管理一个相当复杂的提案,其中我是(将来有一天)分包商。该提案有两种配置:一种是针对总承包商,一种是针对最终客户,有些部分被省略,有些部分则进行了微小的措辞更改。以这种方式管理变更需要的工作量比我预期的要多得多。
我计划对所有需要此内容的新项目做什么
最后,我得出结论,这也不是最好的方法。我现在坚信,不同的配置应该在一个分支中处理,方法是使用相对较小且简单的顶级文件,每个配置一个,输入一个或多个主文件,这些主文件通过使用verbatim
“注释”环境、comments
包或我自己的更有限的配置来配置,tagging
包进行配置(尽管在妈妈眼里,即使是秃鹫小鸡也很漂亮)。我的回答是多语言文档是一个非常简单的例子。
在这种制度下,您可以通过使用标签或分支(无论您喜欢哪种方式)来存档或提供其他后备参考点。但您的所有配置都是一起进行的,而不是分开进行的,我认为这使整个事情(两个版本和配置控制)变得容易得多。
结束语
我可以向 git 用户推荐一个积极的事情:Syntevo 的 Smartgit。它的索引编辑器允许您将更改分解为更小的位以进行多次提交,从而实现干净的挑选,并且它的存储界面干净且易于使用。
正如我在开头所说的,这可能不是最好的答案;我在这方面已经尽我所能了。所以我欢迎我的技术主管提出意见、批评和改进。
答案2
Per Loop Space 的评论如上,他的提示https://loopspace.mathforge.org/HowDidIDoThat/TeX/VCS/很方便。特别有用的是将布局代码与内容分开(无论如何都是个好主意)并管理换行。
我的句子倾向于长句和许多从句,而我的重写经常会合并或拆分这些从句,因此他关于在句子边界处断行的建议对我来说还不够;因此,我超越了这些建议,一直把我的散文写成无韵诗:在大多数标点符号和其他短语边界处断行。
我会这样写上面的段落/句子:
I tend toward long sentences with many dependent clauses,
and my rewrites often combine or split these,
so his advice about breaking lines at sentence boundaries is not quite enough for me;
I’ve therefore gone beyond those tips,
all the way to writing my prose as if it were blank verse:
breaking lines at most punctuation points
and at other phrase boundaries.
(为了说明起见,这与我实际的写作风格有些夸张。)
ETA:我刚刚发现了这种技术的名称: 语义换行. Brandon Rhodes 在关于该主题的博客文章,引用 Brian Kernighan 1974 年出版的《UNIX 初学者指南》 [PDF]:
准备文件的提示
大多数文档在最终完成之前都会经过多个版本(总是比您预期的要多)。因此,您应该尽一切可能使更改工作变得容易。
首先,当你进行纯粹的机械打字操作时,打字方式要便于后续编辑。每句话都从新行开始。尽量缩短行距,并在自然位置(例如逗号和分号后)换行,而不是随意换行。由于大多数人通过重写短语以及添加、删除和重新排列句子来更改文档,因此这些预防措施可以简化你以后必须进行的任何编辑。