Git 操作面试题, Git 中有哪些合并策略,比如 recursive 和 ours?

Step 1

Q:: Git 中有哪些合并策略，比如 recursive 和 ours？

A:: Git 提供了多种合并策略来处理不同的合并情况，其中最常用的有：

1. **recursive**：这是 Git 的默认合并策略，适用于两个不同分支的合并。它会尝试通过三方合并（three-way merge）将两个分支的变更合并在一起。如果有冲突，Git 会尝试自动解决，如果无法解决，则需要手动干预。

2. ours：这种策略在合并过程中会忽略所有来自其他分支的更改，只保留当前分支的更改。通常用于在分支历史中记录已经解决的冲突，但希望保留当前分支的内容。

3. theirs：与 ours 相反，这种策略会保留要合并的目标分支的更改，而忽略当前分支的更改。它经常用于接受上游仓库的变更，而不希望引入当前分支的更改。

4. octopus：适用于合并多个分支的场景，通常用于一次性将多个特性分支合并到主分支。如果存在冲突，Git 无法自动解决，开发者需要手动处理。

5. resolve：用于简单的两方合并，仅在有少量冲突时才推荐使用。

Step 2

Q:: Git 中的 fast-forward 合并是什么？

A:: fast-forward 是 Git 中的一种合并策略，当目标分支没有任何新提交时，源分支可以直接将目标分支的引用指向源分支的最新提交，而不产生新的合并提交。这种策略非常高效，但会丢失合并的历史记录，不推荐在需要保留合并记录的情况下使用。

Step 3

Q:: Git rebase 和 merge 的区别是什么？

A:: Git 中的 rebase 和 merge 都是整合分支变更的操作，但它们的工作方式有所不同：

- rebase：将一个分支上的所有提交应用到另一个分支的基础提交之上，形成一个线性的提交历史。它可以使历史记录更为整洁，但如果在共享分支上使用 rebase，可能会导致复杂的冲突。

- merge：直接将两个分支的历史合并，保持了分支点的记录，但会产生合并提交，从而使提交历史变得非线性。

Step 4

Q:: 在 Git 中如何处理合并冲突？

A:: 当 Git 在合并过程中检测到冲突时，开发者需要手动解决这些冲突。Git 会标记出冲突的文件，并用特殊的标记分隔冲突的内容。开发者需要手动编辑文件，决定保留哪个部分的内容或进行适当的修改。完成后，使用 git add 命令将解决后的文件标记为已解决，最后提交合并结果。

Step 1

Q:: Git 中有哪些常见的合并策略？例如 recursive 和 ours？

A:: 在 Git 中，常见的合并策略包括：

1. recursive：这是默认的合并策略，用于两边分支都有新提交时。它尝试通过三方合并将两个分支的更改合并，处理同一文件的冲突。

2. ours：在冲突时选择保留当前分支的内容，而忽略要合并进来的分支的更改。这种策略通常用于我们希望保留当前分支的所有更改而忽略其他分支时。

3. octopus：用于合并多个分支（即三个或更多分支）时。它尝试直接合并所有分支，但如果有冲突，它会放弃合并。

4. resolve：类似于 recursive，但仅用于两个父级的合并，且只尝试一次三方合并。

5. subtree：用于合并两个项目的子树历史，并保留它们的历史记录。

Step 2

Q:: 如何解决 Git 合并中的冲突？

A:: 在 Git 合并冲突时，Git 会在冲突的文件中插入冲突标记，开发者需要手动编辑这些文件以解决冲突。解决方法如下：

1. 打开冲突文件，找到标记为 <<<<<<``, ====== 和 >>>>>> 的冲突部分。

2. 选择要保留的更改，删除不需要的部分以及冲突标记。

3. 保存文件，使用 git add <file> 标记冲突已解决。

4. 最后，使用 git commit 提交合并结果。

在实际生产环境中，开发者可能还会借助 GUI 工具（如 VSCode、Sourcetree 等）来辅助解决冲突。

Step 3

Q:: Git 中的 Fast-forward 合并是什么？

A:: Fast-forward 合并是当当前分支是要合并的分支的祖先时发生的一种特殊合并情况。由于当前分支在合并时不需要进行额外的合并操作，只需将 HEAD 指向要合并的分支，从而“快速前进”到目标分支。这种方式不会生成新的合并提交，因为它不需要实际的合并操作。