有没有一种快速的方法来从点或分支原点“ git diff”？

Use git diff @{u}...HEAD, with three dots.

With two dots, or with HEAD omitted, it will show diffs from changes on both sides.

With three dots, it will only show diffs from changes on your side.

Edit: for people with slightly different needs, you might be interested in git merge-base (note that it has plenty more options than the other answer uses).

You can find the branch point using git merge-base. Consider master the mainline and dev the branch whose history you are interested in. To find the point at which dev was branched from master, run:

git merge-base --fork-point master dev

We can now diff dev against this basis:

git diff $(git merge-base --fork-point master dev)..dev

If dev is the current branch this simplifies to:

git diff $(git merge-base --fork-point master)

For more information see the git-merge-base documentation.

You can diff the current branch from the branch start point using:

git diff (start point)...

Where (start point) is a branch name, a commit-id, or a tag.

Eg if you're working on a feature branch branched from develop, you can use:

git diff develop...

for all changes on the current branch since the branch point.

This was already mentioned in a comment, but I think it deserves answer status. I don't know what it will do since last rebase.

For diffs, you want the three-dot notation. If your branch is called dev and it branched from master:

% git diff master...dev

For log, you want the two-dot notation:

% git log master..dev

The revision syntax r1..r2 (with two dots) means "everything reachable from r2 (inclusive) but not reachable from r1 (inclusive)". The normal way to use this is to think of r1 and r2 as specifying a range in a sequence of commits (r1 exclusive, r2 inclusive), so if you have 10 revisions, 3..7 will show you changes 4, 5, 6, and 7. It's {1, 2, 3, 4, 5, 6, 7} minus {1, 2, 3}. But r1 doesn't necessarily have to be an ancestor of r2. Think of it more like a set operation where r1 represents the entire ancestry from r1 backwards, and r2 represents the entire ancestry from r2 backwards, and you're subtracting the first set from the second set.

So then:

git log master..dev

is the entire history of the branch minus the entire history of master. In other words, just the branch.

In Visual Studio 2017 there is a comfortable way to show diffs:

1. In Team Explorer -> Branches right click the branch and select View History

2. In the History - branch control select the commits you want the diff and select Compare Commits

You get a nice diff overview and you can open the files in compare mode.

To diff against the remote master branch:

git diff $(git merge-base HEAD origin/master)..

The current solution mentions

Use git diff @{u}...HEAD, with three dots.

But... this is best done with Git 2.28 (Q3 2020).
Before, "git diff" used to take arguments in random and nonsense range notation, e.g. "git diff A..B C ", "git diff A..B C...D", etc., which has been cleaned up.

See commit b7e10b2, commit 8bfcb3a (12 Jun 2020), and commit bafa2d7 (09 Jun 2020) by Chris Torek (chris3torek).
^{(Merged by Junio C Hamano -- gitster -- in commit 1457886, 25 Jun 2020)}

git diff: improve range handling

^{Signed-off-by: Chris Torek}

When git diff is given a symmetric difference A...B, it chooses some merge base from the two specified commits (as documented).

This fails, however, if there is no merge base: instead, you see the differences between A and B, which is certainly not what is expected.

Moreover, if additional revisions are specified on the command line ("git diff A...B C"), the results get a bit weird:

• If there is a symmetric difference merge base, this is used as the left side of the diff.
  The last final ref is used as the right side.

• If there is no merge base, the symmetric status is completely lost.
  We will produce a combined diff instead.

Similar weirdness occurs if you use, e.g., "git diff C A...B D". Likewise, using multiple two-dot ranges, or tossing extra revision specifiers into the command line with two-dot ranges, or mixing two and three dot ranges, all produce nonsense.

To avoid all this, add a routine to catch the range cases and verify that that the arguments make sense.

As a side effect, produce a warning showing which merge base is being used when there are multiple choices; die if there is no merge base.

The documentation now includes:

'git diff' [<options>] <commit> [<commit>...] <commit> [--] [<path>...]:

This form is to view the results of a merge commit.

The first listed must be the merge itself; the remaining two or more commits should be its parents.
A convenient way to produce the desired set of revisions is to use the {caret}@ suffix.
For instance, if master names a merge commit, git diff master master^@ gives the same combined diff as git show master.

I wrote an alias in my .gitconfig to solve this task:

[alias]
# See changes since branching off of main branch
changes = "!f() { \
current=$(git rev-parse --abbrev-ref HEAD); \
main=$(git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@'); \
commit=$(git merge-base --fork-point \"$main\" \"$current\"); \
git diff \"$commit\"...; \
}; f"

Line-by-line, this alias:

1. Defines a shell function, f, which
2. computes the current branch name,
3. computes the main branch name (which could be main, master, develop, etc.),
4. computes the commit from which these two branches diverge, and
5. runs git diff to see the changes since this commit

If you use a newer git version, you can simply use

git diff --merge-base <target_branch>

Which delivers (for me) identical results to currently highest voted answer of:

git diff $(git merge-base --fork-point origin/main)

The command was introduced in Git Version 2.30 as:

"git diff A...B" learned "git diff --merge-base A B", which is a longer short-hand to say the same thing.

So basically it another way of gettings the same result as the currently accepted answer.