SVN主干带标签过时，合并的最有效方式？
使用SVN，我们通常的操作过程是开发人员创建一个开发分支，进行一些更改，测试它，标记它，然后将该标记推送到prod。然后“合并主机”将这些更改合并到主干中。问题是，关于谁是合并主控者，存在一些错误的沟通。所以现在我们在这些回购协议上有一个过时的主干，谁知道有多少标签没有合并到主干中SVN主干带标签过时，合并的最有效方式？,svn,Svn,使用SVN，我们通常的操作过程是开发人员创建一个开发分支，进行一些更改，测试它，标记它，然后将该标记推送到prod。然后“合并主机”将这些更改合并到主干中。问题是，关于谁是合并主控者，存在一些错误的沟通。所以现在我们在这些回购协议上有一个过时的主干，谁知道有多少标签没有合并到主干中 我们正在停止开发以解决这个问题，我想知道是否有人遇到过类似的问题并提出了一个有效的解决方案标记并不用于合并回来。简而言之，它们是用来作为书签的。你必须合并回“开发分支”，不要看标签，即使你以前是这样做的。我认为这个过
我们正在停止开发以解决这个问题，我想知道是否有人遇到过类似的问题并提出了一个有效的解决方案标记并不用于合并回来。简而言之，它们是用来作为书签的。你必须合并回“开发分支”，不要看标签，即使你以前是这样做的。我认为这个过程是这样的：
我建议大家阅读我相信你们的开发过程是错误的。应该发生的是，每个人都从主干中分支，以进行修复或添加一些新功能，然后该人合并回主干中。然后你总是在后备箱上贴标签。有了这个，每个人都是他们自己的合并主节点，你不会遇到任何过时主干的问题，因为人们不断地将他们的更改合并回主干中。同样，这样你的标签将始终拥有每个人的新特性，这些特性已经过测试，并准备好进入主基线
现在，对于您当前的问题，每个拥有分支的人都应该立即合并到主干中，然后您就可以在主干中找到每个人的“标记”的工作副本。如果这听起来像是一个尖刻的回答，很抱歉，但是：是的，我们遇到了相同的问题。我们停止为每个项目创建新标记。合并是一场噩梦。每次合并都会带来风险：如果您遇到合并冲突，必须有人来解决。但最糟糕的情况是，您没有得到合并冲突，结果代码编译成功。。。但这是不对的 在过去的几个月里，我们采取了一种完全不同的策略：尽可能地在主干上进行所有开发。我们通常在当前版本移交给测试组的同一时间开始编写下一个版本。所以当我们进行测试时，我们会剥离一个标有发布号的“发布分支”。任何bug修复都是对主干进行的，然后合并到发布分支中。这意味着bug修复将作为正在进行的开发的一部分进行测试。此外，我们也不可能忘记合并：如果我们这样做了，测试组会立即抱怨bug没有被修复。由于发布分支离主干只有几周的时间，所以很少有合并问题，当有合并问题时，做出更改的程序员很容易被识别和使用，因为他昨天刚刚做了更改
PS我是你为我们团队所说的“合并大师”。这听起来令人印象深刻：我可能会开始这样称呼自己 是的，在将分支合并到主干之前，应该从主干同步开发分支。也可以选择首先对其进行单元测试。这意味着您可以在分支而不是主干中捕获集成错误。
推送标签