`git merge`和`git merge --no-ff`有什么区别？ [英] What is the difference between `git merge` and `git merge --no-ff`?

问题描述

使用 gitk log ，我无法发现两者之间的差异。我怎么才能观察到不同（使用git命令或者某个工具）？ 如果检测到当前的 HEAD 标志阻止 git merge 执行快进 code>是您尝试合并的提交的祖先。快进是指，git不是构建合并提交，而是将分支指针移动到指向传入提交的位置。这通常发生在执行 git pull 而没有任何本地更改时。

然而，偶尔要防止这种行为通常是因为你想维护一个特定的分支拓扑结构（例如，你正在合并一个主题分支，并且你希望在阅读历史时确保它看起来像这样）。为了做到这一点，你可以传递 - no-ff 标志和 git merge 将总是

同样，如果你想执行一个 git pull 或者使用 git merge 来显式快速转发，并且如果它不能快速转发，那么您希望保留它，那么您可以使用 - 仅ff 标志。通过这种方式，你可以不加思索地定期做一些类似于 git pull --ff-only 的东西，然后如果出错，你可以回去决定是否要合并或重新绑定。

Using gitk log, I could not spot a difference between the two. How can I observe the difference (with a git command or some tool)?

解决方案

The --no-ff flag prevents git merge from executing a "fast-forward" if it detects that your current HEAD is an ancestor of the commit you're trying to merge. A fast-forward is when, instead of constructing a merge commit, git just moves your branch pointer to point at the incoming commit. This commonly occurs when doing a git pull without any local changes.

However, occasionally you want to prevent this behavior from happening, typically because you want to maintain a specific branch topology (e.g. you're merging in a topic branch and you want to ensure it looks that way when reading history). In order to do that, you can pass the --no-ff flag and git merge will always construct a merge instead of fast-forwarding.

Similarly, if you want to execute a git pull or use git merge in order to explicitly fast-forward, and you want to bail out if it can't fast-forward, then you can use the --ff-only flag. This way you can regularly do something like git pull --ff-only without thinking, and then if it errors out you can go back and decide if you want to merge or rebase.

这篇关于`git merge`和`git merge --no-ff`有什么区别？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！