“git diff"显示不够

本文介绍了“git diff"显示不够的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我想看看 master 分支和我的特性分支之间的区别.我有很多从 master 到我的 feature 分支的 pull，并且希望看到如果我将我的 feature 合并到 master 中将会添加的更改.

这是我的情况:

-*--*--*-----* 1--*--*--*--2--*

我的问题是 git diff master feature 似乎只显示提交编号 2.我如何才能看到 GitHub 拉取请求将显示的差异，我认为这完全是提交 1 的方式?

我注意到 git cherry 向我展示了我想要看到的不同之处.

解决方案

关于 git diff AB 需要意识到的重要一点是，它只会向您显示树的状态之间的差异.提交图中的两点 - 它不关心历史.用于 git diff 的 .. 和 ... 符号具有以下含义:

因此，当您运行 git diff master feature 时，它不仅会向您显示由您标记为 2 的提交引入的更改 - 输出应显示确切的差异master 中提交的树状态和 feature 中提交的树状态之间.如果它没有向您显示您的功能分支上的早期更改，也许您解决了早期从 master 合并的冲突，以支持 master 中的版本?

正如 的博客文章，其中讨论了

I want to see the difference between the master branch and my feature branch. I have many pulls from the master to my feature branch and want to see the changes that would be added if I merged my feature into the master.

This is my situation:

-*--*--*-----*<master> 1--*--*--*--2--*<feature>

My problem is git diff master feature seems to only display commit number 2. How can I see the diff that a GitHub pull request would show, which I believe is all the way to commit 1?

I noticed git cherry shows me the commits I want to see the difference for.

解决方案

The important thing to realize about git diff A B is that it only ever shows you the difference between the states of the tree between exactly two points in the commit graph - it doesn't care about the history. The .. and ... notations used for git diff have the following meanings:

So when you run git diff master feature that's not just showing you the change introduced by the commit you've marked as 2 - the output should show the exact differences between the state of the tree committed in master and the state of the tree committed in feature. If it's not showing you the earlier changes on your feature branch, perhaps you resolved conflicts from the earlier merges from master in favour of the version in master?

As cebewee says, it may be that what you want is git log -p master..feature, since git log does care about history. The meaning of .. and ... for git log are different since they select a range of commits:

Incidentally, it's often said that merging from master into a topic branch is the wrong thing to do - instead you should be rebasing, or merging your topic branch into master after it is complete. This keeps the meaning of the topic branch easily understood. The Git maintainer did a (somewhat difficult to understand) blog post about the philosophy of merging which discusses that.