Subversion，Git或类似版本控制系统入门以保存文件历史记录？[关闭]

我意识到这可能是一个表面上的广泛问题，但是我正在寻找人们用来在WordPress网站上保留已编辑文件的版本历史的设置/工作流程的特定示例。例如，在开发站点时（甚至在其上线时），我经常对CSS和PHP文件进行更改，但是我没有很好的方法来恢复这些文件的旧版本。出于我的目的，在本地开发安装上进行更改，然后将这些更改复制到实时站点通常比我想要的麻烦得多。关于如何开始使用版本控制工具跟踪对实时站点中文件的编辑的任何建议？

我不确定您对使用版本控制了解多少，但是最近我从SVN切换到了Git，发现它很棒！

尽管这取决于您的活动站点的服务器已安装Git（或会让您）。我还在实时服务器上也安装了Git，并在名为之类的分支下运行production。每当我在本地完成实现/修复的问题时，我都会将其合并到production分支中，然后将SSH合并到实时站点的服务器中，并进行更改。当您不知道是否要覆盖更改等内容时，可以胜过通过FTP拖动文件。

我建议您花一些时间来熟悉Git（如果您还没有的话），在更改/添加文件负载时，我发现它比SVN更容易，而且麻烦更少（而且与SVN不同，它并不愚蠢）.svn文件夹到处）。

我在Mac上，如果不能满足所有条件，则感到抱歉，但是我将Coda用作代码编辑器，并通过Ports（使用Porticus）安装了Git。

如果我要重新设置所有内容，则可以执行以下操作：

1. 安装Coda

2. 安装Porticus（这将要求您安装端口，但是该页面上有信息）

3. 安装Porticus后，将其打开打开，搜索“ git-core”并安装。

4. 下载并安装GitX 7-5

5. 在此处设置git repo有很好的指导，但基本操作是：1.打开Terminal。2. cd到您希望站点驻留的位置。$: mkdir mysite && cd mysite3. $: git init就是这样！如果您将文件添加到此文件夹，请继续执行下一步

6. 一旦在本地设置了一个GIT存储库（上一篇文章），那么如果您在GitX中打开该目录，您将能够提交诸如此类的东西。

在服务器上进行全部设置可能有些棘手，我有一个MediaTemple和Dreamhost帐户，它们都具有开箱即用的GIT。第5步中的链接告诉您如何添加远程回购，因此，在您要将现场站点纳入方程式之前，不必这样做。我建议首先使所有内容在本地运行（与SVN不同，GIT不需要远程存储库，因此您可以暂时在计算机上进行所有操作）。

我将SVN用于WordPress开发中所做的所有操作的版本控制。实际上，我之所以这样开始，是因为我需要SVN进行插件开发……从那里开始，这是自然的扩展，可以继续将SVN用于客户端站点上的主题和自定义脚本。

外挂程式

由于插件已经托管在WordPress的服务器上，因此我只需将插件直接检出到/wp-content/plugins/本地WordPress安装目录中即可（我在开发盒上运行WAMP）。然后，我对本地副本进行更改，并在准备好放映时将其提交到存储库。那里的过程很顺利，没有上传/下载和即时验证我的更改是否有效的信息。

主题

主题有些不同，尤其是在为客户构建时。我创建一个本地存储库（R为此，我在硬盘驱动器上有一个分区），然后将空存储库直接检出到我的/wp-content/themes目录中。然后，我根据需要进行更改并进行开发，直到准备就绪为止，然后再进行修订。

当我准备将主题发布到客户端的生产服务器时，我导出存储库，将其压缩，然后使用WordPress中的本机主题>>添加新功能。这也适用于自定义插件（不是由WordPress托管）。

工具类

就像我说的那样，我在本地计算机上使用WAMP来运行WordPress的开发安装。它可以在我的盒子上完美运行，并允许我运行特定项目所需的WordPress实例。

对于SVN，我使用Tortoise SVN。它是免费的，非常易于使用，并且与Windows的文件和命令结构集成在一起。只需单击鼠标右键，然后选择命令操作，即可进行更新，提交和导出。使用“导出”可以将整个文件夹（没有烦人的.svn文件夹）直接发送到您选择的任何位置-我经常导出到桌面。压缩文件夹也是一种右键单击操作，WordPress会处理上传。

手动传输文件可能会很麻烦，特别是如果您不断更改一个文件但并非全部更改时，尤其如此。如果您改为在FTP上选择“覆盖全部”，则覆盖整个目录，则替换旧文件要容易得多（并且不必跟踪更改的内容和未更改的内容）。就像WordPress过去的5分钟旧安装-只需用新版本替换所有内容即可。

就个人而言，我认为安装和管理SVN / GIT是一个有趣的练习，但是，如果您每月可以花15美元，Beanstalk值得每一分钱。他们为您管理整个服务器。 http://beanstalkapp.com/ FTP部署工具很棒。例如，当我提交时，我的版本会自动将版本部署到我的登台服务器

获得某些个人文件版本控制的另一种方法是使用投递箱。每次将文件保存到保管箱时，它都会跟踪版本，以后您可以还原到任何以前的版本。您和另一个开发人员或组可以共享一个保管箱文件夹。当然，这不会进行中继，合并等操作，但是它确实使分布式团队可以非常轻松地在一个网站上工作。您只是不能真正真正地一次处理完全相同的文件。

我们将SVN工作副本保存在保管箱中，然后在写入时间时提交文件。我的设计人员不会提交文件或处理SVN，所以这很麻烦。

我更喜欢SVN，因为我不需要GIT非常适合的所有中继，并且可以使用SVN更好的GUI工具。

我非常喜欢Aptana，它集成了Subversion，您可以轻松地通过ftp / sftp连接到服务器并推送文件，它的另一个强大功能是，如果您创建一个新的php项目并包含“整个” WordPress，文件夹（带有wp-admin，wp-includes），您将在主题文件中获得代码完成。

在我的设置中，存储库是本地的。

您要求“但我正在寻找人们用来在WordPress网站上保留已编辑文件的版本历史的设置/工作流程的特定示例”，但您还提到了产品：）

您在上面获得了一系列工具和最佳实践的答案，但我将在这里重点介绍工作流程：它们不是WORDPRESS专用的：

但对于一般示例/设置/工作流程：

对于初学者：有CM模式，因此与工具无关。Google在CM Patterns上有很多书籍，在Wiki上甚至还有社区，例如http://www.cmcrossroads.com/forums。

也提供有关设置有效流策略（Google流策略）等的指南。

与CM Management包括大型Siebel，SAP，Informatica，Java等工厂上的分布式并行开发相比，我认为WordPress部署没有什么特别之处。实际上，这几乎是默认值。

我认为缺少的是，没有人为WordPress开发（IEEE）写CMplan。一旦有人做到了（独立于工具）。我认为，可以使用任何工具来满足需求。

我认为尚未制定计划的原因是，几乎所有WordPress实施仍然都是由一个人完成的，只需一个简单的开发-生产设置，因此在构建阶段不必由多个开发人员/设计人员来部署正在运行的不同版本例如测试环境。

CMP计划首先要识别所有CI，即：列出WordPress实现中存在的所有类型的CI，包括应用程序，插件，数据库，文档，帮助，内容，配置文件，发行说明（！）等。 ..）。这是一个好的开始。然后决定要带给CM的人。

接下来，确定是什么原因导致这些CI发生变化，例如，客户要求修正错误或需要进行升级。如果做得正确，这会导致您感到事情在控制之中。

诸如从生产合并到开发以及如何处理该问题的决策是该章的一部分（此处为两种主要模式）（当然，您应该尝试最小化这些修补程序）。

只是以后再寻找一种工具来在一侧进行CM（其中包括版本管理作为工具之一），并在另一侧进行变更管理工具（这会使您保持理智）。

我认为这是最好的工作流程，因为据我查询，到目前为止还没有人做过。我认为，一旦第一个人编写了WordPress CM计划（根据IEEE），世界上所有其他WordPress人士都可以复制该计划，并进行调整和实施其工具中的模式。

这不是太多的工作/太重了：取决于您是否有公司：拥有良好的CM计划可以节省一天的大量时间。

我在共享主机上，因此无法安装SVN或类似的工具。我使用Mercurial对家用计算机进行版本控制。我使用Beyond Compare的FTP同步来保持本地和远程文件夹同步。

我正在使用git。这很简单。您只需要了解简单的命令，例如clone，commit，push，pull，就可以开始了。这是基本的。

即使，如果您更多地使用git，例如协调团队来开发产品，那么这是另一个层次。但最后，值得使用git或任何版本控制。发生狗屎的时候是可以实现的。