纯文本文档的简单版本控制（Linux）

#1 楼

是的，您应该使用git *。

现在让我解释一下原因。给定问题中的当前（相当模糊）的标准，答案似乎很明显。如果您知道更多，甚至都不会问这个问题。您已经把自己带到悬崖的边缘，现在您只需要哄哄就可以跳跃。

*或集市，商品或其他DVCS取决于您喜欢的前端工具，待解释..

当前的场景和一些历史：

基本上有三种版本控制系统：分布式，ham-fisted和窃听。请允许我详细介绍该技术术语，以及每种术语的含义以及如何适用于您的情况。



火腿ham

值得注意的条目*：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，BitKeeper，CA，CC，darcs，化石，单调，Perforce，塑料，PVCS，Star，SVK，Vault，Vesta，VSS和其他同类产品。您的名字将永远不会被忘记已经只是一个记忆。

git如何适合您的用例：

您提到使用过一点Github。很好，但是您需要记住Github不是git。人们通常会误以为他们提供的是通过为您托管存储库来进入系统的一种免费方法。实际上，他们提供的是在git之上构建的一层，部分是社交网络和部分项目管理。对于开源社区来说，这是一件了不起的事情。他们没有试图成为替代系统并与市场竞争，而是巧妙地利用了一个好的工具，并开辟了一个为企业提供增值服务并同时为社区服务的市场。但是Github不是git。

实际上，可以以更简单的方式使用Git。

与RCS类似，git在您的旁边存储本地版本信息。内容。显着的区别在于它是基于每个目录而不是每个文件执行此操作。



RCS：

file1.txt
file1.txt,v
file2.txt
file2.txt,v

每个文件的,v文件保留文件历史记录的运行列表，并存储每个连续版本之间的增量。


git：

 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。

看到那并不难。

#2 楼

在这种情况下，我建议使用https://draftin.com/，请参阅此处以快速了解您可能希望使用的特定功能。

我要指出的该软件的缺点在为您的问题提供详细答案之前，它是应在线使用的。可以在没有Internet连接的情况下使用草稿（请参见此处），但是它仍然需要完善-同步（草稿中的一项基本功能），在离线之前仍必须手动触发。


版本控制：可以。它是草稿中的一项核心功能，它很棒，因为它在您不想看到它时不会妨碍您，但是每次您（或与您共享写作的任何人）遇到麻烦时，它都会为您服务与文档有关。 （默认情况下，您的文档版本中不包括其他人的编辑，您必须先接受它们。）
Ubuntu / Mint友好：是的，毕竟这是一个网站。任何降级的浏览器都可以解决问题，我只测试了Chrome的脱机功能，该功能具有适用于Ubuntu的PPA。
轻松标记/注释/标签：否。关键是草稿应允许您标记文档的主要和次要版本，并明确指出谁进行了编辑，从而为您解决了这一问题。在这一点上，草稿并不是您的最佳工具。
简单的标签/标签浏览，搜索：不确定。好吧，如果为您设置的标签草稿至少适合您的需求。
以前版本的简单“恢复”：是。您不仅可以恢复以前的版本，还可以保留两个版本中的有用位，并在查看与其他任何版本的差异时编辑当前版本。
做差异的可能性：是的。有时候这件事会弄错（最烦人的情况是在重写段落时：Draftin相信我将每个句子替换为一个新句子，在diff中混合了新旧句子，而我希望将新段落与可以，但是可以使用Diff正常工作。
可以同步到不同的机器：是的，由于它的网页性质。但是，离线模式很奇怪，并且需要手动同步。
文档的简单目录结构/层次结构：是的，但是甚至太简单了。您可以将文档放在文件夹中，但是我还没有找到嵌套文件夹的方法，这是一个很大的缺点。

总而言之，草稿将其强加给用户，如果您愿意的话，这很酷它（我喜欢）。它确实值得您尝试一下，但是它的灵活性很低（如果您喜欢编码，它确实提供了API）可能会限制其范围。

#3 楼

git是版本控制的好方法。特别适用于纯文本。


调查集成在ReText中的版本控制系统支持。 （我找不到）
尝试git前端。我喜欢git-cola。
尝试使用外部差异/合并工具。我喜欢Meld。