所以我知道你们中的大多数人都对我不满意，因为我目前没有使用任何源代码控制。我想，我真的想，现在我已经花了一些时间阅读这里的问题/答案。我是一个业余程序员，除了修补外，我真的什么都不做，但我已经被咬了好几次了，没有手边的“时间机器”……
我仍然必须决定我将使用哪种产品，但这与这个问题无关。
我真的在为源代码控制下的文件流而苦苦挣扎，以至于我什至不确定如何明智地提出这个问题。
目前我有一个目录层次结构，我的所有 PHP 文件都位于 Linux 环境中。我在那里编辑它们，然后可以在我的浏览器上点击刷新，看看会发生什么。
据我了解，我的文件现在位于不同的位置。当我想编辑时，我会检查它并编辑掉。但是我的 F5 的替代品是什么？我该如何测试它？我必须重新签入，然后按 F5 吗？我承认在我的工作中有很多尝试和错误。我怀疑我会厌倦快速签入和签出，因为我倾向于进行频繁的小改动。我必须错过一些东西，对吧？
任何人都可以带我了解所有事物的存在以及我如何测试，同时保持手边拥有“时间机器”的目标吗？
Eric Sink 有很多关于源代码控制基础的文章。他的公司 (Sourcegear) 制作了一个名为 Vault 的源代码控制工具，但操作方法通常与系统无关。
实际上，您的文件虽然存储在源存储库中（硬盘驱动器上的另一个位置或其他地方的硬盘驱动器），但也可以存在于您的本地计算机上，就像它们现在存在的位置一样。
因此，如果您使用 VSS（不确定 SVN、CVS 等），所有未检出的文件都将被标记为“只读”。因此，您仍然可以通过点击“F5”来运行您的网站，它将重新加载它们当前所在的文件。如果您签出并正在编辑它，它将变为非只读，您可以更改它。
无论如何，您正在运行的 Web 服务器将加载具有相同效果的只读/可写文件。
以下是您在 CVS 或 Subversion 等非集中式源代码控制系统中使用的一般工作流程： 首先，您将当前项目导入所谓的存储库，即所有文件的版本化存储。注意只导入手动生成的文件（源文件、数据文件、makefile、项目文件）。生成的文件（目标文件、可执行文件、生成的文档）不应放入存储库。
然后你必须检查你的工作副本。顾名思义，您将在这里进行所有本地编辑、编译以及将测试服务器指向的位置。它基本上是你以前工作的地方的替代品。每个项目只需要执行一次这些步骤（当然，您可以检查多个工作副本。）
这是基本的工作周期：首先，您将存储库中所做的所有更改检出到本地工作副本中。在团队中工作时，这会带来其他团队成员自您上次签出以来所做的任何更改。然后你做你的工作。当您完成一组工作后，您应该再次检查当前版本并解决由于其他团队成员的更改而可能发生的冲突。（在纪律严明的团队中，这通常不是问题。）测试，当一切按预期工作时，您提交（签入）您的更改。然后您可以继续工作，一旦您再次完成，请签出、解决冲突并再次签入。请注意，您应该只提交经过测试和工作的更改。你多久入住是一个品味问题，但是一般规则说您应该在一天结束时至少提交一次更改。就个人而言，我提交更改的频率要高得多，基本上是每当我进行了一组通过所有测试的相关更改时。
您仍然拥有硬盘上的所有文件，为 F5 做好准备！
不同之处在于您可以将文件“检查点”到存储库中。你的日常生活完全不需要改变。
您可以对您当前工作的同一目录执行“签出”，这样就不必更改。基本上你的工作目录不需要改变。
这是一个非常开放的问题，因为您如何使用 SCM 在很大程度上取决于您选择的 SCM。像 git 这样的分布式 SCM 与像 Subversion 这样的集中式 SCM 的工作方式非常不同。
svn 对于“新用户”来说更容易消化，但 git 可以更强大一些并改善您的工作流程。Subversion 也有非常棒的文档和工具支持（比如 trac），还有一本你应该阅读的在线书籍：
它将涵盖源代码控制管理的基础知识，无论您最终选择哪种 SCM，都会以某种方式帮助您，因此我建议您略读前几章。
编辑：顺便说一下，让我指出为什么人们对你不满意：SCM 不仅仅是“代码的备份”。拥有“时间机器”与 SCM 完全不同。使用 SCM，您可以返回您的更改历史记录，查看您实际更改的内容，以及您在使用 blob 代码时永远无法获得的内容。我敢肯定你不止一次问过自己：“这段代码是怎么来的？” 或“我以为我修复了那个错误”——如果你这样做了，那就是你需要 SCM 的原因。
您没有“必须”以剧烈的方式改变您的工作流程。你可以，在某些情况下你应该这样做，但这不是版本控制规定的。
您只需像往常一样使用这些文件。只有在版本控制下，一旦您达到某种“完成”或至少“工作”状态（解决了问题跟踪器中的问题、完成了某种方法、调整了某些东西等），您就可以签入。
如果您有多个开发人员在处理您的代码库，请务必定期更新，以便您始终使用最新（合并）版本的代码。
我会推荐分布式版本控制系统（mercurial、git、bazaar、darcs）而不是集中式版本控制系统（cvs、svn）。它们更容易设置和使用。
试试 mercurial（这是我用来理解版本控制如何工作的 VCS），然后如果你愿意，你甚至可以迁移到 git。
Mercurial 的主页上有一个非常好的介绍性教程：Understanding Mercurial。这将向您介绍 VCS 的基本概念以及工作原理。这真的很棒。之后，我建议您继续阅读 Mercurial 教程：Mercurial 教程页面，它将教您如何实际使用 Mercurial。最后，你有一本免费的电子书，它是关于如何使用 Mercurial 的非常好的参考：Distributed Revision Control with Mercurial
如果您感觉更有冒险精神并想立即开始使用 Git，那么这本免费的电子书是一个很好的起点：Git Magic（非常容易阅读）
最后，无论您选择哪种 VCS 工具，您最终会做的事情如下：
差不多就是这样。
好问题。使用源代码控制，您仍然可以执行“F5”刷新过程。但是在每次编辑（或一些小的编辑）之后，您都需要检查您的代码，以便备份一份副本。
根据源代码控制系统，您不必每次都明确签出文件。只需编辑文件即可查看。我写了一个源代码控制的视觉指南，许多人在了解基础知识时发现它很有用。
这都是非常主观的，具体取决于您决定使用的源代码控制解决方案。您肯定会想要研究的一个是 Subversion。
您提到您正在做 PHP，但您是在 Linux 环境还是 Windows 中做呢？这并不是很重要，但我在 PHP 环境中工作时通常做的是拥有一个生产分支和一个开发分支。这允许我配置一个 cron 作业（Windows 中的计划任务），以便从生产服务器的生产就绪分支自动拉取，同时从我的开发服务器的开发分支拉取。
一旦你决定了一个工具，你真的应该花一些时间来学习它是如何工作的。例如，签入和签出的概念并不适用于所有源代码控制解决方案。无论哪种方式，我都强烈建议您选择一个允许分支的。 本文介绍了一个很好的（在我看来）在生产环境中遵循的源代码控制模型。
当然，我声明这一切多年来都没有“修补”过。我从事职业发展已经有一段时间了，我的技术可能对你这个职位的人来说太过分了。然而，并不是说这有什么问题。
如果您使用的是 Subversion，您只需检出一次文件。然后，每当您进行重大更改（或要去吃午饭或其他什么）时，您都将它们提交给服务器。这样，您可以通过按 F5 来保留旧的工作流程，但每次提交时，您都会在 SVN 存储库中保存所有文件当前状态的副本。
根据源代码控制系统，“结帐”可能意味着不同的东西。在 SVN 世界中，它只是意味着从存储库中检索（可能是更新，可能是新文件）最新副本。在源代码安全的世界中，这通常意味着更新现有文件并将其锁定。 下面的文字使用了 SVN 的含义：
使用 PHP，您要做的是将整个项目/站点签出到测试 apache 站点上的工作文件夹。您应该设置存储库，这样只需一次签出就可以发生这种情况，包括任何必要的子文件夹。您签出您的项目以设置一次。
现在您可以进行更改并按 F5 正常刷新。当您对支持特定修复或功能的一组更改感到满意时，您可以作为一个单元提交（当然，带有适当的评论）。这会将最新版本放入存储库中。
一次签出/提交一个文件会很麻烦。
取决于您使用的源代码控制系统。例如，对于 subversion 和 cvs，您的文件可以驻留在远程位置，但您总是在本地检查您自己的副本。此本地副本（通常称为working copy）只是文件系统上的常规文件，其中包含一些元数据，可让您将更改上传回服务器。
如果您使用的是 Subversion，这里有一个很好的教程。
听起来您在询问如何使用源代码管理来管理版本。
以下是一些并非特定于网站的一般指导：
如果你有一个小团队、一个稳定的产品、一个快速构建和高效、高质量的测试，那么整个过程可能是 100% 自动化的，并且可以在几分钟内完成。
源代码控制系统通常是您的文件及其历史记录的存储位置，并且通常与您当前正在处理的文件分开。这在一定程度上取决于版本控制系统的类型，但假设您使用的是类似 CVS 的东西（例如 subversion），那么您的所有文件都将存在于两个（或更多）位置。您在本地目录中有文件，即所谓的“工作副本”和存储库中的一个，它可以位于另一个本地文件夹或另一台机器上，通常通过网络访问。通常，在第一次将文件导入存储库后，您可以在继续处理它们的工作文件夹下检出它们。我假设这将是您的 PHP 文件现在所在的文件夹。
现在，当您签出副本并进行了一些要“保存”的重要更改时会发生什么？您只需将工作副本中的这些更改提交到版本控制系统。现在您有了更改的历史记录。如果您在任何时候希望返回到您提交这些更改的版本，那么您可以简单地将您的工作副本恢复到较旧的修订版（您一次提交的更改集的名称）。
请注意，这都是 CVS/SVN 特有的，因为 GIT 的工作方式会略有不同。我建议从 subversion 开始，并阅读非常优秀的SVN Book的前几章来帮助您入门。
我只想补充一点，我认为最容易设置和使用的系统是Mercurial。如果您单独工作而不是在团队中工作，您只需在正常工作文件夹中初始化它，然后从那里继续。正常流程是使用您喜欢的编辑器编辑任何文件，然后进行签入（提交）。我没有尝试过 GIT，但我认为它非常相似。单调有点难上手。这些都是分布式源代码控制系统。
我推荐Subversion。设置一个存储库并使用它实际上是相当简单的，即使从命令行也是如此。这是怎么回事：
$ which svn
/usr/bin/svn
这是一个工具，可以告诉您通往另一个工具的路径。如果它什么也没返回，则该工具未安装在您的系统上
$ apt-get install subversion
apt-get是一种将其他工具安装到您的系统上的工具
如果这不是 apt 中颠覆的正确名称，试试这个
$ apt-cache search subversion
或这个
$ apt-cache search svn
找到正确的包名并使用apt-get install packagename安装它
$ cd /path/to/directory/of/repositories
$ svnadmin create my_repository
svnadmin create reponame在当前工作目录 ( pwd )中创建一个名为reponame的新存储库
您已正式完成创建存储库
$ cd /repos/on/your/local/machine
$ svn co svn+ssh://www.myserver.com/path/to/directory/of/repositories/my_repository
svn co是用于签出存储库的命令
$ 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。
$ 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 的每个文件。
$ cd /repos/on/your/local/machine
$ svn status
这将告诉您是否有任何新文件、更新文件以及有冲突的文件（您的本地版本与服务器上的版本之间的差异）等。
$ cd /repos/on/your/local/machine
$ svn up
更新会从您还没有的服务器中提取任何新更改
svn up确实关心你所在的目录。如果你想更新整个存储库，请确保你在存储库的根目录中（主干上方）
这就是你开始真正需要知道的一切。有关更多信息，我建议您查看Subversion Book。