我是一名作家，不是程序员。我现在才第一次了解版本控制及其工作原理，我想知道版本控制如何简化我的工作流程。
多年来，我一直使用自己拼凑的版本控制。我的文件夹中堆满了这样的文件：resume-2012-06-01.doc、resume-2012-06-15.doc、letter.txt、letter-old.txt、letter-v2.txt、story-notes.txt、story-notes-with-character-sketches.txt、story_draft1.txt、story_draft2.txt、story_draft2-shorter.txt 等。
因为我单独工作，所以我永远不会进行分支或合并——只会在进行过程中提交，并偶尔引用文件的旧版本。
使用版本控制来管理单独作者的写作工作流程的最佳实践是什么？
我在 OSX 上，我打算使用 Git 或 Mercurial（仍在决定使用哪一个）。
- 我是否应该将整个 Documents 文件夹作为单个存储库进行版本控制？（它包含子文件夹，如 Documents/stories/anguish/characters/、Documents/stories/anguish/drafts/、Documents/stories/anguish/brainstorming、Documents/resume/、Documents/letters/ 等）。或者我应该为每个项目创建单独的存储库？或者甚至为写作项目中的每个子文件夹创建单独的存储库（/interviews/、/web-research/、/story-drafts/ 等）？
- 拥有多个较小的存储库比拥有一个大的存储库有哪些优势？
- 我是否仍应手动维护某些版本控制？例如 draft1.txt、draft2.txt、draft2-shorter.txt 等？还是应该让版本控制系统帮我完成所有这些工作？
- 过去，我尝试从不删除任何内容，而是将旧文件存放在名为 backups/、archives/ 或 old-version 的文件夹中。现在我使用版本控制，我可以随意删除不再需要的文件吗？
答案1
我是否应该将整个 Documents 文件夹作为单个存储库进行版本控制？
我强烈建议采用每个项目一个存储库的方法（假设项目彼此独立）。
想想看：如果你要回顾某个项目 3 个月前的版本 - 你是否还想让所有其他项目都恢复到同一日期？当你想查看自上次提交以来所做的所有更改时 - 你会针对每个项目进行查看，还是针对整个 Documents 目录[1] 进行查看？
您不应将内容拆分到项目级别以上：将您当前的子目录保留为每个存储库中的目录。这样，单个提交可以保存例如对草稿文件的更改、为某个角色引入新的背景故事以及对同一角色的传记文件的更新，其中详细介绍了这个新的背景故事。稍后，如果您想删除（“还原”）这个故事，您有一个单独的提交，其中所有内容已经绑定在一起。
这种将多个文件的逻辑相关更改放在一起（附上解释更改的额外注释）的能力可能是我使用单个用户版本控制的最重要的理由（而不是简单的基于日期的备份）。后来，当我看到一些奇怪的东西并问自己“我在想什么”时，这是一个很容易回答的问题。
关于您没有问到的事情，还有一些评论：
分支 - 您可能会发现这对于“测试”一个想法很有用 - 我不知道这在写作中有多常见。在编程中，我可能会尝试需要多次提交的东西，但不确定它是否会成功 - 因此明确分支感觉“更安全”，而不是必须回到我认为我开始的时候。
Git（可能还有 Mercurial）主要是为源代码设计的；它们通常以行为基础比较文件，这对您来说可能意味着整段。更重要的是，如果您的文件不是纯文本（例如，如果您使用 Word），则设置它们以“理解”所做的更改非常困难，在某些情况下甚至是不可能的。如果您的版本控制系统无法看到您所做的更改，您将失去其许多好处。
[1] 即使您对所有内容都使用单个 repo，您实际上也可以在每个子目录的基础上执行此操作，并且不需要做太多工作；但如果您总是要这样做，请将它们分开。
答案2
我是否应该将整个 Documents 文件夹作为单个存储库进行版本控制？
是的，我会从这个开始。随着时间的推移，如果你觉得这个仓库太笨重，你可以把它分成几个仓库。一个仓库的好处是可以同时看到你对整个 Documents 文件夹的更改。如果使用单独的仓库，你必须进入每个文件夹才能进行提交。
拥有多个较小的存储库比拥有一个大的存储库有哪些优势？
拥有较小的存储库意味着每个存储库的大小较小。如果你想要共享一些文档，拥有几个存储库而不是一个存储库可能会更容易。或者可能有一个“私有”存储库和一个“公共”存储库。
我是否仍应手动维护某些版本控制？例如 draft1.txt、draft2.txt、draft2-shorter.txt 等？还是应该让版本控制系统帮我完成所有这些工作？
使用 git 你可以 主题分支 将文件带往不同的方向。
A--B--C--D--E--F (master)
\
X--Y--Z (shorter)
过去，我尝试从不删除任何内容，而是将旧文件存放在名为 backups/、archives/ 或 old-version 的文件夹中。现在我使用版本控制，我可以随意删除不再需要的文件吗？
git 会智能地存储你对任何文件所做的所有更改。因此，如果你想回溯一天或一年，你可以这样做。如果出于某种原因你需要删除某个文件，你可以
git rm draft1.txt
git commit -m 'remove unused file'
答案3
我是否应该将整个 Documents 文件夹作为单个存储库进行版本控制？（它包含子文件夹，如 Documents/stories/anguish/characters/、Documents/stories/anguish/drafts/、Documents/stories/anguish/brainstorming、Documents/resume/、Documents/letters/ 等）。或者我应该为每个项目创建单独的存储库？或者甚至为写作项目中的每个子文件夹创建单独的存储库（/interviews/、/web-research/、/story-drafts/ 等）？
通常情况下，您会为每个项目创建一个存储库，但对于您的情况，我认为这并不重要。基本上，如果您是唯一一个负责所有工作的人（您不会与其他人共享部分），那么一个存储库可能就足够了。
拥有多个较小的存储库比拥有一个大的存储库有哪些优势？
最重要的是，阻止一个存储库中的灾难影响另一个存储库:)
我是否仍应手动维护某些版本控制？例如 draft1.txt、draft2.txt、draft2-shorter.txt 等？还是应该让版本控制系统帮我完成所有这些工作？
绝对是后者。
过去，我尝试从不删除任何内容，而是将旧文件存放在名为 backups/、archives/ 或 old-version 的文件夹中。现在我使用版本控制，我可以随意删除不再需要的文件吗？
备份整个仓库。将其安全地存储在云端某处。确保您知道如何根据需要恢复旧版本。
答案4
我是否应该将整个 Documents 文件夹作为单个存储库进行版本控制？
不。对于“我可以吗”类型的问题，答案不是那么必要，但“每个项目一个存储库”有很多优点
- 存储库中所有对象的共同历史意味着一个项目的演变不会影响其他项目
- 对于多文件项目，您可以轻松地将文件拆分成子项目（如果需要的话）
拥有多个较小的存储库比拥有一个大的存储库有哪些优势？
可管理性、克隆|拉取|推送的（可能）传输的大小、每个存储库的大小
我是否仍应该自己手动维护某些版本控制？
你能使用标签/书签，以便在存储库的任何变更集的历史记录中获得比哈希 ID 更好记|更具信息量的标签（实际上，对于任何工作状态）
现在我正在使用版本控制，我可以随意删除不再需要的文件吗？
是的，如果你保存已完成工作的存储库（在某个备份位置），你将获得具有附加值的旧结果（“文件”）“完整的更改历史记录，而不仅仅是最终状态”