问题标签 [git-merge]

我使用git pull并遇到了合并冲突：

我知道该文件的其他版本是好的，而我的是坏的，所以我的所有更改都应该被放弃。我怎样才能做到这一点？

我想解决我的Git存储库中的合并冲突。

我怎样才能做到这一点？

使用 将主题分支“B”合并到“A”git merge时，我遇到了一些冲突。我知道所有的冲突都可以使用“B”中的版本来解决。

我知道git merge -s ours。但我想要的是类似的东西git merge -s theirs。

为什么不存在？git与现有命令发生冲突合并后，如何获得相同的结果？（git checkout来自 B 的每个未合并的文件）

仅丢弃分支 A 中的任何内容（合并提交点到树的 B 版本）的“解决方案”不是我想要的。

从 git-merge 的手册页中，您可以使用许多合并策略。

• 解决- 这只能使用 3 路合并算法解决两个头（即当前分支和您从中提取的另一个分支）。它试图仔细检测交叉合并歧义，并且通常被认为是安全和快速的。

• 递归- 这只能使用 3 路合并算法解决两个头。当有多个共同祖先可用于三向合并时，它会创建共同祖先的合并树并将其用作三向合并的参考树。据报道，通过对取自 Linux 2.6 内核开发历史的实际合并提交进行的测试，这可以减少合并冲突，而不会导致错误合并。此外，这可以检测和处理涉及重命名的合并。这是拉取或合并一个分支时的默认合并策略。

• 章鱼- 这解决了两个以上的情况，但拒绝进行需要手动解决的复杂合并。它主要用于将主题分支头捆绑在一起。这是拉取或合并多个分支时的默认合并策略。

• 我们的 - 这解决了任意数量的头，但合并的结果始终是当前分支头。它旨在用于取代分支的旧开发历史。

• 子树- 这是一种修改后的递归策略。合并树 A 和 B 时，如果 B 对应 A 的子树，则首先调整 B 以匹配 A 的树结构，而不是读取同级树。对共同祖先树也进行了这种调整。

我什么时候应该指定不同于默认值的东西？什么场景最适合？

我在一个新项目上使用 Git，该项目有两个并行的——但目前是实验性的——开发分支：

• master: 现有代码库的导入以及我通常确定的一些修改
• exp1: 实验分支#1
• exp2: 实验分支#2

exp1并exp2代表两种截然不同的架构方法。在我走得更远之前，我无法知道哪个（如果有的话）会起作用。当我在一个分支中取得进展时，我有时会进行一些对另一个分支有用的编辑，并且只想合并那些。

将选择性更改从一个开发分支合并到另一个分支的最佳方法是什么？

我考虑过的方法：

1. git merge --no-commit然后手动取消暂存大量我不想在分支之间通用的编辑。

2. 手动将公共文件复制到临时目录中，然后git checkout移动到另一个分支，然后将更多手动文件从临时目录中复制到工作树中。

3. 上面的一个变种。暂时放弃exp分支并使用两个额外的本地存储库进行实验。这使得手动复制文件更加简单。

所有这三种方法似乎都很乏味且容易出错。我希望有更好的方法；类似于过滤器路径参数的东西，它会使git-merge选择性更强。

几个月来，我和其他开发人员一起在一个项目中使用了 Git。我有几年的SVN经验，所以我想我给这段关系带来了很多包袱。

我听说 Git 非常适合分支和合并，但到目前为止，我还没有看到它。当然，分支非常简单，但是当我尝试合并时，一切都变得糟糕透顶。现在，我已经习惯了 SVN，但在我看来，我只是将一个低于标准的版本控制系统换成了另一个。

我的搭档告诉我，我的问题源于我想随意合并的愿望，并且在许多情况下我应该使用 rebase 而不是合并。例如，这是他制定的工作流程：

本质上，创建一个特性分支，总是从主分支变基到分支，然后从分支合并回主分支。需要注意的重要一点是，分支始终保持在本地。

这是我开始的工作流程

有两个本质区别（我认为）：我总是使用合并而不是变基，并且我将我的功能分支（和我的功能分支提交）推送到远程存储库。

我对远程分支的推理是我希望在工作时备份我的工作。我们的存储库会自动备份，如果出现问题可以恢复。我的笔记本电脑没有，或者没有那么彻底。因此，我讨厌在我的笔记本电脑上有没有在其他地方镜像的代码。

我对合并而不是 rebase 的理由是，merge 似乎是标准的，而 rebase 似乎是一个高级功能。我的直觉是我想做的不是高级设置，所以 rebase 应该是不必要的。我什至仔细阅读了关于 Git 的新实用程序设计书，它们广泛地涵盖了合并，几乎没有提到变基。

无论如何，我在最近的一个分支上遵循我的工作流程，当我试图将它合并回 master 时，一切都变得糟糕透顶。与本应无关紧要的事情发生了很多冲突。这些冲突对我来说毫无意义。我花了一天的时间整理一切，最终以强制推送到远程 master 达到高潮，因为我的本地 master 已经解决了所有冲突，但远程 master 仍然不高兴。

像这样的“正确”工作流程是什么？Git 应该让分支和合并变得超级容易，而我只是没有看到它。

2011-04-15 更新

这似乎是一个非常受欢迎的问题，所以我想我会用我第一次问起的两年经验来更新。

事实证明，最初的工作流程是正确的，至少在我们的例子中是这样。换句话说，这就是我们所做的并且它有效：

事实上，我们的工作流程有点不同，因为我们倾向于进行squash 合并而不是原始合并。（注意：这是有争议的，见下文。）这允许我们将整个功能分支变成 master 上的单个提交。然后我们删除我们的功能分支。这允许我们在 master 上逻辑地构建我们的提交，即使它们在我们的分支上有点混乱。所以，这就是我们要做的：

Squash Merge Controversy - 正如一些评论者所指出的，squash 合并将丢弃您功能分支上的所有历史记录。顾名思义，它将所有提交压缩为一个。对于小功能，这是有道理的，因为它将它压缩成一个包。对于更大的功能，这可能不是一个好主意，特别是如果您的个人提交已经是原子的。这真的取决于个人喜好。

Github 和 Bitbucket（其他？）Pull Requests - 如果您想知道合并/rebase 与 Pull Requests 的关系，我建议您按照上述所有步骤操作，直到您准备好合并回 master。无需手动与 git 合并，您只需接受 PR。请注意，这不会进行 squash 合并（至少默认情况下不会），但非 squash、非快进是 Pull Request 社区中公认的合并约定（据我所知）。具体来说，它是这样工作的：

我开始爱上 Git，再也不想回到 SVN。如果你在挣扎，那就坚持下去，最终你会看到隧道尽头的曙光。

我正在合并一个可能有很多冲突的远程分支。我怎么知道它是否会发生冲突？

我没有看到类似--dry-runon的东西git-merge。

如果我在多个分支中处理单个功能，我会使用git pull branch1 branch2 branch3将所有更改拉入我的主分支。但是，每个分支的所有提交日志也会被复制。如何将提交日志扁平化为一条消息？

什么时候推荐使用 Git rebase vs. Git merge？

成功变基后我还需要合并吗？

我和一位同事目前都在 master 分支上工作。我的工作树中有一些我不想提交的代码（调试语句等）。现在，如果他对其中一些相同的文件进行更改，我将无法合并它们：

来自颠覆背景，我习惯于在我从存储库中提取更改时自动合并我的工作树，如果有冲突，我会手动解决它们。

我发现在 git 中执行此操作的最快方法是：

本质上，删除我未提交的更改，进行合并，然后重新应用更改。如何告诉合并自动将我的工作树与我试图引入的更改合并？