您需要在~/中添加以下内容。gitconfig文件:

[rebase]
    autosquash = true

这将自动实现与此答案所显示的相同的结果。

接下来我来处理。

用2点url代替3点url来比较

而不是

http://githuburl/org/repo/compare/targetbranch...currentbranch

Use

http://githuburl/org/repo/compare/targetbranch..currentbranch

如果你太担心会把事情搞砸，可以采用故障安全方法: 转到文件并手动删除更改，然后使用最后一次提交压缩

git add .  && git commit -a --allow-empty-message -m '' && git reset --soft HEAD~2 &&
git commit --edit -m"$(git log --format=%B --reverse HEAD..HEAD@{1})"

我没有矛盾，你就好走了!

我不太确定这背后的理论。但我得到了这个几次，并能够通过做下面的事情来解决这个问题。

git pull --rebase

这将从您的原始回购主分支获取并合并更改(如果您有指向)

然后你把你的更改强行推到你的github克隆库(目标)

git push -f origin master

这将确保你的github克隆和你的父repo在相同的github提交级别，你不会看到跨分支的任何不必要的更改。

这发生在GitHub中，当你压缩从目标分支合并的提交时。

I had been using squash and merge with Github as the default merge strategy, including merges from the target branch. This introduces a new commit and GitHub doesn't recognize that this squashed commit is the same as the ones already in master (but with different hashes). Git handles it properly but you see all the changes again in GitHub, making it annoying to review. The solution is to do a regular merge of these pulled in upstream commits instead of a squash and merge. When you want to merge in another branch into yours as a dependency, git merge --squash and revert that single commit before pulling from master once that other branch has actually made it to master.

编辑:另一种解决方案是重新基底和强制推。干净但被改写的历史

我找到了一种方法来获得正确的行为(在2020年11月测试)。

git合并和解决冲突后，需要使用git merge——continue而不是git commit ....