有时，不仅文档本身，而且文档的处理过程也可能至关重要。 例如，在项目中，大部分工作与文档准备有关，不正确的过程可能导致错误甚至信息丢失，从而导致时间和利润的损失。 但是，即使该主题不是您工作的中心并且位于外围，正确的过程仍然可以提高文档的质量并节省您的时间。
此处概述的方法（带有
特定实现的示例）具有较低的进入阈值。 从技术上讲，明天您可以开始新的工作方式。
问题陈述
您需要创建一个特定的文档或一组文档。 也许这是项目文档或网络日志，或更简单的东西，例如，您应该描述公司或部门中的流程。 通常，我们谈论的是带有文本，图片，标牌的任何文档或一组文档...我们使任务复杂化，因为
- 这项工作涉及共同工作，一组或几组员工的努力
- 在输出中，您要具有根据特定模板创建的具有公司样式属性的特定格式的文档。 为了确定起见，我们将假定这是MS Word（.docx）
10年前，这种方法是明确的：我们将创建一个或多个MS Word文档，并以某种方式组织有关更改的工作。
而且这种方法仍然有效。 大型集成商在创建项目文档时也会使用它。 但是从直觉上很明显，如果您真的很忙，需要进行大量编辑和讨论，并且长时间处理文档，则此方法不是很方便。
例子
在一个大型集成商中工作时，我非常敏锐地感觉到了这个问题。 更改设计文档的过程如下：
- 工程师下载最新版本的MS Word（.docx）文档
- 改名
- 修改轨道模型
- 将更正后的文档发送给架构师
- 还会发送所有带有评论的更正列表
- 建筑师分析变化
- 如果一切正常，则将更改数据复制到最新版本的文件中，更改版本，然后将其放在共享资源上
- 如果有评论，则开始讨论（通过电子邮件或集会）
- 达成共识
- 其他第3-9段
尽管工作并不紧张，但还是有所进展。 但是到了某个时候，这个过程成为整个项目的瓶颈，并导致了问题。 事实是，一旦几个团队同时频繁进行更改，一切都会变得很糟。
因此，当我们进入初步测试阶段时，开始出现不同的问题，尽管在细节上，我们还是不得不经常更改文档-四个不同的团队，每天几乎同时进行讨论。 所有这些更改都是通过一位工程师-一位建筑师完成的。 该项目的设计文件很大，结果使建筑师不堪重负的日常工作涉及大量的复制，编辑，犯了很多错误，我不得不仔细检查，重新发送，总的来说这几乎是混乱的。
在这种情况下，这种方法（一种处理MS Word文档的方法）非常刺耳，产生了问题。
Git降价
面对上面示例中描述的问题，我开始研究此问题。
我看到在创建文档时结合使用
Markdown和
Git变得越来越流行。
Git是一种开发工具。 但是，为什么不将其用于记录过程呢？ 在这种情况下，解决了多用户工作的问题。 但是，为了充分利用Git功能，我们需要文档的文本格式，我们需要找到其他工具而不是MS Word，Markdown很好地满足了这些目的。
Markdown是一种简单的文本标记语言。 它旨在在常规TXT文件中创建设计精美的文本。 如果我们在Markdown中创建文档，那么Markdown-Git链接看起来很自然。
一切都会好起来，如果不是我们的第二个条件，就可以在这里结束：“在输出端，我们需要某种格式的文档，并根据特定模板创建公司样式属性”（我们首先同意当然，它将是MS Word）。 也就是说，如果我们决定使用Markdown，则需要以某种方式将此文件转换为所需类型的.docx。
有些程序可以在不同格式之间进行转换，例如
Pandoc 。
您可以使用此程序将Markdown文件转换为.docx格式。
但是，您仍然需要了解，首先，并非Markdown中的所有内容都将转换为MS Word，其次，与细长但仍然很小的小镇Markdown相比，MS Word是整个国家。 Word中包含大量内容，Markdown中没有任何形式。 您不仅可以将所需的Pandoc键的Markdown格式带入所需的MS Word形式。 因此，通常在转换后，您必须手动“优化”接收到的.docx文档，这又会很耗时并导致错误。
如果我们可以编写一个脚本来自动“完成” Pandoc无法完成的工作，那将是一个理想的解决方案。
我认为，由于MS Word和Markdown功能在通用术语上并不完全相同，因此不可能解决此问题，但是可以针对特定情况，特定要求来解决吗？ 我的经验表明，是的，有可能而且很可能在许多甚至大多数情况下都是可能的。
解决特定问题
因此，就我而言，使用Pandoc转换文件后，我必须手动进行其他文件处理，即
- 在Word中添加表格和图片的标题自动编号的字段
- 更改表格样式
我没有找到如何使用标准（Pandoc）或已知方法执行此操作的方法。 因此，我在
pywin32包中应用了python脚本。 结果，我得到了完全的自动化。 现在，我可以使用一个命令将Markdown文件转换为所需的MS Word文档格式。
在这里查看详细信息。
备注
当然，在此示例中，我将转换一些抽象的Markdown文件，但是对“战斗”文档采用了完全相同的方法，并且在输出时，我收到了几乎完全相同的MS Word文档，而以前我们是通过手动格式化收到的。
通常，使用pywin32，我们几乎可以完全控制MS Word文档，这使我们可以对其进行更改，并使其具有企业标准所需的外观。 当然，使用其他工具（例如VBA宏）也可以实现相同的目标，但是使用python更为方便。
此方法的简要公式：
Markdown + Git -- () --> MS Word
“东西”不是那么重要。 就我而言，它是Pandoc和pywin32的python。 您可能有不同的首选项，但重要的是这是可能的。 这是本文的主要内容。
总而言之，您的想法是，使用这种方法，您只能使用Markdown文件并使用Git来组织协作和版本控制，并且只有在必要时（例如，向客户端提供文档）才会自动创建所需格式的文件（例如，MS Word） ）
过程
我认为，对于上面给出的许多公式而言，足以理解现在如何组织文档处理过程。 但是，尽管如此，我通常还是专注于网络工程师，所以我将概述一下该过程现在的外观以及与编辑MS Word文件的方法有何不同。
为了确定起见，我们将选择GitHub作为与Git合作的平台。 然后，您必须创建一个存储库，并将Markdown文件或计划使用的文件放在master分支中。
我们将看一个基于github流的简单过程。 在Internet和
Habr上都可以找到它的描述。
假设有四个人在处理文档，而您是其中之一。 然后，使用这些人的姓名创建另外四个分支。 每个都在自己的分支中本地工作，并使用所有必需的
git命令进行更改。
完成一些工作后，您就可以提出请求，从而开始讨论您的更改。 也许在讨论过程中，您应该添加或更改其他内容。 在这种情况下，您需要进行必要的更改并创建其他拉取请求。 最后，您的更改被接受并与master分支合并（或被拒绝）。
当然，这是一个非常笼统的描述。 我建议与您的开发人员联系或找有知识的人来创建详细的过程。 但我要指出，进入Git的门槛非常低。 这并不意味着该协议很简单，而是可以从一个简单的协议开始。 我想，如果您什么都不知道，花了几个小时甚至几天的时间来研究和安装，您就可以开始使用它了。
例如，与上面示例中描述的过程相比，此方法有什么用？
实际上，过程非常相似，您只是替换了
复制文件->创建分支
将文本复制到最终文件->合并（合并）
将最新更改复制到自己-> git pull / fetch
对应讨论->请求请求
跟踪模式-> git diff
最新批准的版本-> master分支
备份（复制到远程服务器）-> git push
...
因此，您可以自动执行所有必须执行的操作，但是要手动执行。
在更高的层次上，这使您可以
- 创建一个清晰，简单且受控的过程来更改文档。
- 因为 您自动创建的最终文档（在我们的示例中为MS Word），这减少了与格式相关的错误的可能性
备注
鉴于上述情况，我认为很明显，即使您仅在处理文档，使用Git也可以极大地简化您的工作
所有这些都提高了文档的质量，并减少了创建时间。 还有一点好处-您将学习Git，这将帮助您自动化网络:)
如何切换到新流程？
在本文的开头，我写道，明天您可以以新的方式开始工作。 如何将您的工作向新的方向发展？
以下是您最有可能必须完成的步骤序列：
- 如果您的文档非常大，请将其分成几部分
- 将每个零件转换为Markdown（例如，使用Pandoc）
- 安装Markdown编辑器之一（我使用Typora ）
- 您极有可能需要调整创建的Markdown文档的格式
- 开始应用上一章中描述的过程
- 并行，开始修改转换脚本以适合您的任务（或创建您自己的东西）
您不必等到完美创建和调试输出文档类型所需的Markdwon->转换机制。 事实是，即使您不能快速快速地完全自动完成Markdown文件的转换，您仍然可以使用Pandoc以任何形式进行转换，然后手动将其转换为最终形式。 通常，您不需要经常执行此操作，而只需要在某些阶段的末尾执行此操作，尽管我认为此手动操作不方便，但在调试阶段仍然可以接受，并且不应大大减慢该过程。
其他所有内容（Markdown，Git，Pandoc，Typora）均已准备就绪，不需要花费特别的精力或时间即可开始使用它们。