我有一个包含两个分支的Git存储库：master和Release/v1.0。在master我有一个我无法直接推送的分支政策，我可以通过Pull Requests做出贡献。
现在，我正在修复Release / v1.0上的错误，并希望将其合并到master。 因此，我会做以下事情：
// create a new branch from master where I merge the changes from Release/v1.0
git checkout -b merge-to-master
// start the merge
git merge origin/Release/v1.0
// merge gets committed automatically, so I just need to push (to upstream if the branch doesn't exist remotely)
git push
现在，我正在从merge-to-master向master提出拉取请求。 PR完成后，我在master中进行了所有更改。
合并按预期工作。但是，当我再次开始合并时，我希望这些提交不再出现，因为它们已经合并。但是这些提交在合并视图中一次又一次地出现。
我认为合并信息写得不正确？ 现在我的问题是：我做错了吗？如何避免相同的提交一遍又一遍地出现？
@UPDATE：
另外，当我想删除一个本地分支（git branch -d v1.0/212760-wrong-status - 这是一个功能分支）时，它告诉我：
error: The branch 'v1.0/212760-wrong-status' is not fully merged.
If you are sure you want to delete it, run 'git branch -D v1.0/212760-wrong-status'.
但是，我已经发布PR版本/ v1.0（并完成了它），所以我认为它是完全合并的。但为什么Git有不同的意见？ ：）
答案 0 :(得分：1)
我想，但无法从所提供的信息中确定，这是关键：
我可以[仅]通过Pull Requests贡献
当您向其他人发送拉取请求 时，您要求他们采取某些行动。我们需要知道他们是谁。谁 他们？让我们找出他们正在做的事情！
让我们从这开头：
v1.0/212760-wrong-status
我认为这意味着你已经完成了：
git checkout -b v1.0/212760-wrong-status v1.0
或您自己的存储库中的等效文件，然后在此处进行一次或两次提交以修复错误。然后你做了：
git checkout -b merge-to-master master
git merge origin/Release/v1.0
git push
步骤。 （如果您在此处提取实际步骤和实际提交哈希ID和分支名称，这将有很大帮助，因此所有内容都与实际哈希ID具体相关。）请注意git push会将实际提交推送到某些其他存储库，例如您调用origin的存储库或您调用upstream的存储库（可能是不同的/单独的存储库）;每次推送都会要求其他 Git设置一些分支名称以指向特定的提交。
此时，让我们也给每个人起名，以便我们知道谁在采取行动。我将称呼Dave并谈论Dave的提交，它们具有您可以在存储库或存储库中看到的特定哈希ID（运行git log --all --decorate --oneline --graph以查看缩写的哈希ID和图形）。我没有操作上游存储库的人的名字;让我们称她为Ursula，它以U为上游开始。
此外，这些天，＆＃34;拉请求＆＃34;通常意味着像GitHub或Bitbucket这样的托管服务。 GitHub特别提供了一个clicky按钮，＆＃34;合并拉取请求＆＃34;，并附有一个下拉菜单。单击下拉菜单而不是＆＃34;合并拉取请求＆＃34;按钮提供三个选项，用于更改clicky按钮的操作：
合并。这是一个直接的合并：Ursula将添加到Ursula的（上游）存储库，由Dave从Dave的Web托管存储库副本中提交的一个或多个提交。 Dave的提交将拥有Dave提交的哈希ID，因为他们是 Dave的提交。 Ursula将使用一个新的唯一哈希ID创建一个新提交。
重新基础和合并。这使得Dave的提交副本。 Ursula会将这些副本添加到Ursula的存储库中，之后Dave的提交基本上已经死了--Dave应该用Ursula的副本替换它们。
壁球并合并。这使得一个新的提交（专属于Ursula）与Dave的 N 提交进行相同的更改（无论大 N 是的，即使它只是1）。如果 N = 1，这与＆＃34; rebase和merge＆＃34;非常相似，尽管默认提交日志消息不同。在任何一种情况下，Ursula的新单一提交都会避免所有Dave的原始提交，就像在rebase-and-merge模式下一样。
一旦厄秀拉完成，你（戴夫）可以git fetch她的提交 - 至少其中一个 - 来自你使用单词upstream拼写的地址。如果她是真正的合并，她将合并你在v1.0/212760-wrong-status上做出的承诺（我相信）。也就是说，具有相同哈希ID的精确提交现在存在于Ursula的存储库中。她合并到她的master有一个不同的哈希ID，从你合并到你的主人，但它确实使用你的原始提交。
如果你那么，在你自己的计算机上的存储库中（不是你在GitHub上的origin或其他），请查看你的master并快进到她的合并提交（现在显示， git log --all --decorate --oneline --graph上的upstream/master，然后运行：
git branch -d v1.0/212760-wrong-status
您的Git会看到将v1.0/212760-wrong-status 的提示合并到您当前的分支master。也就是说，通过查看Ursula的合并提交的第二个父级，您的Git可以跟踪从您的master到该特定提交的直接线路。因此，提交包含在master中，Git很乐意从本地存储库中删除名称 v1.0/212760-wrong-status。
由于不是的情况，我们可以得出结论，Ursula必须使用＆＃34; rebase并合并＆＃34;或者＆＃34;挤压和合并＆＃34; clicky按钮的模式，用于进行提交的复制。如果副本足够好 - 如果你对Ursula复制你的提交的方式感到满意 - 你可以安全地强行删除你的分支名称，丢失你的原始提交（最终永远你的reflogs可能会保留它30天左右，如果你改变了主意。）
换句话说，如果Ursula已经复制你的提交到一个新的，据称改进的提交，以避免你的原始提交，现在取决于你 - 戴夫 - 决定是否戴夫＆＃s; s原始提交应该被丢弃，以支持这个新副本。这就是你的Git告诉你的。
如果您没有丢弃您自己的提交，那么您的下一个拉取请求可能会取决于您如何构建它 - 重新介绍这个提交。它是否会像往常一样依赖于实际的提交图。提交图 - git log --graph绘制的图 - 是重要的。您通过拉取请求提供实际提交，其中包含实际图形段。 如果他们接受了您的实际提交，则会添加您的图表细分，现在您和他们共享图表。但如果他们不接受您的提交，他们就会＃39 ; ll添加一些其他提交与不同的图段。您的Git会将他们的提交添加到您的图表中，为您提供包含大量提交副本的更大图表。由你决定如何处理这个问题。