你可以尝试做git日志子集:

git log --oneline devel ^next

要获得未集成到发布分支(下一个)的提交列表，您可以使用:

git rev-list --reverse --pretty="TO_TEST %h (<%ae>) %s" --cherry-pick --right-only origin/release_branch...origin/development_branch | grep "^TO_TEST " > NotIntegratedYet.txt

查看git-rev-list获取更多信息。

如何

git log next..devel

结果类似于Byran的答案(不同的提交顺序)，但我们的两个答案都会在分支之间产生不同的提交，而不是只显示一个分支中有什么而另一个分支中没有什么。

@Mark Longair在他的回答中指出了这一点，但我想补充一些额外的见解。

相关的，并且回答了如何分解一个大的Pull Request (PR)的问题，特别是当压缩你的提交是不切实际的，因为一个或多个master合并到你的feature_branch

My situation: I made a big feature_branch with 30 commits and opened a Pull Request (PR) on GitHub to merge it into master. Branch master changed a ton underneath me, and received 200 commits my feature_branch didn't have. To resolve conflicts I did git checkout feature_branch and git merge master to merge master's changes into my feature_branch. I chose to merge rather than rebase onto latest master so I would have to resolve conflicts only one single time instead of potentially 30 times (once for each of my commits). I didn't want to squash my 30 commits into 1 first and then rebase onto the latest master because that might wipe away GitHub review comment history in the PR. So, I merged master into my feature branch and resolved conflicts 1 single time. All was well. My PR, however, was too big for my colleagues to review. I needed to split it up. I went to squash my 30 commits and OH NO! WHERE ARE THEY? THEY ARE ALL INTERMINGLED WITH master's 200 recent commits now because I merged master into my feature_branch! WHAT DO I DO?

Git樱桃使用情况，如果你想尝试Git樱桃选择个人提交:

樱桃来拯救(某种程度上)!

要查看所有在feature_branch但不在master中的提交，我可以这样做:

git checkout feature_branch
git cherry master

或者，我可以检查来自任何分支的提交，而不确保我首先在feature_branch上执行git cherry [upstream_branch] [feature_branch]，就像这样。同样，这将检查哪些提交是在feature_branch中，而不是在upstream_branch中(在本例中是master):

git cherry master feature_branch

添加-v还会显示提交消息的主题行:

git cherry -v master

输送到"word count" "-lines" (wc -l)来计算有多少个提交:

git cherry master | wc -l

You can compare this count against the commit number shown in your GithHub PR to feel better about knowing git cherry really is working. You can also compare the git hashes one by one and see they match between git cherry and GitHub. Note that git cherry will NOT count any merge commits where you merged master into feature_branch, but GitHub WILL. So if you see a small discrepancy in the count, search the GitHub PR commit page for the word "merge" and you'll probably see that's the culprit which is not showing up in git cherry. Ex: a commit titled "Merge branch 'master' into feature_branch" will show up in the GitHub PR but not when you run git cherry master feature_branch. This is fine and expected.

所以，现在我有了一种方法来找出哪些差异，我可能想要樱桃选择到一个新的功能分支来分割这个差异:我可以在本地使用git樱桃master feature_branch，或者在GitHub PR中查看提交。

压扁会有什么帮助——如果我们能压扁:

An alternative, however, to split up my big diff is to squash all 30 of my commits into one, patch that onto a new feature branch, soft reset the patch commit, then use git gui to add pieces file by file, chunk by chunk, or line by line. Once I get one sub-feature, I can commit what I've added then check out a new branch, add some more, commit, check out a new branch, etc, until I have my big feature broken out into several sub-features. The problem is that my 30 commits are intermingled with the other 200 commits from other people due to my git merge master into my feature_branch, so rebasing is therefore impractical, as I'd have to sift through 230 commits to re-order and squash my 30 commits.

如何使用补丁文件作为一个更容易的压缩替换:

一个解决方法是简单地获取一个补丁文件，其中包含我所有30次提交的“压缩等效”，将它补丁到master的新分支(一个新的子功能分支)，然后从那里开始工作，如下所示:

git checkout feature_branch
# ensure I have the latest changes from master merged into feature_branch
git merge master 
# Obtain a patch file, which is the equivalent of a squash of my 30 commits into 1 commit:
git diff master..feature_branch > ~/mypatch.patch
git checkout master
# Create a new, sub-feature branch
git checkout -b feature_branch2
# Patch the 30 commit patch file onto it:
git apply ~/mypatch.patch

现在，我已经在本地应用了30个提交的补丁，但它们都是未部署和未提交的。

现在使用git gui添加文件，块和/或行，并打破你的大PR或“diff”:

注意，如果你没有git gui，你可以用sudo apt install git-gui在Ubuntu中轻松安装它。

I can now run git gui and start adding files, chunks, and/or lines (by right-clicking in the git GUI program), and break up the 30 commit feature branch into sub branches as described just above, repeatedly adding, committing, then forking a new feature branch and repeating this cycle until all changes have been added to a sub-feature-branch and my 30-commit feature is successfully broken up into 3 or 4 sub-features. I can open up a separate PR for each of these sub-features now, and they will be easier for my team to review.

引用:

从git存储库创建补丁或diff文件，并将其应用到另一个不同的git存储库

你可以尝试做git日志子集:

git log --oneline devel ^next

同样，你也可以用它来获得一个不错的不同提交的列表，这些提交没有在分支之间共享:

git log --left-right --graph --cherry-pick --oneline main...next

示例输出:

> 492508ac (HEAD -> next) feat: make bazzable
> 5ceb5a90 hotfix: off-by-one
> b4459544 feat: add bar
> b6ce3b78 (origin/add-foo, add-foo) feat: add foo

关键字是——精心挑选

——择优挑选

Omit any commit that introduces the same change as another commit on the "other side" when the set of commits are limited with symmetric difference. For example, if you have two branches, A and B, a usual way to list all commits on only one side of them is with --left-right, like the example above in the description of that option. It however shows the commits that were cherry-picked from the other branch (for example, "3rd on b" may be cherry-picked from branch A). With this option, such pairs of commits are excluded from the output.

正如在评论中提到的，最新版本的git添加了——cherry-mark:

——cherry-mark

比如——cherry-pick(见下文)，但是用=标记等价的提交而不是省略它们，用+标记不等价的提交。