Question

背景：

我想为使用Git进行版本控制的项目提供错误修复;
我没有项目公共存储库的写访问权;
项目维护者需要通过电子邮件提交补丁。

工作流：

我克隆项目的公共存储库;
我创建了一个本地分支，我在其中开发了我的错误修复程序;
我将补丁发送给维护者;
维护者应用补丁并推送到项目的公共存储库;
我将更改从master;

origin/master

我确认我的补丁是由维护者应用的。

问题：

git branch -d现在不会删除我的错误修复分支，而是error: The branch ... is not fully merged.

然而，维护者应用的补丁包含所有我在我的bug修复分支中所做的更改，因此直观地认为Git应声称分支“未完全合并似乎是错误的。 “

Git书似乎与我同意。它只提到git branch -d失败的一个原因 - 因为分支“contains work that isn’t merged in yet” - 在我的情况下不适用。

我不确定我是否在Git中遇到过错误，或者Git是否不支持我的用例。

是的，我可以继续使用git branch -D删除分支，但我宁愿不养成这样做的习惯，除非我想要删除一个分支，其中的文件发生了变化工作树确实尚未合并到任何其他分支。

我更愿意：

理解为什么Git声称错误修复分支“未完全合并”，即使分支的更改确实已应用于master，
找到比诉诸git branch -D更优雅的回复。

实施例

$ git clone https://git.example.com/repo.git
# Output omitted for brevity. Clone proceeded fine.
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
$ git checkout -b fix_bug_42
Switched to a new branch 'fix_bug_42'
$ vim foo.txt # Fix bug 42.
$ git add foo.txt
$ git commit -m "Fix bug 42"
[fix_bug_42 244540f] Fix bug 42
 1 file changed, 1 insertion(+)
$ git format-patch HEAD^
0001-Fix-bug-42.patch

然后我将0001-Fix-bug-42.patch发送给维护者。

维护者使用git am < 0001-Fix-bug-42.patch应用它，也可以进行其他一些提交，然后推送到origin / master。

然后我做了：

$ git remote update
Fetching origin
remote: Counting objects: 54, done.               # Numbers illustrative only
remote: Compressing objects: 100% (42/42), done.
remote: Total 42 (delta 29), reused 0 (delta 0)
Unpacking objects: 100% (42/42), done.
From https://git.example.com/repo
   7787ce5..1c1a981  master     -> origin/master
$ git status
On branch fix_bug_42
nothing to commit, working directory clean
$ git co master
Switched to branch 'master'
Your branch is behind 'origin/master' by 3 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)
$ git pull
Updating 7787ce5..1c1a981
Fast-forward
 bar.txt          |   3 +--
 contributors.txt |   1 +
 foo.txt          |   1 +
 3 files changed, 3 insertions(+), 2 deletions(-) # Numbers illustrative only

到目前为止，真好！让我们看看我的补丁是否已应用于这三个提交中的一个：

$ git log @...@^^^ # Show the last two commits
commit 1c1a981f0b9cbaa593c949cea07e3265e2f8c9fa
Author: A Maintainer <maintainer@example.com>
Date:   Thu Aug 11 20:58:32 2016 +0000

    Add sampablokuper to list of contributors

commit 44a35eae3dc69002b6d3484cd17ad653ee7de3c3
Author: Sam Pablo Kuper <sampablokuper@example.edu>
Date:   Thu Aug 11 19:00:00 2016 +0000

    Fix bug 42

commit 25c3562fecd3f42f76c7552fabec440dd4473c6e
Author: A Maintainer <maintainer@example.com>
Date:   Thu Aug 11 14:44:53 2016 +0000

    Edit bar.txt

看起来它已在倒数第二次提交中应用。我们确认一下！

$ diff -s <(git diff @^^ @^) <(git diff fix_bug_42^ fix_bug_42)
Files /dev/fd/63 and /dev/fd/62 are identical
$

我在fix_bug_42分支中所做的所有更改都已由维护者明确应用和提交。耶！

这意味着Git应该知道我现在可以安全删除我的bug修复分支，对吧？错！

$ git branch -d fix_bug_42
error: The branch 'fix_bug_42' is not fully merged.
If you are sure you want to delete it, run 'git branch -D fix_bug_42'.

哎呀！

假设

现在，我想我知道为什么会这样。我认为这是因为应用我的补丁的master中的提交（44a35eae3dc69002b6d3484cd17ad653ee7de3c3）与fix_bug_42中的提交具有不同的哈希值（244540f） ...）。即Git认为，因为master中不存在提交244540f，这意味着fix_bug_42“未完全合并”。

问题

我的假设是否正确？
无论如何，如果不使用git branch -D，我该怎么办？（例如，我可以使用更好的工作流程，这可以避免这个问题吗？）
Git的这种意外（至少对我来说）行为是代表Git中的错误，还是至少是改进处理此用例的合法功能请求？

Answer 1

您的假设是正确的，更好的工作流程会使用git request-pull：

之类的东西

https://git-scm.com/docs/git-request-pull

git没有办法知道你的提交与未经过大量详细检查而合并的提交相同，所以它并不是一个错误。

即使分支的更改已应用于主

实施例

假设

问题

1 个答案: