git pull 时 配置适合自己的合并策略 git config pull.rebase

当 git pull 时有可能遇到以下的提示

hint:   git config pull.rebase false  # merge (the default strategy)
hint:   git config pull.rebase true   # rebase
hint:   git config pull.ff only       # fast-forward only
1
2
3

这三个配置项影响git pull的默认行为。以下是对它们的详细解释：

1. 默认合并策略（git config pull.rebase false）

前提条件：

1. 本地分支上有一系列提交(git commit)，远程分支上也有一系列提交。

后续变化：

1. 执行 git pull 后，Git 会创建一个新的合并提交，将本地分支和远程分支的更改合并在一起。

优点：

• 直观易懂，不改变提交历史。

缺点：

• 会引入新的合并提交，可能导致提交历史变得复杂。

可能的影响：

• 提交历史看起来清晰，但可能会显得杂乱，特别是在频繁的合并操作后。

2. 重新基础合并策略（git config pull.rebase true）

前提条件：

1. 本地分支上有一系列提交(git commit)，远程分支上也有一系列提交。

后续变化：

1. 执行 git pull --rebase 后，Git 会将本地分支上的提交暂存，应用远程分支的更改，然后重新应用本地提交。

优点：

• 产生线性的提交历史，保持了更干净的提交历史。

缺点：

• 可能会引发冲突，需要手动解决冲突。
• 改变了提交历史，可能会导致团队协作的困难。

可能的影响：

• 提交历史线性，但在共享的分支上进行重新基础可能会导致冲突，需要小心使用。

3. 仅快进合并策略（fast-forward only）

前提条件：

1. 本地分支上有一系列提交(git commit)，远程分支上也有一系列提交。

后续变化：

1. 执行 git pull --ff-only 后，Git 只允许快进合并。如果能够快进合并，则本地分支会直接指向远程分支的最新提交，否则会拒绝合并。

优点：

• 保持了线性的提交历史，没有引入新的合并提交。

缺点：

• 无法执行合并操作，如果有新的提交则会拒绝。

可能的影响：

• 适用于在本地分支上进行独立开发，确保不引入新的合并提交。

这样的表述应该更清晰，希望对您理解有帮助。