我将在博客文章中回答这个问题，因为它偏离了主题GRIN。在http://wp.leau.co/2011/02/25/how-to-setup-your-wordpress-php-development-environment/第6章中我做了一些解释SVN在食，但你可能在找其他的东西。
我在这里讲的故事是关于你的评论
“因此，到目前为止，我将其与IDE（NetBeans，PHPStorm）中的VCS集成功能结合使用。这经常使我对特定的细节和正确的做事方式感到困惑。” 和“专注于概念和工作流的东西，而不是在控制台中键入奥术线。”
我听说，我经常想在更广泛的上下文中解释SVN，例如首先描述“编程语言”，然后解释PHP使您更好地理解PHP，在这种情况下，首先是配置管理，然后是其中的SVN解决方案。
我将在此处键入一些内容，如果它不在主题范围内或不需要，则将其删除：
------------ 8 <----------------
如果您安装Eclipse PDP，我已经写了：[ http://wp.leau.co/2011/02/25/how-to-setup-your-wordpress-php-development-environment/ ]
如果向下滚动至＃6，我将简要说明如何在Eclipse中安装collabnet subclipse（基本上只是指向服务器，然后选择全部并安装）
在带有任何版本管理工具的Eclipse中，用于版本管理的命令始终在rightmouse下单击“ TEAM”。由于可以在项目之间进行切换，因此可以支持多种版本管理工具，并且大多数命令通过GUI都是工具所熟悉的。
外挂程式
如您所知：对于一个新的WordPress插件项目，您可以从WordPress.org（在您的邮箱中）获得一个svn位置，它们将Trunk用于您的最新代码，并使用“标签”副本来稳定发行。（非常基本的CM模式）。乍一看就是这样。
因此，您的项目将链接到TRUNK。而且您可以简单地做到这一点。这是您工作的地方（但不是您发布的地方）（除非您在readme.txt中指定“ trunk”作为最终代码的位置）。
此外，您可以将WordPress / wp-includes和/ wp-admin作为库包含在Eclipse项目中，以便您可以查找功能并查看不赞成使用的功能。这些是不可写的，因此不属于版本管理（！）。这是从客户端而不是版本管理项目中实际链接的“外部”。
有了稳定的版本后，请选择内容，然后右键单击“团队”和“创建标签/分支”，这将打开WordPress svn位置，您可以选择标签目录并键入新的数字，然后您的新版本就会发布（这可能对阅读此书的人有用）。请注意，您不应选择项目的根目录，而应选择其他所有目录，否则它将在您的标签/2.3.4下创建该根目录，这不是您想要的，您希望该根目录下的所有内容都位于/ tag目录中。
有关一些屏幕截图，请参见发布。
http://wp.leau.co/files/2011/02/image_thumb17.png
WordPress本身贡献者
如果您是贡献者，则可以使用与上面相同的内容，但是您可以根据所做的更改创建“补丁”。“补丁”是CM世界中的一个概念，例如，颠覆提供了该补丁或爵士RTC。右键单击“应用补丁”，如果您有尚未应用于WordPress干线的补丁，则可以应用补丁。
某些人也直接致力于树干。
WordPress本身“读取”
再次通过team> checkout，创建一个项目“ WordPress”，该项目在主干中（Subversion代码的）包含一个/ LATEST版本的签出。
就我个人而言，我不这样做，而只是使用最新代码的导出（强制执行）以获取具有最新WordPress版本的目录（因此该目录不属于任何版本管理）
一般来说
由于您具有一些VCS经验和有关SVN的问题，因此：基本上，所有版本工具都是有关事物命名的概念的。或更好的说拥有最好的命名空间。您可以将CVS，Git，RTC，ClearCase，SourceSafe等中的大多数命令映射到此名称空间周围的概念。由于您对其他工具有一些/很少的经验，因此要多一点：
新人们常常对某些命令或某些特定功能视而不见，但提供最佳选择以将所需的所有元素放置在名称空间中是核心。
因此，由于这基本上是这些工具的核心功能，因此术语“版本管理”是错误的。它实际上是一个名称空间管理器。
所以如果你有
/项目A /部门B /团队C /成员D /流E /组件F /元素G /分支H /分支I /版本J
您可以为每个“事物”创建一个唯一的名称。上面是使用一种名称空间工具为特定目的所需的名称空间的实现。
这个世界上几乎所有概念都可以映射到这个概念，因此您支持自定义名称空间/分类法的方式取决于工具的功能。因此……这实际上取决于数百种不同工具的设计者所做出的概念和选择。
在一个好的工具中，您可以单击并在一棵树中看到完整的分类法，或者放大一棵树。
这就是核心：一个可以帮助您管理自定义分类法的好工具，可以帮助您管理复杂性（请参阅Wikipedia中的复杂性：http : //en.wikipedia.org/wiki/Complexity）。创建分类法并思考如何进行设置的人是配置经理，他写了一个计划，即首先考虑到这一点的配置管理计划。
试想一下，有人要求您在WordPress中创建一组自定义分类法，以表示他公司中的所有对象，包括能够随时获取状态信息。您可以做出很多设计选择，每个人都将根据某些选择产生其他东西。有些将包含更多功能，某些将更简单，而更复杂的将做出不同的决策。这就是“这些工具”。因此，我从不理解有关版本管理的工具级别的讨论，因为那完全是奇怪的。
如今，在PHP中，您可以创建名称空间，使用目录创建层次结构，将命名约定应用于对象以及其中的方法。如果要处理放置在层次结构中的一个文件，请更进一步。您在其后添加一个/并在其后放置一个版本号。这甚至还不够，因为您希望团队A使用文件的版本4，而团队B使用该版本。因此，您添加另一个/并添加分支ID。这是构建命名空间的方式。根据工具的不同，您可能会发疯。
但这意味着：如果有人问您“文件Z在哪里”，您将无法给出答案。因为在版本管理系统中不存在“文档Z”。即使他说给我“文档Z版本5”，您也无法移交给他，因为他可能表示团队1分支的“文档Z版本5”或团队2分支的“文档Z版本5”。这都是关于命名的。“文档Z版本5”在定义的名称空间中只是一种不正确的命名方法。
在Subversion中，您只能进行此限制，因此易于理解。一些概念与此相匹配：
“版”
版本是对某个元素的修订。因此，例如wp-config.php版本5。在类似ClearCase的工具中，您还可以查看元素的各个版本并“提交”单个文件（但也可以执行原子提交或更改集或其他操作）。
在Subversion中，处理版本受到更多限制：
- 您可以一次性在本地进行一组更改，即“ commit ”，这意味着将完全提交完整的一组“更改”，并且整个基础都将获得一个新的版本号。这是您在WordPress颠覆网站中看到的版本号。
- 因此，您无法在本地对1个文件进行更多更改，并且将所有这些更改均视为单个新版本，如clearcase一样。您在本地对该1个文件或任何其他文件所做的所有更改都会一口气提交，并获得“唯一的新名称”。
- 如果您无权访问存储库（权限），则可以进行一组更改并将其保存在“补丁”中。然后，您可以将该补丁发送给某人，例如将其应用到存储库的集成管理器，甚至是构建管理器。诸如RTC之类的工具也支持“补丁”。因此，一个人创建了一个补丁，而另一个人则应用了该补丁。您应该真正将其视为“单词补丁”一词，而不是默认的代码开发用例。
- 除了/ branch N / hello.doc / version 25外，还有/ branch N / hello.doc / LATEST或/ HEAD之类的标签。在某些版本管理系统中，您可以应用复杂的标签，然后编写在这些标签上工作的脚本。
在版本上工作
在Subversion中，默认用例是您只需从存储库签出中将所有内容下载到硬盘上，对这些内容进行处理，然后提交，然后面对其他人所做的所有更改，在解决冲突之后。您在GUI中看到的这些概念。如果您想防止其他人也编辑您的hello.doc文件，那么您将其锁定意味着：没有其他人可以更改它。
我真的不喜欢这个主意:(恕我直言，这是非常不好的做法。为了进行比较和理解：在ClearCase中，签出或多或少可与锁媲美，而签入是提交（在Subversion中，签入是提交的别名）这是ClearCase中的默认用例，它还支持劫持，它与Subversion 签出相同，但随后在选定的文件上。恕我直言，这更加干净。此外，即使在ClearCase中进行签出，它也提供3个选项：other人们可能不使用它（例如使用word docs），如果确实需要，其他人可以使用它，而“每个人都可以使用它”（例如使用源代码文件）所以...这就是签出，锁定和提交的含义在SVN中。
组件和基准
在RTC和ClearCase之类的工具中，您可以将元素分组为组件。功能强大，因为这些组件是名称空间的一部分，并且可以通过对它们进行基线设置来获取其自身的版本。因此，例如组件“ WordPress”的基准版本为4.53。这些基线本身就是对象，然后它们也可以获取元数据，例如“测试中”。但是SVN没有ANY。所以...
标签
在SVN（以及WordPress网站等）中，您会在称为“标签”的整体目录中看到带有数字的目录。解决方法。您只需获取某个存储库并将其（基于文件）转储到目录标签/3.2.4中即可。而已。它与版本管理名称空间等没有任何关系...只是一个简单的目录.... SIGH .....恕我直言，无法使用这种工具进行任何配置管理。因此，它不是元数据对象，您可以在其中编写脚本并分配属性，也可以执行最疯狂的事情……它只是一个目录..........在RTC中，您可以将“某个基准的快照”以支持该用例。在ClearCase UCM中，您将创建一个特定基线的新分支/流，然后“查看”。
分行
据我所知，这在WordPress环境中并未使用，但也许我是错的，并且有一些团队为此目的在WordPress版本中将端口更改支持到较早版本。所以我不知道也许别人认识。
这用于名称空间树。要让两个团队使用相同的代码，您可以说“英语” \ team 1 \ hello.doc和\ team 2 \ hello.doc。然后，两个团队都开始工作，过一会儿您有\ team 1 \ hello.doc \ version 51和\ team 2 \ hello.doc \ version 23（因此，第1团队制作了51个版本，第2团队制作了23个版本）。现在您可以从分支团队1合并到分支团队2，并且可以在团队2中合并，但是到最后，团队2将拥有团队1的所有更改（版本24），并且各个分支仍然显示每个团队的工作其中。
在RTC和ClearCase中，不使用此对象，而使用更高级的对象“ streams”（用于比较）。从低角度看，您可以将它们视为相同的按钮……。在现实生活中，您的分支机构将包含很多东西。因此，在现实世界中，您将必须做笔记，发行说明，文档等。为增强此功能，流不仅包含“代码”，还包含“更改”，因此您知道RFC23是关于34,32版本的和56，您可以分别释放它们。
恕我直言，如果您想正确设置事情，那么您可以为每个人提供一个或多个个人信息流/分支。这样他们就可以从那里签入/提交和签出，而且没有人打扰。只有当某个人准备好了之后，他们才将他们的东西“交付”到团队流中，而团队流则交付到集成流中，等等……在WP中，发行版可能是分支机构，但对于普通人：他们都在同一分支机构中工作。这是一个缺点，因为“测试项目”位于c：\ temp中，而不是在版本管理下，并且不能有一群人临时从事功能X的工作，而这些功能X仅需要5个发行时间。
理想世界与权衡
如果您有\ team1 \ hello.doc，并且有人在\ team2 \中也复制了hello.doc，则这是BAaaaaad。从现在开始，我们有2个具有不同ID的元素，用户认为它们是相同的，但是系统将它们视为不相同。这被称为“邪恶的双胞胎”，您永远不要在这样的环境中这样做。始终合并或分支的基础。如果您了解邪恶的双胞胎，那么您就会了解分支（这很不好：因为在合并时，它们将被视为2个不同的实体，而您希望它们被视为相同）（或在不同系统中具有不同的行为）。如果新用户搞砸了，就只能解决了。“我刚刚删除了hello.doc，然后将其复制回了” argh
变化
SVN不为此提供支持，但可以将其与一些工具集成以支持某种集成的变更管理/ ALM。在像ClearCase- UCM变体或RTC这样的工具中，如果没有缺陷，RFC，票证等，则不能更改1个字母。在SVN中，当您提交时您可以为您的原子提交键入描述。含义：换句话说，您应该尝试以“可修补”的方式进行更改：对每个缺陷/更改进行原子提交，以使其具有某些行为。（但是当然，后来它并没有在诸如ClearCase数据库之类的命名树中将所有链接链接在一起）（以便您可以自动化发行说明，或帮助作为部署管理者的可怜人获取大量新代码集，更改，发行版并进行尝试。将其混合在一起，而没有真正的工具可以让他对实际情况有任何见解）。
由于SVN不支持变更管理，因此WordPress设置为使用TRAC： 您所知道的http://core.trac.wordpress.org/因为您居住在这里:)
我觉得TRAC是存在的，因为缺少像ClearCase或RTC这样的真实工具，该工具具有随对象（是您针对其编程的对象）集成的更改。因此，您有一个工具来讨论和提交设置为“某种”变更的工具（同时也缺少该概念）。因此，这些都是“补丁”，只是一堆文件，没有在良好系统中会期望的任何元数据（因此，我现在处于脾气暴躁的状态）。TRAC的数量很重要，因为这是链接到某些更改的命名树中的总体ID。
交付变化
这是在另一篇博客文章中写的。简而言之：在理想的世界中，您将希望选择要“交付”（或另一个概念）的更改，然后不必担心文件，目录（版本）。您只需“提供RFC 3和5”。这就是ClearCase UCM或RTC的工作方式。在SVN /基本clearcase中，您“提交”一堆文件，我们希望您做出正确的决定。这是一个很大的差异，也是一个重要的差异。（这就是为什么SVN通常与jira / clearquest /等集成在一起使用以实现此行为的原因）。修补....没有将它作为一种“修补程序”从一个流传输到另一个流。
外在
在其他工具中，您在SVN中的操作与此不同，这更简单：如果您的代码来自非您自己的部分，则可以将其视为受外部版本管理，并…回到核心概念：您的意思是部分不属于您的命名空间责任，因为这全都与命名有关。但是，即使它是外部的，也应由您负责。
在GUI中，常规的“右键”中没有工作流，但是它是在项目结构中定义的。因此，这是您定义的一部分。
如果使用此概念，则在定义时需要在IEEE CMP中定义（请参阅下文）
整合与合并
如前所述。SVN背后的范式是在本地获取内容，完成工作然后提交并拥有***。在GUI中，您确实可以获得与大多数其他工具完全相同的工具。在这里，您应该真正了解三路合并，两路合并以及可以自动解决的冲突和无法自动解决的冲突之间的区别。然后，最后一类分为2类：工具可以向您提出好的最终结果的类别，以及不知道最终结果的类别。您询问了有关GUI的信息，但在命令行上获得了有关提交之前应修复/合并的信息的信息文件。
有关博客文章的更多内容。（例如，开放源代码开发与企业开发，并建立领导者和集成经理，因为您实际上必须在此处做出不同的选择）。
最后但并非最不重要
您需要的是WordPress的配置管理计划。这是一个IEEE文档。含义：无论您在Google上找到数以百万计的配置管理计划，它们都针对CMP的IEEE指定（几种版本）有效。
就像（例如HTTP）RFC一样，IEEE CMP也是如此。
该计划包含已定义的部分，例如“如何对待外部对象”和“名称空间的外观，我们如何检索项目以及如何复制项目”，角色，职责等。
然后，您可以从此CMP创建工作说明。任何想知道规则是什么的人都可以阅读CMP。
在开源环境中，通常缺少角色“配置管理器”。因此，您也错过了配置管理计划。
与公共RFC（例如URI或HTTP）不同，您必须支付IEEE标准文档的费用，但是...如果您使用Google，则可以在此找到它。
送货街
在交付街道上，您将有一个团队思考新的业务构想。您有一个维护部门，在他们的系统中收到大量的生产错误。您将有多个团队使用相同的代码。在每个子街道中，您将拥有一个定义需求的需求团队。架构团队分为职能团队和运营团队（用例属于职能团队，非职能属于运营团队）。您经常会在单元测试环境，验收环境，负载和压力测试环境，功能测试环境，预生产测试环境和生产环境中并行运行不同的发行版。
所有这些都是相互跟踪的版本。
特定测试环境上的一个版本链接到一组链接到特定RFC的版本，而该版本链接到需求的特定版本。然后将需求链接到测试集的特定版本。全部归版本管理。
在带有SVN / TRAC的WP中，我尚未找到需求数据库和需求的版本数据库。（这样您就可以进行影响分析，并查看更改1个需求后代码会更改）（并且在新版本中，您可以打印出哪些需求已更改）。我在注释中看到了TRAC中的单个项目，并链接到TRAC中的其他单个项目。除了注释之外，我还没有看到TRAC项目与代码之间的可追溯性。因此，这意味着人们在做很多事情，并且非常依赖活跃的社区或核心开发人员，因为他们的大脑很多。
但这远非话题可笑
适用于ALM的OSLC
关于这个故事，请再说一遍：如果所有这些应用程序生命周期管理工具（ALM）都只有一套标准，那不是很好吗？有人想到了这一点，现在有了标准，以便将所有概念置于更高的抽象级别，然后在工具中实现。Google：适用于ALM的OSLC。（以便所有工具都可以相互交流并为用户交流：您通过了解抽象层来了解所有工具）。
平静
如果有时间的话，甚至可以更进一步：世界正在走向C / ALM，这是下一代产品，其中流程和工具是一个集成的东西，因此您不必再怀疑流程是什么了。这一代的第一款产品是RTC。因此，如果您很好地理解SVN或了解ClearCase或Jira或Trac或ANT或Agile或RUP或iRUP或其他任何流程，版本管理，变更管理，构建管理的东西，那么您将需要所有这些来理解RTC，因为所有这些都是结合在一起的一方面是因为它们都捆绑在一起，而这本身就是通过OSLC进行连接的，所以任何这些较旧的工具都可以“插入”。
但是现在我真的没话题了。