git练习题（合并两个分支和处理冲突）

Question

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

refactor/structure 和 fix/ingredients 到 main 分支

Main 目前是这样的：

Framboise
Banane
Champignon

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

- Framboise
- Banane
- Champignon

fix/ingredients :

Framboise
Banane
Pommes

想要的最终结果是这个（所以 champignon 被 Pommes 取代，列表有一个新的格式，带有'-'，文件夹结构也将是 listes\listes.txt

- Framboise
- Banane
- Pommes

我尝试了什么：

git 克隆 https://github.com/glo2003/H21-tp1-git.git

git合并fix/ingredients

git合并refactor/structure

我做了 git 状态检查情况 :

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

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

Answer 1

这是文件级冲突，不是文本冲突。要修复它，您可以操纵索引：您说 git add 来保留文件，然后说 git rm 来删除文件。然后说 git commit 让它变成这样。

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

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

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

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

中止合并。
重新排列 main 上的文件结构以匹配分支上的文件结构，然后添加并提交。

现在执行合并，指定为：

 git merge -Srecursive -Xno-renames refactor/structure

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

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

$ git clone git@github.com: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

Answer 2

当你运行 git merge, git:

找到一些共同/共享的起点。这是历史上某处的另一个提交，“你”（运行宁 git merge 人）和“他们”（产生你正在合并的提交的人）都从这里开始。
将合并基础的全部内容与您当前的提交进行比较。这些是“您的更改”。在您的情况下，您更改了现有文件 liste.txt.
比较合并基础的全部内容与其提交。这些是“他们的变化”。在他们的案例中，他们删除一个现有文件，liste.txt，创建一个完全不同的文件, listes/listes.txt.
结合——或试图结合——这两组变化。

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

您修改了一些文件；
他们完全删除了那个文件。

Git 称之为“modify/delete 冲突”。

现在，你声称他们重命名 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=<em>number</em> 控制此重命名相似度阈值。您也可以像在中一样，使用 -X no-renames 禁用完全重命名检测。如果 Git 被 错误分类 某些不应该重命名的东西，这很有用——但是如果有一些重命名 Git 应该找到了，就得自己处理了。

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

git练习题（合并两个分支和处理冲突）

git practice exercise ( merging two branch and dealing with conflict)

git

git-merge

git-merge-conflict