是的，您应该使用git*.
现在让我解释一下原因。鉴于您问题中当前（相当模糊）的一组标准，答案似乎相当明显。如果你知道更多，你甚至不会问这个问题。你已经把自己带到了悬崖的边缘，现在你只需要哄着跳就行了。
* 或 Fossil、Mercurial、Darcs、Bazaar 或其他 DVCS，具体取决于您喜欢的前端工具，待解释。
当前场景和一些历史：
基本上有三种版本控制系统：distributed、ham-fisted和tapped-out。请允许我扩展该技术术语以及每个术语是如何产生的以及如何适用于您的情况。
笨手笨脚的
值得注意的条目*：CVS、Subversion。
在 DVCS 系统风靡全球之前，就有了 VCS 系统。这些可以通过中央存储库/服务器和用户工作空间/客户端的星形模式来表征。这些是一个不可或缺的宝贵工具，可以让一组程序员保持在同一页面上，甚至使自己适应其他用途。一个程序员可以在多个系统上工作，并使用分支和标签。他们节省了很多一天。但他们天生笨拙。他们使一些简单的任务变得更加困难。首先是设置它们的开销，需要服务器和特定的协议来连接它们。然后是处理那些你做错事的痛苦。可以说这些可以为您的用例完成工作，但会引入权衡取舍，使生活变得更加复杂。
出线
值得注意的条目：RCS。
因为当涉及服务器和客户端以及身份验证以及所有爵士乐的“成熟”系统难以接受时，可以使用一个生活在自己的小泡泡中的精简系统。RCS 通过避开存储库的想法并一次只对一个文件进行版本控制来做到这一点。你有file.txt并且坐在它旁边file.txt,v有版本历史。您可以在每个文件的基础上轻松实例化它，并使用一些简单的工具来处理差异、回滚时间等。
现在，在您说“啊哈，这正是我想要的！”之前，请继续阅读，因为这不再是最简单或推荐的方法了。轻松进入是以较低的运营上限为代价的，这几乎可以保证迟早会限制您的风格。
分散式
在某个时候，一群聪明的程序员认为他们已经受够了痛苦，并说：“我们要吃蛋糕，也要吃蛋糕。” 令人惊讶的是，他们成功了，分布式版本控制系统诞生了。这些系统结合了两全其美的优点——完整的版本历史记录位于您的本地系统上，紧邻原始文件，并且能够共享您的历史记录并与其他远程存储库的历史记录进行交互。事实证明，这样做没有严重的技术缺点。
对一些商店来说，最大的障碍是灵活性。由于系统不会对您的工作方式施加任意限制，因此从强制您拥有特定工作流程的系统迁移有时会很痛苦。突然之间，您必须考虑一下您希望系统如何工作。许多过去需要的东西（中央节点总是有每个人的最新东西）变成了一个只有在需要时才使用的事情约定，但你必须坐下来说：“这就是我们将如何使用这个工具的方式。”
所以让我们坐下来谈谈你将如何使用这个工具。
出于这个答案的目的，我将坚持使用 git，因为它是最广泛采用的系统之一。它很容易在大多数系统上安装（如果尚未安装），并且有大量可用的文档涵盖几乎所有用例。它也是可扩展的，并且被许多第三方系统等认可。话虽如此，它不一定比它最近的竞争对手 Bazaar 或 Mercurial 在本质上更好。
如果你生活在一个 Ubuntu 生态系统中，你可能想看看 Bazaar，因为 Canonical 将它用于一切，它会很好地与你的环境集成。他们的启动板服务类似于 Github，但为 Ubuntu 软件开发量身定制。如果你打算在那个生态系统中玩，考虑学习bzr而不是 git，这样一个工具既适用于你的个人世界，也适用于你参与的生态系统。如果你不从事在启动板上协调的项目，我建议使用 git。
如果您的任何同事对 Mercurial 很感兴趣，您可能想考虑使用它。它是一个非常强大的 DVCS，与 Git 相比具有一些优势。由于更简化的数据流，它经常被认为对某些操作更快。这些工具都封装在一个二进制文件中，而不是像 Git 那样从一堆单独的（有时是冗余的）工具中拼凑在一起。它可以使用 Python 绑定进行扩展，并且可以构建与之紧密集成的外部系统。该范例与 Git 非常相似，一旦您学习了它，您也可以在 git 存储库中犯错。最后，git 是目前该领域最受欢迎的玩家，坚持使用它会让您在需要时更容易获得帮助。
* 我对所有未命名的 VCS 系统表示歉意。CVSNT、CA、CC、Perforce、Plastic、PVCS、Star、SVK、Vault、Vesta、VSS 等等。你的名字永远不会被遗忘，已经只是记忆。
如何git适合您的用例：
你提到过使用 Github 一点。这很好，但你需要记住Github 不是 git。一种常见的误解是，他们提供的是一种通过为您托管存储库来进入系统的免费方式。实际上，他们提供的是在 git 之上构建的一个层，该层部分是社交网络，部分是项目管理。这对开源社区来说是一件好事。他们没有试图成为替代系统并与市场抗争，而是出色地利用了一个好的工具，开辟了一个市场，为企业提供增值服务，同时为社区服务。但是 Github 不是 git。
事实上，Git 可以以更简单的方式使用。
与 RCS 类似，git 将版本信息存储在本地内容旁边。门外的显着区别是它基于每个目录而不是每个文件执行此操作。
RC：
file1.txt
file1.txt,v
file2.txt
file2.txt,v
,v每个文件的文件都保留一个文件历史的运行列表，存储每个连续版本之间的增量。
混帐：
directory
+ file1.txt
+ file2.txt
+ .git
+ glob1
+ glob2
.git 文件夹中的东西实际上有时髦的名字并且有点复杂，但你不需要知道它。从概念上讲，它所做的只是将不同版本之间的差异存储在您的目录中。基本上，每个 glob 都是您的目录在每次提交时的样子的图像。许多花哨的数学可以降低开销，以便只保存增量数据。
现在这听起来可能已经很复杂了，但你真的不需要知道这些。该工具集会为您跟踪所有花哨的东西。基本用法与 RCS 一样简单，但为您提供了成长空间。
入门会是这样的：
# Change to the directory that has files you want to version.
cd ~/pathto/yourtextfiles
# Initialize git to keep track of that folder
git init
完毕。不需要服务器。只有您和您的版本控制文件。除非您还没有任何文件受到监视，所以 git 实际上并没有在看任何东西。从某种意义上说，Git 并不贪婪，它不会跟踪文件夹中的所有内容，只会跟踪您告诉它的特定内容。因此，下一步是告诉它您要跟踪哪些文件。
# Add some files to the system, assuming these already exist the your dir
git add file1.txt file2.txt
# Commit the changes you just made
git commit -m "initial add"
请注意，与大多数系统不同，这是一个两步过程。在您提交内容并将它们作为新版本填充到存储库中之前，您必须“暂存”它们。并非您对工作目录所做的每项更改都会自动假定为您希望在每次提交时保存的内容。也许您更改了两个文件，但只想标记一个。
# Edit a bunch of files
vim file1.txt
vim file2.txt
vim file3.txt
# Only mark one of them as going it your next commit
git add file2.txt
# Commit it to history
git commit -m "fixed typo"
请注意，对 file1.txt 的更改尚未保存到存储库，并且根本未跟踪 file3.txt。通过运行，您可以看到以前跟踪的文件有未暂存的更改，git status以及这些更改是什么git diff。此时状态会告诉您您已对 file1.txt 进行了更改，并且您的目录中有一个未跟踪的 file3.txt。Diff 将向您显示自上次暂存和提交以来您对 file1.txt 所做的更改。
一个“陷阱”，你应该被警告开始，这样它就不会咬你的路是 - 因为 git 的存储库的概念是一个完整的目录，对文件的更改被视为该目录的图像时间点——您应该考虑为不同的项目建立单独的存储库。与其从“我的文档”中创建单个存储库，不如从包含文档的某些有意义子集的目录中创建单独的存储库，无论是按主题、按格式还是按项目或其他。当您想在另一台机器上处理“与 x 相关的所有文档”时，这将使您在以后更轻松，而不必拥有您在该机器上创建的每个文档。Git不允许您要检查存储库的子树*，它要么全部要么全无，因此错误地为密切相关的数据集创建许多粒度存储库，每个目录一个。
实际上，这就是基本用法的全部内容。从那里开始，几乎所有你能想象到的事情都是可能的，但那时你会问一个使用问题，而不是一个软件推荐问题。
* 例如，Subversion 确实允许这样做，我已经习惯了。当我认为 git 会允许类似的事情时，这让我很早就想到了。我在一个大型 svn 存储库中拥有我所有的个人文件，并且天真地认为 git 会替代它。吸取的教训，我的文件最好被分类。
但是命令提示符很可怕！
当然，有许多前端 GUI 可让您远离命令行并直观地表示文件正在发生的事情。其中许多具有 IDE 风格，可以作为您进入文档管理的入口点，使用它们来启动您最喜欢的编辑器*，甚至使用内置编辑器。由于您询问了后端文件应如何存储的问题，因此我建议将其git用作版本管理器，但如果您想从前端的角度来看这应该如何看待和工作，您应该问这是一个单独的问题。
* 当然gvim很适合这个用例 ;-)
综上所述：
进来吧，水很好！
一！二！三！跳 git init。
看到这并不难。
版本控制（显然是必不可少的！）