Subversion——trunk真的是主开发的最佳位置吗?

您的主干应该始终编译,如果您需要进行中断更改,您应该使用一个分支,稍后再合并更改。

http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html

这真的取决于你的环境。在某些情况下,让后备箱暂时坏掉不是什么大事。但如果你和2-3个人一起工作,那可能不是个好主意。

在这种情况下,我认为可以更自由地使用分支 好主意。它们很容易设置和重新合并(如果你不让事情变得太不同步的话)。

当然,如果您的所有开发人员都使用同一个分支,那么您实际上不会得到任何好处—您只需要调用/branch/dev您的主干,但是让它断开仍然是一个主要问题!把分支分解,这样每个分支上只有几个开发人员在工作,你应该做得很好。

我建议你读这个 article 关于供应链管理最佳实践。

摘自文章:

永远。干线为几乎所有的变化提供了最终目的地-两者 维护修复和新特性-并表示 软件产品。发布代码行和开发代码行从

编辑:我也推荐阅读 SCM Patterns

主干是进行中的开发应该发生的地方。如果每个人在提交更改之前都在测试更改,那么您真的不应该对“损坏”代码有任何问题。一个很好的经验法则是在对更改进行编码后进行更新(从repo中获取所有最新代码)。然后构建并进行一些单元测试。如果一切都建立和工作,你应该很好地签入它。

当你准备释放时,做一个分支。测试可以对分支进行发布验证。如果发现问题,则对分支和主干进行修复,并给出分支的新切口进行测试。与此同时,开发人员正忙着为主干添加新的更改。

所以。。。通过测试发现的问题和这些琐碎问题的出色解决方案目前在分支和主干中都很流行,测试人员有一个稳定的工作切入点,并且在测试验证当前版本的情况下,开发工作继续向前推进。

就像汉尼拔在《甲级球队》中经常说的,“我喜欢当一个计划出现在一起的时候。”

使用Subversion的团队通常对合并有病态的厌恶,因为在1.5之前,合并是一个长期复杂的过程,容易失败。如果您有足够的开发人员,因此拥有一个始终工作的主干是绝对必要的,因为许多人正在处理许多不同的模块一起工作,branchy开发肯定会有帮助。

我创建了两个shell脚本来简化创建短期开发分支:

# Create new branch and switch to it
function svn_bswitch()
{
   branch=$1; shift
   msg="$1"; shift

   URL=$(svn info . | sed -ne 's@URL: \(.*\)@\1@p')
   REPO=$(svn info . | sed -ne 's@Repository Root: \(.*\)@\1@p')
   BRANCH_URL=$REPO/branch/$branch

   svn copy $URL $BRANCH_URL -m "$msg"
}


# Switch to a branch or tag
function svn_switch()
{
  d=$1; shift
  REPO=$(svn info . | sed -ne 's@Repository Root: \(.*\)@\1@p')
  URL=$REPO/$d
  svn switch $URL
}

在我们公司里,我们每晚都有一个行李箱。希望每个人都测试自己的代码,以便在签入之前至少编译它。如果夜间生成失败,则会删除有问题的代码,直到修复为止。

我认为最重要的部分是让每个人都理解subversion的作用,以及为什么他们只签入编译的代码是很重要的。

另一个很好的老“stable trunk,dev in branch”流程成为问题的例子:

您正在开发一个web应用程序,它依赖于大量实时的、可能是用户贡献的数据。因为某些原因你可以 不 只需生成您所依赖的数据库后端或外部文件系统的另一个实例。(例如,您的环境可能缺少数据模型迁移)

第一件事 B组需要做的是重构一堆数据库表和/或如何在外部文件系统上布局文件。这使得团队A在继续开发之前必须重构他们的许多新东西。然后C队来做另一件事。。。突然每个人都有问题了。

然后是合并阶段——之后就再也没有人想用陆龟了。

不,trunk不是提交开发级代码的最佳位置。在我们的环境中,我们将我们的主干视为部署到生产中的任何内容的镜像。web开发和应用程序开发的工作流可能不同,但主干应该包含最新的生产更改。

我们在开发分支(即分支/功能1)上工作,通过复制分支/功能1-->标记/功能1-qa1来创建qa标记,并修复分支/功能1中的任何错误以创建标记/功能1-qa1等。当准备好部署时,自上次合并到trunk以来在branches/feature1中发生的所有更改都会在创建最终版本标记(即tags/5.1.0)之前合并回trunk。

工作流程可能会有所不同,这取决于您的团队是如何建立的,或者您所处的项目/环境的类型。

不,后备箱不是最好的地方。 在我们的组织中,我们始终遵循以下方法: Trunk包含发布代码,所以它总是编译的。 随着每个版本/里程碑的更新,我们将打开一个新的分支。 每当开发人员拥有一个项时,他/她会创建一个新的分支到此发布分支,并在测试之后将其合并到发布分支中。 系统测试后,释放分支合并到主干中。