问题标签 [branch]

我相当习惯于使用 svn 进行分支和合并，通常这工作正常。然而，一个组件在两个分支中工作，并且基本上将组件带到不同的方向，因此自动合并将不起作用，并且使用超越比较显示文件大部分不同。

我试图将一些文件拼接在一起，但结果，即使它们有效，也是相当可怕的。

我很想对企业说，这是无法做到的。我可以看到这让他们感到沮丧，因为他们有模块 + 功能 A 和模块 + 功能 B 工作，但模块 + 功能 A + 功能 B 就目前而言没有意义。例如，功能 A 可能会删除功能 B 中的关键组件。

有没有办法尝试合并这样的代码？或者模块+A+B真的是模块+C吗？

我们确实看到了这一点，但与功能 B 相比，功能 A 需要的时间范围更短，而功能 B 是长期运行项目的一部分。有没有办法避免这种情况发生？或者他们是如何构建代码以使两个功能很好地结合在一起的？

当您想要进行持续集成时，最好使用的分支策略是什么？

1. 发布分支：在主干上开发，为每个发布保留一个分支。
2. 功能分支：在单独的分支中开发每个功能，仅在稳定后合并。

将这两种策略一起使用是否有意义？例如，您为每个版本分支，但您也为大型功能分支？这些策略之一是否更适合持续集成？当使用不稳定的主干时，使用持续集成是否有意义？

我刚刚继承了一个使用 Git 维护的项目。有一次，代码被部署到 3 个独立的系统上，每个系统都维护着自己的分散式 Git 存储库。

3 个系统中的每一个都在 3 个不同的方向上扩展了原始基础系统。三个系统都没有相互同步。一些更改在主分支上，其他更改在新分支上。

我怎样才能将 3 个不同的来源放在一起，以便我可以：

1. 找到一个共同的工作基础；
2. 找出哪些更改是应该应用于所有 3 个系统的错误修复；和
3. 以一种健全的方式维护 3 个系统，以便只有一个公共分支并分离出 3 个不同系统所需的定制？

我希望这是有道理的，如果这已经被覆盖过，我深表歉意。

情况：我们定期发布到生产环境。至少每两周发布一次，但通常一周最多可以发布三个版本。我们有一个由 3xSE、2xWD、3xQA 和技术经理/主管（我）组成的专注团队。团队会根据需求波动，但我们通常会发现 QA 的规模会在接近尾声时急剧增加，以应对延迟的需求/资产或大型回归测试阶段。6 个通常针对发布日期的标准功能分支和一个兼作发布分支的主干。有合并和分支开销，但我们已经非常擅长将其归结为美术。因此，只要从某个功能分支合并到主干，我们就会定期从主干合并到功能分支来维护分支。

问题：我想看看改进这个过程的方法，我们已经研究了在主干存储库中完成所有工作的选项，分支到 QA 存储库，然后进入发布分支。如果需要从主干中使用功能分支，我们仍然可以使用，尽管这可能会令人不悦。我的观点是，要将网站的两个主要元素（内容和功能）结合在一起，我们需要让事情依赖于时间。即提供一种将时间依赖于内容的机制（我不确定您是否可以使用该功能）。这个过程的成本会相对较高，如果它不起作用，我们会很快发现，因为我们无法足够快地响应客户。

有没有人有任何建议或以前遇到过类似的情况？

谢谢

我有一个带有（目前）三个分支的 git 存储库：

• head是稳定版本（不要与 git 混淆HEAD）
• experimental是实验代码；它应该编译
• norman是我的沙盒；其中的代码可能已损坏

“master” git repo 位于已备份的文件服务器上。但我在本地磁盘、家里的机器和笔记本电脑上都有副本。（我准备随时随地编写代码）。

git branch -a显示：

Tufts 分支是“主”存储库上的远程分支。当地分支机构应该跟踪；git config -l | grep -w remote说：

这是我的问题：如何使用单个 git 命令同时从远程分支更新所有本地分支？ git-fetch不太行；它更新它对每个远程分支的内容的了解，但它不会将它们合并到本地。显然git-pull只更新当前签出的分支。我想一次更新所有分支。可以做到吗？

（我并不疯狂

部分原因是在我的工作目录中修改后的文件在这一切进行时会发生什么对我来说并不明显，部分原因是我需要更多的 shell 代码来保存和恢复有关我当前所在分支的信息。）

我发现了一个（不是很密切相关的）问题：

• 关于跟踪远程分支

我的公司正在考虑将我们的版本号扩展另一个档次（例如从major.minor.servicepack 到major.minor.servicepack.customerfix），以允许客户特定的修复。

从表面上看，这让我觉得这是个坏主意，因为我的经验是产品的分支越多（我相信客户修复程序是代码库的分支），开销就越大，工作量越分散，最终开发效率就越低组变成。

我见过很多风险与生产力的讨论，但仅仅说“我认为这是一个坏主意”还不够。关于过于规避风险并采用繁重的、客户特定的源代码分支开发模型的实际成本有哪些文献？

一点澄清。我希望这个模型意味着客户可以控制哪些错误修复进入他们自己的私有分支。我认为他们很少会升级到通用后备箱（它甚至可能不存在于这个模型中）。我的意思是，如果你可以控制自己的私人现实泡沫，你为什么要这样做？

在 TFS 中，标记死分支的最佳方法是什么？你移动你的分支吗？分行发布吗？删除它？重命名它？对于这些方法中的每一种，您都遇到了哪些问题？有哪些优点？

如果有一个简单的界面解决方案可以在特定分支被标记为已死时简单地标记或过滤当前视图，那就太好了。这样你就不必做一些永久性的事情，比如 rename 或 delete a branch 。. .

您好我想创建一个简单的存储过程，它执行以下操作：

伪代码

这种方法有效吗？谢谢你。

我正在为表单创建工作流程。

表单是需要4个审批人或被拒绝的审批表。

我可以得到批准，但不能得到拒绝。

我正在使用设计师 2007。

我的工作流程如下所示：

第 1 步：条件：如果 Created 等于 created Action:Email 通知所有批准者。

第 2 步：
条件：Else 如果 TomR 等于 yes 如果 TomA 等于 yes 操作：向创建者发送电子邮件，然后向...发送电子邮件

从这里开始，我使用与上述相同的步骤为其他 3 个批准者创建了条件分支。

我不相信我明白我在做什么显然。

我在一个存储库中有多个网站项目，每个项目都有一个 WordPress 副本。更新 WordPress 意味着更新所有项目文件夹并保留冗余副本。这对于同步整个文件夹的 rsync 脚本很有用。它还为我提供了该站点的完整工作本地副本。

我可以通过多种方式改进这一点，并希望得到一些反馈。我在 Windows 上，最近迁移到 Subversion。

1. 在每个网站文件夹中创建指向 WordPress 位的符号链接。这会在 Subversion 和 Apache 中得到支持吗？有什么缺点吗？
2. 拥有一个 WordPress 文件夹并将其分支到其他网站主干。我读到分支很便宜，并且维护一个副本，但我不确定是否应该跨主干进行分支。就个人而言，我认为这是最好的方法。有什么理由避免这种情况吗？
3. 最后，我可以保留当前结构并使用脚本在所有网站文件夹中进行复制。

最好的方法是什么，是否有任何替代解决方案？