git练习合并两个分支并处理冲突

如何解决git练习合并两个分支并处理冲突

我必须克隆这个仓库：https://github.com/glo2003/H21-tp1-git 并整合两个分支：

重构/结构和修复/成分到主分支

Main 目前看起来像这样：

Framboise
Banane
Champignon

refactor/structure 有一个名为 listes 的新文件夹，其中包含文件 liste.txt（因此文件结构为 listes\listes.txt）：

- Framboise
- Banane
- Champignon

修复/成分：

Framboise
Banane
Pommes

想要的最终结果是这个（所以 champignon 被 Pommes 替换，并且列表具有带有“-”的新格式，文件夹结构也将是 listes\listes.txt

- Framboise
- Banane
- Pommes

我尝试了什么：

git clone https://github.com/glo2003/H21-tp1-git.git

git merge fix/ingredients

git 合并重构/结构

我做了 git status 来检查情况：

看起来listes.txt被删除了但不确定。

从那里我想用 vi listes.txt 或 vi listes\listes.txt 解决冲突，但我没有看到任何冲突的 Head 标签，所以我有点困惑？我究竟做错了什么。非常感谢。

解决方法

这是文件级冲突，不是文本冲突。要修复它，您可以操作索引：您说 git add 以保留文件并说 git rm 以删除文件。然后说 git commit 使其如此。

例如，如果你喜欢重组分支所做的，你可以说

$ git rm liste.txt
$ git add listes/liste.txt
$ git commit -m"finish merge"

但是您也接受了该文件的内容。如果您希望内容与 main 匹配，则需要将顶级 liste.txt 中的内容复制到 listes/liste.txt 中的内容之前做那些文件级的事情。

---

在评论中，您基本上说您希望这是一个文本级别的冲突，因此您可以在文本级别解决它。为此，您需要：

1. 中止合并。

2. 重新排列 main 上的文件结构以匹配分支上的文件结构，并添加并提交。

3. 现在执行合并，以这种方式指定：

    git merge -Srecursive -Xno-renames refactor/structure
   

这会给你移动的 liste.txt 作为文本冲突，你可以在 vi 或其他地方继续解决。

所以，这就是我从一开始就解决它的方法：

$ git clone [e-mail]:glo2003/H21-tp1-git.git
$ cd H21-tp1-git/
# create local branches
$ git checkout fix/ingredients
$ git checkout refactor/structure
$ git checkout main
$ git merge fix/ingredients
$ git merge refactor/structure
# file-level conflict,abort
$ git merge --abort
# mimic "theirs" file structure,and merge
$ mkdir listes
$ git mv liste.txt listes/liste.txt
$ git add .
$ git merge -Srecursive -Xno-renames refactor/structure
# now we have the text level conflict you wanted,as we can see:
$ cat listes/liste.txt
<<<<<<< HEAD
Framboise
Banane
Pommes
=======
- Framboise
- Banane
- Champignon
>>>>>>> refactor/structure

,

当你运行 git merge 时，git:

1. 找到一些共同的/共享的起点。这是历史上某个地方的另一个提交，“您”（运行 git merge 的人）和“他们”（您正在合并的提交的生成者）都从该提交开始。

2. 将合并库的全部内容与您当前的提交进行比较。这些是“您的更改”。就您而言，您更改了现有文件 liste.txt。

3. 将合并库的全部内容与其提交进行比较。这些是“他们的变化”。在他们的案例中，他们删除了一个现有文件，liste.txt，并创建了一个完全不同的文件，listes/listes.txt。

4. 结合——或尝试结合——这两组变化。

当无法使用 Git 内置的简单规则自动组合更改时会发生冲突。这里，无法组合的两个更改是：

• 你修改了一些文件；
• 他们完全删除了该文件。

Git 称之为“修改/删除冲突”。

现在，您声称他们重命名 liste.txt 为 listes/listes.txt。你是根据什么提出这个主张的？如果 listes/listes.txt 的文件内容与前者的文件内容完全相同，现在已删除 liste.txt，我可能会同意您的意见——Git 也可能同意。如果您提出这种说法的依据是 liste.txt 和 listes.txt非常相似，那么，我认为这不是一蹴而就的。 Git也没有看到它。一旦您指出，如果我们替换第 3 行并对第 1 行和第 2 行进行中等小的更改，这种程度的更改将更改 liste.txt 的内容以匹配新文件 listes/listes.txt 中的内容，然后我可能会同意——Git 也可能会同意。

最后，Git 用这个来决定某个文件是否被重命名，是计算 Git 所谓的相似性索引。如果旧文件和新文件的相似度指数足够高——达到或超过 50% 的相似度阈值——Git 将声明文件被重命名，而不是删除左侧文件(liste.txt) 并创建一个全新且不同的右侧文件 (listes/listes.txt)。

您可以使用 -X find-renames=number 控制此重命名相似度阈值。您还可以像在 matt's answer 中一样，使用 -X no-renames 禁用 完全重命名检测。如果 Git 在不应该错误分类的情况下将某些重命名为重命名，这很有用 - 但是如果 Git 应该 找到一些重命名，您将不得不处理他们自己。

总的来说，Git 的相似性检测在大文件上效果很好。它在您的示例文件上效果如此之差的原因是您的示例文件很小，而且太多行差异太大。