问题标签 [branching-and-merging]

我们刚刚升级到 TFS 2010。我们为每个项目创建了一个开发分支。如果在 Branch1 中进行了更改，然后将 Branch1 合并回基线，它会合并每个文件，而不仅仅是更改的文件。

对 Branch1 中文件的后续更改然后合并到基线只会合并那些更改（这是我们想要的），除非来自 Branch2 的更改在 Branch1 的第一次和第二次合并之间合并，然后每个文件再次合并（我们不想）。

我们怎样才能让它每次只合并更改的文件？

我目前正在开发一个 .NET 项目，该项目由多个逻辑层和多个前端组成。这是我们的 SVN 结构的粗略表示：

我们所有的日常开发都发生在主干中——这是所有开发人员从/提交到的地方。

我正在寻找一种在环境（测试和生产）之间干净、轻松地部署的方法。

我的想法是创建两个分支，测试和生产，从主干 - 解决方案和所有。我为自己辩护，原因如下：

1. 通过仅从主干合并到测试分支以及从测试分支合并到生产分支，我可以完全控制哪些修改流向哪些环境
2. 只需查看 Subversion 中相应分支的日志，我就可以轻松查看每个环境中正在执行的代码

有没有人有过类似的解决方案的经验？我是否遗漏了任何潜在的陷阱或疏忽？

使用 Visual SourceSafe 2005：

在较早的时间点，我标记了我的来源以指示该软件的新版本的发布。

我现在要做的是创建一个创建标签的分支，以便在不包括我在软件上所做的其他工作的情况下发布一个小升级。

我是否为此使用分支，以及如何在 VSS 2005 中执行此操作？

有没有人有代码（最好是在 Win32 上运行）可以显示在 Perforce 分支中发生的所有文件重命名和移动的历史记录？

Fossil SCM 中有关分支的文档说，如果叶子有一个封闭的标签，它就被认为是封闭的。但是，当我进入

它没有显示任何已关闭的内容。如果我添加带有--propagate. 当我检查Fossil本身的闭合叶子时，列出的叶子没有closed显示任何标签。我有什么误解？

我创建了一个名为“features”的 SVN 项目的分支，现在每当我尝试更新所述项目时，它都会带来一个 features 文件夹，其中包含来自该分支的项目的另一个副本。

有没有办法完全从存储库中删除分支，这样就不会再发生这种情况了？

很长一段时间以来，我们所有的开发和部署都是从主干完成的。过了一段时间，这导致生产环境与主干不同步，因为我们收到将新功能“B”移动到生产环境的请求，但推迟了新功能“A”——基本上我们会从主干结帐到临时文件夹，然后有选择地将文件从临时合并到生产（不受版本控制）

在为此挣扎了太久之后，我终于决定重新安排存储库以允许分支，但是在移动（svn mv）主干时犯了一些错误，以便我可以为分支和标签文件夹腾出空间（以前在那里不是“主干”文件夹，文件只是位于项目的父文件夹中），最终结果是我的“主干”现在比我从中创建的一些分支更新。现在我似乎无法从分支合并回主干，而不会丢失很多更改并遇到很多冲突。（我已经从主干更新了分支。）

如果我svn log --stop-on-copy在我的主干上运行，最早的版本是 r14376，如果我在我的分支上运行它，最早的版本是 r14368。（HEAD 位于 r14710）

如何在不丢失 r14368 和 r14376 之间的所有更改的情况下进行正确的合并？我只是要手动合并到主干，但随后我丢失了分支文件的所有修订历史记录。

我们的大学在我们管理的服务器上为校园部门提供网络托管。安装开源第三方程序需要在程序运行前修改文件权限和代码。（如果您熟悉的话，我们使用的是 suEXEC。）

我们目前通过安装程序脚本提供 WordPress。用户上传最新的稳定版本，并通过 SSH 运行服务器端 PHP 脚本。这个 PHP 脚本修改所有文件/文件夹的文件权限，添加/删除各种文件中的一些代码，并创建一些新文件。当发布新的稳定版本时，此安装程序脚本是一个繁琐的平衡操作。

我想开始使用版本控制（特别是 git）来跟踪我们的自定义更改，而不是依赖脚本来进行更改，但我不确定要使用的工作流程。我熟悉分支和合并，但不确定在发布新版本时如何集成我们的旧更改。

我的 git 工作流程应该是什么来集成来自 WordPress 核心的新更改，同时保留我们旧的自定义更改？

这在我的工作流程中经常发生：我正在处理一个单独分支中的功能，并且在执行此操作时，我会遇到需要修复但来自框架或站点布局更高层的小问题。

我想切换回主开发分支并从那里的选择文件提交更改，然后返回到功能分支并重新设置基准，以便我可以继续在那里进行不相关的调整/错误修复。

我正在使用git stash并git stash pop执行此操作，但是我从一堆我修改但不需要提交到父分支的文件中遇到了很多冲突。

是否有另一种方法可以避免冲突或以某种方式保存当前状态，并且只将选择的工作树更改拉到另一个分支进行提交？（有点像 git-stash-cherry-pick ;-)）

我一直在努力了解 SVN 合并/重新集成，并阅读了这些文章/书籍：

http://svnbook.red-bean.com/en/1.5/index.html
http://blogs.open.collab.net/svn/2008/07/subversion-merg.html

我显然还没有完全明白，因为我不明白为什么在合并回主干（反射/循环合并）中包含同步修订是一个问题 - 我确实看到了不排除修订的理由。

如果trunk上的一行文件A被合并到branch上的文件A'中，然后又合并回trunk，那么A和A'肯定没有区别，所以不冲突？为什么“[合并]主干中已经存在的更改”是一个问题？

我正在尝试复制冲突场景，以尝试了解 reintegrate 为我做的事情，但更让我困惑的是这种情况：

1. 在主干上提交更改 (r4)
2. 将 r4 合并到分支并提交 (r5)
3. 在分支上提交更改 (r6)
4. 通过以下任一方式将分支合并到主干：
   • 将修订范围 r5-r6 合并到主干 - 发生冲突，或
   • 将 r5 合并到主干，然后将 r6 合并到主干 - 不会发生冲突

我正在使用 SmartSVN 6.6 和 SVN 1.6。为什么与单独合并每个修订版相比，合并修订版范围时会产生不同的结果？最终，为什么包含反射合并是一个问题？