当我们最初设置版本控制时，我们的时间非常有限，只有基本知识如何设置。我们不理解分支，中继或标签。我们一直在处理的是Checkout，Update和Commit（哦，偶尔还有冲突）。我是否设置了subversion Repository错误？
但是现在，我们已经得到的地方，我们认为，我们需要更好地了解它，并可能重新思考的方式我们的资料库是设置和工作过的一个阶段。
目前，我们有我们的服务器上的4名不同的文件夹，每个包含结帐。这4个区域具有用于生产的源代码。这些结账中的2个直接作为缺陷修复结账区域进行工作。其他2个用作开发结账。团队成员可以在更长时间的工作中工作的地方。一旦他们完成了开发任务，他们将其提交到存储库，并因此将其更新到所有其他签出的生产代码。
但是，当阅读关于分支时，它听起来像在这里有一个失踪的水平。一根树干，我认为它是它所称的。
有人可以给这个newb一点快速崩溃corse如何正确的方法是为团队或开发人员设置一个存储库，他们需要一种方法来执行生产代码的快速错误修复，但也运行一对夫妇发展？
尽量先阅读一些文章。然后回来更具体的问题。我认为这是很好的文章：http://nvie.com/posts/a-successful-git-branching-model/
简而言之，您将源代码作为一批补丁管理。您作为提交进行的每个更改都是一组修补程序。然后你可以将这些补丁组合成特定的产品版本。此外，VCS允许保留所有历史记录，并为您提供每个已发布版本的可重复性。
这说明资源与图形可视化分支可能对您有用：http://nvie.com/posts/a-successful-git-branching-model/
想想这样：你想要一个'trunk'，它是你所有产品代码的主版本。但是你不想一直对它进行修改 - 总有一天你会想要获得最新版本的产品，而且，恐怖的是，开发人员通过做出的改变不是中途还有工作。最重要的是，假设你发现最新版本有问题，你需要获取最后一个版本（你知道的一个版本）。
那么，分支机构就是这里的答案。在Subversion中有两种不同类型的分支，称为分支和标签。他们真的是一样的东西，但人们称他们为不同的名称来区分你使用它们的用途。
与以前一样，您拥有自己的主干，但是现在，当开发人员想要进行更改时，首先将主干复制到新分支中。开发人员可以安全地在该分支上工作。一旦他完成，您将更改复制回主干。 Svn（以及所有其他人）都有工具来帮助将变化重新合并到主干上。
当您想要保留“完成”版本时，您可以做同样的事情 - 将其复制到具有唯一名称的标签分支上（例如版本1）。不同的是，你永远不会改变这个分支。它是固定的，不变的，并为您提供了识别构成该版本的代码（仅代码）的方法。
就是这样。你可以有多个分支进行开发，你可以从一个标签发布分支来进行错误修正，或者你总是可以从分支中分支来创建错误修正 - 你如何做到这一点取决于你想如何工作。