因此，我知道你们中的大多数人因为当前不使用任何源代码管理而对我皱着眉头。现在，我已经花了一些时间在此处阅读问题/答案，我确实想这样做。我是一个爱好编程的人，确实做的不多，但修修补补，但现在我已经被咬了好几次了，因为没有方便的"时间机器" ...

我仍然必须决定要使用哪种产品，但这与这个问题无关。

我真的在源代码控制下为文件流而苦苦挣扎，以至于我什至不知道如何明智地提出这个问题。

目前，我有一个目录层次结构，所有我的PHP文件都位于Linux环境中。我在那里编辑它们，可以在浏览器中单击刷新以查看发生了什么。

据我了解，我的文件现在位于其他位置。当我要编辑时，将其签出并进行编辑。但是我能替代F5吗？我该如何测试？我是否必须重新签入，然后按F5键？我承认我的工作经历了很多尝试和错误。我怀疑我会因为经常进行的微小更改而厌倦了快速签入和签入。我一定要丢失一些东西，对吧？

谁能一步步指导我了解所有事物的生存方式以及我在测试过程中如何进行测试，同时又能真正实现方便使用"时间机器"的目标？

解决方案

回答

Eric Sink在源代码控制基础上有很多文章。他的公司(Sourcegear)制造了一种称为Vault的源代码控制工具，但是该方法通常与系统无关。

回答

我们仍将硬盘上的所有文件准备好用于F5！

区别在于我们可以将文件"检查点"到存储库中。日常生活根本不需要改变。

回答

我们可以对当前工作所在的目录进行"签出"，因此不必更改。基本上，工作目录不需要更改。

回答

这是一个悬而未决的问题，因为我们如何使用SCM很大程度上取决于我们选择的SCM。像git这样的分布式SCM与像Subversion这样的集中式SCM完全不同。

svn对于"新用户"来说更容易消化，但是git可以更强大，并改善工作流程。 Subversion还具有非常出色的文档和工具支持(例如trac)，以及一本在线图书，我们应该阅读以下内容：

http://svnbook.red-bean.com/

它将涵盖源代码管理管理的基础知识，无论我们最终选择哪种SCM，它都会以某种方式为我们提供帮助，因此，我建议略读前几章。

编辑：顺便说一句，我指出为什么人们对此不满意：SCM不仅仅是一个"代码备份"。拥有" timemachine"与SCM完全不同。使用SCM，我们可以返回更改历史记录，查看我们实际更改的内容以及何时更改代码是永远无法获得的。我确信我们已经多次问自己："这段代码是如何到达这里的？"或者"我认为我已修复该错误"-如果我们这样做了，那就是为什么需要SCM的原因。

回答

如果我们使用的是Subversion，则只需签出一次文件。然后，每当进行了较大的更改(或者要去吃午餐或者其他任何东西)时，就将它们提交到服务器。这样，我们可以通过按F5键保持原来的工作流程，但是每次提交时，我们都将所有文件的当前状态保存在SVN存储库中。

回答

取决于源控制系统，"结帐"可能意味着不同的含义。在SVN世界中，这仅意味着从存储库中检索(可能是更新，可能是新文件)最新副本。在源代码安全的世界中，这通常意味着更新现有文件并对其进行锁定。以下文本使用SVN含义：

使用PHP，我们要做的是将整个项目/站点签出到测试apache站点上的工作文件夹中。我们应该设置存储库，这样就可以通过一次检出(包括所有必要的子文件夹)来进行此操作。我们签出项目以进行一次设置。

现在，我们可以进行更改，然后按F5键可以正常刷新。如果对支持特定修订或者功能的一组更改感到满意，则可以作为一个单元提交(当然要带有适当的注释)。这会将最新版本放入存储库中。

一次签出/提交一个文件会很麻烦。

回答

实际上，文件存储在源存储库中(大写字母代表硬盘上其他位置，或者其他位置的硬盘驱动器)，也可以存在于本地计算机上，也就是现在存在的位置。

因此，如果我们使用的是VSS(不确定SVN，CVS等)，则所有未检出的文件都将标记为"只读"。因此，我们仍然可以通过单击" F5"来运行网站，它将重新加载文件当前所在的位置。如果我们检出并对其进行编辑，则它将变为非只读状态，我们可以对其进行更改。

无论如何，我们正在运行的Web服务器将加载具有相同效果的只读/可写文件。

回答

取决于我们使用的源代码管理系统。例如，对于Subversion和CVS，文件可以位于远程位置，但是我们始终在本地签出自己的副本。该本地副本(通常称为"工作副本")只是文件系统上的常规文件，带有一些元数据，可让我们将更改上传回服务器。

如果我们正在使用Subversion，这是一个很好的教程。

回答

• 不要在生产中编辑代码。
• 用适当的服务(apache w / mod_php)创建一个开发环境。
• 开发环境中的应用程序目录是我们执行工作的地方。
• 将我们当前的生产应用程序放在那里。
• 将此目录提交到源代码管理工具。 (现在我们已经在应用程序中填充了源代码管理)
• 在新的开发环境中进行更改，当我们要查看/测试所做的更改时，请按F5键。
• 合并/提交对源代码管理的更改。

回答

我们无需"大刀阔斧"地改变工作流程。我们可以，在某些情况下应该这样做，但这不是版本控制所规定的。

我们只需像平常一样使用文件即可。仅在版本控制下，一旦达到"完成"或者至少"正在运行"的某种状态(在问题跟踪器中解决了问题，完成了某种方法，对某些内容进行了调整等)，就可以将其签入。

如果我们有多个开发人员在代码库上工作，请确保定期进行更新，以便始终使用最新(合并)的代码版本进行工作。

回答

源代码控制系统通常是文件及其历史记录的存储位置，通常与当前正在处理的文件分开。这取决于版本控制系统的类型，但是假设我们使用的是类似CVS的东西(例如Subversion)，那么所有文件都将存放在两个(或者更多)位置。我们将文件放在本地目录(即所谓的"工作副本")中，并在存储库中找到一个文件，该文件可以位于通常通过网络访问的另一个本地文件夹或者另一台计算机上。通常，在首次将文件导入到存储库后，请在工作文件夹下将其检出，并在其中继续进行处理。我认为这将是我们现在的PHP文件所在的文件夹。

现在，当我们签出副本并进行一些要"保存"的重要更改时会发生什么？我们只需将工作副本中的更改提交到版本控制系统即可。现在，我们有了更改的历史记录。如果我们随时希望返回所做更改的版本，则只需将工作副本还原为较旧的修订版(即一次提交的一组更改的名称)。

请注意，这都是CVS / SVN特有的，因为GIT的工作方式略有不同。我建议从颠覆开始，阅读非常出色的SVN手册的前几章，以入门。

回答

这都是非常主观的，具体取决于我们决定使用的源代码管理解决方案。我们一定要研究的是Subversion。

我们提到我们正在使用PHP，但是我们是在Linux环境还是Windows中进行的呢？这并不是很重要，但是在PHP环境中工作时通常要做的是具有生产分支和开发分支。这使我可以配置cron作业(Windows中的计划任务)，以自动从生产服务器的生产就绪分支中提取，同时从我的开发服务器的开发分支中提取。

确定工具后，我们应该真正花一些时间来学习它的工作原理。例如，签入和签出的概念并不适用于所有源代码管理解决方案。无论哪种方式，我都强烈建议我们选择允许分支的一种。本文介绍了在生产环境中要遵循的出色的(在我看来)源代码控制模型。

当然，我声明所有这些年来都没有"修补"。我从事专业开发已有一段时间了，我的技术可能对我们所处位置的人来说是过大的。但是，这并不是说这有什么问题。

回答

这是与非集中式源代码控制系统(例如CVS或者Subversion)一起使用的常规工作流程：首先，将当前项目导入到所谓的存储库中，即所有文件的版本存储。仅注意导入手工生成的文件(源，数据文件，makefile，项目文件)。生成的文件(目标文件，可执行文件，生成的文档)不应放入存储库中。

然后，我们必须签出工作副本。顾名思义，这里是我们进行所有本地编辑，编译和将测试服务器指向的地方。基本上，它是我们以前工作场所的替代者。每个项目只需要执行一次这些步骤(尽管我们当然可以签出多个工作副本)。

这是基本的工作周期：首先，我们将存储库中所做的所有更改签入本地工作副本。在团队中工作时，这将带来其他团队成员自上次签出后所做的任何更改。然后，我们开始工作。完成一组工作后，我们应该再次签出当前版本，并解决由于其他团队成员的更改而可能引起的冲突。 (在一支训练有素的团队中，这通常不是问题。)测试，当一切按预期进行时，我们可以提交(签入)更改。然后，我们可以继续工作，再次完成后，签出，解决冲突，然后再次签入。请注意，我们只应提交经过测试并可以工作的更改。签入的频率取决于口味，但一般规则规定，一天结束时至少应提交一次更改。就个人而言，基本上，每当我进行一组可通过所有测试的相关更改时，我所做的更改要多得多。

回答

我只想补充一点，我认为最容易建立和使用的系统是Mercurial。如果我们是一个人工作而不是一个团队工作，则只需在常规工作文件夹中对其进行初始化，然后从那里继续。正常的流程是使用我们喜欢的编辑器编辑任何文件，然后进行检入(提交)。
我没有尝试过GIT，但我认为它非常相似。开始使用Monotone有点困难。这些都是分布式源代码控制系统。

回答

听起来我们在询问如何使用源代码管理来管理发行版。

以下是一些并非特定于网站的一般指导：

• 使用本地副本进行更改
• 检入(如果适用)并在签入之前测试更改
• 尽可能频繁地(至少每天一次)运行自动构建和测试
• 版本化日常构建(具有某种方式来指定与特定构建和测试运行相对应的确切代码位)
• 如果可能，对主要版本使用单独的分支(或者具有开发和发布分支)
• 必要时，稳定代码库(定义一组测试，以便通过所有这些测试，意味着我们对产品的质量有足够的信心来发布它，然后驱使测试失败为0，即禁止将任何签入发布分支除了解决未解决的问题)
• 当构建具有所需功能并通过所有必要的测试时，请对其进行部署。

如果团队很小，产品稳定，构建快速，高效，高质量的测试，则整个过程可能是100％自动化的，并且可能在几分钟内完成。

回答

好问题。使用源代码控制，我们仍然可以执行" F5"刷新过程。但是在每次编辑(或者进行少量次要编辑)之后，我们都希望签入代码，以便备份副本。

根据源代码管理系统的不同，我们不必每次都明确地检出文件。只需编辑文件即可将其签出。我编写了一个可视化的源代码控制指南，许多人发现在使用基础知识时都非常有用。

回答

我建议使用Subversion。即使从命令行，设置存储库并使用它实际上也很简单。这是怎么回事：

1)确保服务器上已安装Subversion

$ which svn
/usr/bin/svn

这是一个告诉我们通往另一个工具的路径的工具。如果未返回任何信息，则说明系统上未安装该工具

1b)如果没有，得到它

$ apt-get install subversion

apt-get是将其他工具安装到系统上的工具

如果那不是apt中颠覆的正确名称，请尝试此操作

$ apt-cache search subversion

或者这个

$ apt-cache search svn

找到正确的软件包名称并使用apt-get install packagename进行安装

2)在服务器上创建一个新的存储库

$ cd /path/to/directory/of/repositories
$ svnadmin create my_repository

svnadmin create reponame在当前工作目录(pwd)中使用名称reponame创建新的存储库

正式完成创建存储库

1)确保按照上述说明在本地计算机上安装了Subversion

2)将存储库检出到本地计算机

$ cd /repos/on/your/local/machine
$ svn co svn+ssh://www.myserver.com/path/to/directory/of/repositories/my_repository

svn co是我们用于检出存储库的命令

3)创建初始目录结构(可选)

$ cd /repos/on/your/local/machine
$ cd my_repository
$ svn mkdir branches
$ svn mkdir tags
$ svn mkdir trunk
$ svn commit -m "Initial structure"

svn mkdir运行常规的mkdir，并在输入svn mkdir后使用我们提供的名称在当前工作目录中创建一个目录，然后将其添加到存储库中。

svn commit -m""将更改发送到存储库并进行更新。无论我们在-m之后的引号中放置的内容，都是此提交的注释(计数)！

代码的"工作副本"将放在主干目录中。分支用于在主干以外的单个项目上工作；分支中的每个目录都是不同子项目的主干副本。标签用于更多版本。我建议只专注于主干一段时间并习惯Subversion。

1)将代码添加到存储库

$ cd /repos/on/your/local/machine
$ svn add my_new_file.ext
$ svn add some/new/directory
$ svn add some/directory/*
$ svn add some/directory/*.ext

在倒数第二行中，将添加该目录中的每个文件。最后一行添加每个扩展名为.ext的文件。

2)检查存储库状态

$ cd /repos/on/your/local/machine
$ svn status

它将告诉我们是否有任何新文件，更新文件以及有冲突的文件(本地版本与服务器上的版本之间的差异)等。

3)更新存储库的本地副本

$ cd /repos/on/your/local/machine
$ svn up

更新会从我们尚未拥有的服务器中获取任何新更改

svn up确实会关心我们所在的目录。如果要更新整个存储库，请确保我们位于存储库的根目录中(位于中继线以上)。

这就是我们真正需要了解的所有内容。有关更多信息，我建议我们签出Subversion Book。

回答

我建议使用分布式版本控制系统(Mercurial，Git，Bazaar，Darcs)，而不是集中式版本控制系统(CVS，SVN)。它们更容易设置和使用。

尝试Mercurial(这是我用来了解版本控制的工作原理的VCS)，然后，如果我们愿意，甚至可以转到git。

Mercurial主页上有一个非常不错的入门教程：了解Mercurial。这将向我们介绍有关VCS的基本概念以及工作原理。真的很棒之后，我建议我们转到Mercurial教程：Mercurial教程页面，该页面将教我们如何实际使用Mercurial。最后，我们有一本免费的电子书，该书对如何使用Mercurial起到了很大的帮助：Mercurial的分布式修订控制

如果我们感觉更冒险，想立即开始使用Git，那么这本免费的电子书是一个不错的起点：Git Magic(非常容易阅读)

最后，无论我们选择哪种VCS工具，最终都会做以下事情：

• 有一个我们不手动编辑的存储库，仅适用于VCS
• 有一个工作目录，我们可以像往常一样在其中进行更改。
• 更改所需的内容，并按多次F5. 当我们喜欢完成的工作并认为我们想按当时的方式保存项目时(就像我们在用Word编写某些内容时一样)，则可以提交更改到存储库。
• 如果我们需要回到项目中的特定状态，现在可以执行此操作。

就是这样。