Questions tagged «branching»

我们正在将我们的项目团队从使用单个Main / Trunk分支转移到应定期合并到Main中的多个Development / Work分支。我们将基于本文和《TFS分支指南》（我们正在使用TFS和Visual Studio 2010）建立新流程。 目前，任何时候都有1至5个人从事该项目。Main必须始终保持稳定，因为我们希望该选项可以在需要时释放。我们没有固定的冲刺-至少现在还没有-现在每1-2周发布一次。 现在，每个人都在修复整个应用程序中的错误。在几周内，我们将开始为该应用程序开发新的大型组件。 我们发现的一个症结是何时应该创建开发分支。我们将根据开发人员的技能水平并行实施多个用户故事。我们已经考虑过为每个开发人员创建一个分支，但这没有任何意义，因为在一件作品上总会需要一些协作。我们不能只靠一个开发分支，因为我们想在其他工作完成时合并到Main。 有人对此有指导吗？

11 development-process  team-foundation-server  branching 

对项目中的每个开发人员都有一个远程分支是否被视为一种好习惯？ 我们将Git与以下分支一起使用： 主 释放 发展 如果每个开发人员都有自己的分支，则可以将代码推送到自己的分支中，而其他开发人员可以将这些更改合并到自己的分支中。

11 version-control  git  branching 

我的工作团队正在使用Subversion作为我们的VCS来启动一个新项目（出于这个问题的考虑，您可以将其视为一成不变的）。我们仍处于该项目的早期阶段，并试图就分支模型达成共识。我们之前的项目基于非标准版本模型，该模型导致管理现有版本的修补程序和修补程序时出现问题。 我发现不同的分支模型相当复杂，但是我确实很清楚地理解的一种模型是git flow。我很好奇在Subversion中实现这种变化会有多么困难/不期望。显然，在分支机构上进行协作的人会有所不同。功能分支必须集中而不是局限于本地存储库，但是据我所知，该模型的其他概念应该可以在Subversion中重现。 这种方法的缺点或挑战是什么？我听说相对于Git，在SVN中“合并成本很高”。但是我尚不清楚这在实践中意味着什么，或者它将如何影响我们使用像分支模型这样的git flow的能力。 这种方法最大的担忧是什么。有没有一种类似的清晰方法在Subversion中更自然？

10 svn  branching  gitflow 

我对正确的分支命名存在分歧（当然是顺服）。这适用于错误修复和小型功能分支，不适用于长时间运行的功能分支。对于长期运行的功能分支，我们同意人类可读的名称更好。这是两种观点： 矿： 根据团队和票号命名分支更好。这样可以更轻松地在我们的票务系统中找到它们，并且打字更短。当查找有关票证的历史信息时，这也使查找GIT中的相关分支变得更加容易。 例： team-name/12345 team-name/53719 他的： 根据分支的特征/功能命名。与单个数字相比，它更容易自动完成，并且更容易记住。 例： team-name/fix-that-sql-bug team-name/expand-http-parser 我提供的一个折衷方案是： team-name/12345-fix-that-sql-bug 但是他不喜欢这样，因为它与GIT自动完成功能混为一谈。 如果这主要是基于意见的，请随时为我提供指导，以指导如何使其更适合SO-但我认为可以修改/补充我给出的理由以给出经验答案。

10 git  naming  github  workflows  branching 

我正在寻找有关角色和职责的“最佳实践”，特别是谁负责从开发分支到主干（或主干）的合并。基本上，我正在寻找弹药来帮助我的事业。 让我描述一下我所面对的。我是特定应用程序的首席开发人员（所有者）。我们公司最近从VSS（我是存储我的应用程序的VSS数据库的管理员）转移到TFS（在这里我仅对“运营”团队创建的开发分支拥有权限）。在以前的工作中，我是TFS管理员，所以我了解TFS和MSBuild的使用方法。 我对使用的分支和合并策略没有任何问题（主分支，根据需要创建了错误/项目开发分支，然后合并回main，然后提升为发布分支）。我遇到的问题是： 我无法创建自己的分支。我必须创建一个TFS任务，以使“操作”团队成员为我创建分支。 我无法从Main合并到开发分支。我必须创建一个TFS任务，以使一个“操作”团队成员执行合并，然后希望他不要“踩”我的任何团队变更，因为“运维人员”可能是开发人员，也可能不是开发人员几乎不了解他正在合并的代码。 我不能从开发合并到Main。同样，我必须创建一个TFS任务，以使“操作员”执行合并，希望他能正确执行。然后，我必须创建另一个TFS任务以合并回到我的分支，以便我可以解决由于非开发人员合并到Main而发生的任何问题。 我无法创建或编辑MSBuild脚本。再次，我必须与MSBuild的“ ops”团队合作，以便只能执行最基本的构建任务。（忘记任何复杂的事情，或者天堂般的自定义任务）。 我无法执行MSBuild脚本。同样，只有“ ops”团队可以做到这一点。 最重要的是，通常是一个“离岸”资源来执行所请求的任务，因此，即使我在清晨创建任务（分支/合并/构建），它也可能不会完成直到那天晚上。 现在，“操作”团队维护发布分支没有问题。他们所做的（基本上）是从Main那里获取最新版本并将其升级到release分支；因此只要“ Main”稳定且准备就绪，发布分支就可以了。 我的意见是，技术主管（例如I）应负责维护主干（“主”）以及与开发分支之间的任何合并。团队负责人还应具有生成MS Build脚本以构建和部署到Integration测试环境的能力。 任何人都可以将我定向到可以帮助我证明自己情况的最佳做法文档吗？我所有的搜索只发现了有关分支和合并技术的最佳实践，没有提到WHO应该执行上述分支/合并。

10 version-control  team-foundation-server  branching 

如果我们仅在Subversion中使用一个分支，我们是否还要打扰？我们不能只在行李箱上工作以加快速度吗？ 这就是我们使用Subversion开发的方式： 有一个行李箱 我们建立了一个新的发展分支 我们在该分支上开发了一项新功能 完成功能后，将其合并到主干中，删除分支，并从主干中创建新的开发分支 当我们要发布到生产环境时，我们会在行李箱中制作一个标签。错误修正是在该标签的分支上进行的。然后，此错误修正将合并到主干中。 这就是为什么在功能完成后我们创建了一个新的开发分支的原因。这样，错误修正会尽快包含在我们的新代码中。 下图应阐明： 现在，感觉这不是最有效的工作方式。我们在提交之前在本地进行构建，这大约需要5-10分钟。您可以理解，等待时间很长。 开发分支的想法是主干始终可以发布。但这在我们的情况下已不再是真的。有时，一项功能几乎已经准备就绪，并且一些开发人员已经开始编写下一个功能（否则，他们将围坐在一个或两个开发人员完成并合并的位置）。 然后，功能部件1完成后，将其合并到主干中，但包含功能部件2的某些提交。 那么，由于我们只有一个分支，我们是否应该还要烦扰开发分支？我一直在阅读有关基于主干的开发和逐个分支的信息，但是我发现大多数文章都集中在逐个分支的部分。我的印象是，重大变化将涉及多个版本。这不是我们遇到的问题。 你怎么看？我们可以在行李箱上工作吗？最坏的情况是（我认为），我们将不得不在主干中做一个标签，并挑选需要的提交，因为某些提交/功能尚未准备好投入生产。

10 svn  branching  tagging 

具体来说，我正在开发一个将DVCS和构建系统集成在一起的工具，但是我想像一下，如果开发任何“元”工具（编译器，VCS，构建系统，测试运行器等）的人都将面临挑战。希望通过“狗食”发展。 我的问题是：在使用分支工作流的Scrum风格发布过程中，从什么时候开始在工具的开发周期中使用该工具的较新版本？ 我正在寻找一种在以下两者之间建立平衡的过程： 不断使用该develop工具的版本：随着变更的合并，我正在打破自己的开发。 不断使用该master工具的版本：我通过狗食发现的所有问题都是已经发布的问题。

9 scrum  tools  workflows  branching  dogfooding 

我们提供三套测试套件： 一个“小型”套件，只需几个小时即可运行 耗时数小时的“中型”套件，通常每晚（每晚） 一个“大型”套件需要一周以上的时间才能运行 我们也有很多较短的测试套件，但在这里我不关注它们。 当前的方法是在每次提交到干线之前运行小型套件。然后，中型套件每天晚上运行，如果早晨发现它失败了，我们将尝试找出应归咎于昨天提交中的哪个，回滚该提交，然后重试测试。对于大型套房，只执行每周一次而不是每晚一次的类似过程。 不幸的是，中型套件确实经常失败。这意味着后备箱通常是不稳定的，当您要进行修改和测试时，这非常烦人。这很烦人，因为当我从后备箱中退房时，我无法确定它是否稳定，并且如果测试失败，我也无法确定它是否是我的错。 我的问题是，是否存在一些已知的方法来处理此类情况，以使行李箱始终处于最佳状态？例如：“提交到一个特殊的预提交分支，该分支将在每夜经过时定期更新中继”。 它是像SVN这样的集中式源代码控制系统还是像git这样的分布式源代码控制系统有关系吗？ 顺便说一下，我是一名初级开发人员，但更改功能的能力有限，我只是想了解是否有办法解决我遇到的这种痛苦。

9 testing  version-control  development-methodologies  branching 

我最近正在与一位同事讨论dvc，因为我们的办公室开始考虑从TFS切换（我们是一家MS商店）。在此过程中，我感到非常困惑，因为他说尽管他使用Mercurial，但他没有听说过“分支”或“结帐”命令，这些术语对他来说并不陌生。在想知道他可能不了解它们并解释了dvcs分支如何在您的本地文件上“就地”工作之后，他感到非常困惑。 他解释说，类似于TFS的工作原理，当他想创建一个“分支”时，可以通过克隆来完成，因此他拥有回购协议的完整副本。这对我来说确实很奇怪，但是我必须承认的好处是，由于文件是分开的，因此您可以同时查看或处理两个分支。 在搜索此站点以查看是否有人问过这个问题之前，我看到有评论说许多在线资源都在推广这种“从分支到分支”的方法，这使发布者感到沮丧。这实际上在dvcs社区中很常见吗？这样做的利弊是什么？我永远都不会这样做，因为我不需要一次看到多个分支，切换速度很快，而且我不需要所有克隆都填满我的磁盘。

9 workflows  dvcs  branching