问题标签 [merge-conflict-resolution]

Git使用or实现以下工作流程的首选方法是什么Subversion （我对这个版本更感兴趣Git，但比较肯定会有用）：

• 假设我们最近发布了该产品的主要版本，并且有一个特定的 polisihin 分支，名为release-2.0.x.

  然后开发继续进行，几个功能分支被合并到master/trunk（它们稍后将成为即将到来的部分release-2.1.x）。

• 现在，在某个时候，另一个特性（即critical-feature）被开发并合并回master/trunk. 我们意识到这个特性是如此重要，以至于我们必须将它反向移植到release-2.0.x.

这是所描述案例的一个小伪图解。release-2.0.x请注意，顶部的所有内容都会导致与当前之间的树差异master/trunk并导致合并问题（否则我可以简单地合并critical-feature并避免写这个问题:)

问题：

• 从这个角度来看，执行功能反向移植的最佳方式是VCS什么？

• 这应该作为具有解决冲突冲突merge的相应分支的简单来完成吗？critical-feature

• 或者这应该作为cherry-pick提交的 完成，它在完成时合并critical-feature到master/trunk？或者甚至可能作为分支cherry-picks中每个提交的一组critical-feature？

• 你能为冲突解决程序提供一些建议吗？如果release-2.0.x和之间的当前差异master/trunk如此之大，“幼稚”的反向移植会由于代码重构和缺少功能而导致大量冲突，或者API在release-2.0.x?

• 除了标准的合并或挑选方法之外，是否Git或有针对此例程提供的特定内容？Subversion我想在冲突数量很大的情况下，重新设置基准不会有帮助，但是，显然，我可能是错的。

我从 github 分叉了一个项目，源点指向我自己的 github 存储库，远程指向其原始存储库，因为我想从远程获取更新，

我使用 git pull remote branch_name，然后我的本地 repo 处于冲突模式，现在我想取消 git pull 的效果，所以我使用 git stash，但惊讶地发现我没有这样做？怎么了？

详细信息如下：

那么如何取消 git pull 的效果呢？我应该删除repo，然后重新下载吗？

pom.xml将master合并到分支时，有没有办法避免版本标签中的合并冲突？我有很多 pom 文件，80 个，它们都有相同的版本，与 master 中的不同。git mergetool仅仅为了一个版本标签就执行 80 个 pom 文件既费力又费时。

我有一个带有一些库的 git 存储库，可以正常跟踪（不是作为子模块或任何东西）。我正在合并一个单独的分支（不是上游），其中包含对其中一个库的更新。可能是我可以实现更智能的合并策略，但是假设我使用了天真的合并（不是太不合理，对吧？）。

有什么办法吗，一旦我已经执行了

现在自动递归地解析 sub-dir/some/lib/* 以支持来自传入分支的“他们的”更改？

如果对此有明显或有效的合并策略，请随时分享，但我也对这个后天真的合并问题特别好奇。谢谢！

我看到人们建议所有开发人员在他们的机器上设置一个从C:\project\.git\rr-cache共享文件夹到共享文件夹的符号链接\\server\rr-cache。

但是，如果可能的话，通过将文件夹包含在 git 存储库本身中来共享文件夹似乎更方便。我见过人们提到这个解决方案，但实际上并没有提到如何去做。

有任何想法吗？

我怎样才能简单地（例如在一个命令中？）在 Git 中合并，保持当前分支中冲突文件的状态，而不像他们/我们的选项中那样单独指定每个文件？

尝试在个人项目中使用/学习 git。只有我和一个远程 git repo，一些提交，我陷入了失败的合并。我的很多文件现在也有 Git 合并冲突标记。

我如何告诉 git 把所有东西都扔掉，只用我的？

我如何进入我所处的状态的一个具体例子：

我们有一个简单的工作流程，包含三个主要分支

staging即测试环境

master即生产环境

dev/XXX其中 XXX 是票号

• 客户登录票据
• 我们创建一个分支，例如dev/2332
• 我们工作+提交+推送
• 我们将准备好的工作合并到staging
• 客户批准工作staging
• 我们将工作合并到master生产中并部署票证

问题：

如果多个开发人员在各自的dev/XXX分支上工作；当它们合并时staging，有时会产生冲突。他们在分期和推送上解决了这些冲突。

问题是当客户批准那些特定的票并且我们将工作合并到master时，我们必须再次解决冲突

重要的：

• 我们无法将 staging 合并到 master 中——因为票证未经批准
• 默认情况下，所有分支都是从最新的 master 创建的
• 多个工单正在同时开发，但在批准后部署
• 仅当工作已获得批准+已部署时，才可以从 master 重新定位以避免冲突
• 从暂存中重新定位不是一种选择 - 因为未经批准的票证

有关如何解决此问题的任何想法？我们的工作流程有缺陷吗？我们错过了一些 git hack 吗？

基本上，我不希望团队重复同样的事情两次

谢谢

我正在试验 VirtualSVN Server、TortoiseSVN 和 AnkhSVN，一切对我来说还是很新的。

我已向 SVN 添加了 Visual Studio 2010 (VB) 解决方案。完成后，主干包含版本 1.0.0，我有一个包含版本 1.0.0 的标签，以及一个包含版本 1.0.0-dev 的分支。我开始在 1.0.0-dev（来自分支）上工作，当版本 1.1.0 准备好时，我创建了一个标签版本 1.1.0，和一个新的分支 1.1.0-dev。

然后我想将这个最新版本（分支 1.1.0-dev）合并到主干，但遇到了一个巨大的合并（树？）冲突列表。其中大部分是因为 dll 文件、可执行文件和其他二进制文件。忽略这些文件似乎是个好主意，所以我从 Windows 资源管理器中做了，右键单击每种类型的文件，从上下文菜单中选择“TortoiseSVN - 取消版本并添加到忽略列表 - *.dll”（之后还有 *.exe和其他一些文件）。

现在我留下了一个解决方案目录树，上面有很多黄色感叹号以及已删除的标记。

我的问题是：

1. 如何更新主干以使其包含最新版本？
2. 在构建解决方案时如何忽略 Visual Studio 创建的 dll？
3. 有一个第三方 dll 未构建，应包含在存储库中，但文件可能保持不变，我应该如何处理？

存在 git rebase 冲突问题，但仅在使用 2 个远程存储库时。这是工作流程：

1. 做工作...
2. 犯罪
3. 拉 -r 登台大师

这工作正常。如果有冲突我可以解决。

然后在使用生产远程仓库时会出现问题。我是唯一一个推动生产的人。

1. git pull -r production （由于某种原因需要在投入生产之前执行此操作......不知道为什么，因为它应该是一个快速推进。）
2. git推送生产
3. git pull -r staging （更新我的仓库）

这是我在未处理的文件上遇到各种合并冲突的地方。

冲突可能如下所示：

所以，这里有几个问题：

1. 当我是唯一一个推动生产的人时，为什么我需要退出生产？
2. 为什么已经提交但我没有更改的代码会出现合并冲突？
3. 我会选择哪个提交？HEAD 或提交 foo
4. 什么是更好的过程，所以它不会发生？