下面是我从主分支中使用的命令

git branch experiment
git checkout experiment

然后我对我的文件做了一些更改,提交这些更改,并将新的分支推送到GitHub。

git commit . -m 'changed files'
git push -u origin experiment

后来,我决定将我的实验分支合并到主分支中。

git checkout master
git merge experiment

最后,我把这些改动推到了GitHub上。

git push -u origin master

一切都很顺利,直到我试图删除我的实验分支使用

git branch -d experiment

我得到了错误信息:

错误:分支'experiment'没有完全合并。 如果你确定要删除它,运行'git branch -D experiment'。

我对git有点陌生,我不知道我还能合并多少两个分支。我错过了什么?


当前回答

我试了她的答案,但没有成功。

要查找未合并的提交,只需使用:

git log feature-branch ^master --no-merges

其他回答

我试了她的答案,但没有成功。

要查找未合并的提交,只需使用:

git log feature-branch ^master --no-merges

我的本地git上没有上游分支。我已经从master创建了一个本地分支,git checkout -b mybranch。我在上游git上用bitbucket GUI创建了一个分支,并将我的本地分支(mybranch)推到该上游分支。一旦我在我的本地git上进行了git取回来检索上游分支,我可以做一个git分支-d mybranch。

你可以简单地算出:

Git日志-樱桃大师…实验性的

-cherry选项是-right-only -cherry-mark -no-merges的同义词

Git-log手册页说

将输出限制到我们这边的提交,并用git log标记那些已经应用到fork历史另一边的提交,这是很有用的。Mybranch,类似于git樱桃上游的Mybranch。

仅供参考。——cherry-pick会省略相同的提交,但——cherry-marks不会。在上游和联合工作公共分支之间查找rebase并强制更新更改是有用的

我今天就遇到了这种情况,因为我正在将我的第一个功能分支合并回master中。正如一些人在SO的其他地方说的,诀窍是在尝试删除分支之前切换回master。一旦回到master, git很乐意在没有任何警告的情况下删除分支。

注:根据评论意见,措辞有所改变。由于@slekse 这不是错误,这是警告。这意味着您将要删除的分支包含从以下任何一个都无法到达的提交:它的上游分支或HEAD(当前检出的修订)。换句话说,当你失去提交¹。

在实践中,这意味着你可能修改、重基(包括压缩合并)或过滤提交,它们看起来并不相同。

因此,你可以通过签出一个分支来避免这个警告,这个分支包含了你要删除的另一个分支

你会想要验证你实际上没有错过任何重要的提交:

git log --graph --left-right --cherry-pick --oneline master...experiment

这将为您提供分支之间任何非共享的列表。如果你好奇的话,在没有选择的情况下可能会有区别,这种差异很可能是你得到警告的原因:

--cherry-pick 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-branch命令不会检查所有分支的修订树。这个警告是为了避免明显的错误。

²(我更倾向于强制删除,但你可能想要额外的保证)。