如果我推送到已删除的分支会发生什么？答案

【问题标题】：What happens if I push to a deleted branch?如果我推送到已删除的分支会发生什么？
【发布时间】：2022-01-02 02:45:18
【问题描述】：

我有一个 git 分支。它被gitlab合并和删除。现在，发现一个错误，我想继续在这个分支上工作。我重命名了它，但它仍然跟踪已删除的分支（它不知道 gitlab 删除了该分支）。现在我很好奇，在这种情况下我该怎么办。

如果我按原样推动会发生什么？
如何将分支从该原点分离？
也许创建一个新分支更简单？

【问题讨论】：

标签： git branch git-branch

【解决方案1】：

在回答您的具体问题之前，我想指出您问题措辞的一个小细节：

我有一个 git 分支。 已合并并被 GitLab 删除。现在，发现一个错误，我想继续在这个分支上工作。

从概念上讲，我认为这样说更有意义：

现在，发现了一个错误，我想修复它。

由于该错误已经合并到主代码库中，因此您开发该代码的分支不再相关，这就是为什么典型的操作是在合并后将其删除。假设您想修复一年前引入的错误；你不会试图找到一个有一年历史的分支并从那里开始修复，而是你会从最新的main（或任何你的默认分支）创建一个分支，然后去修复这个错误。从概念上讲，这也是你应该为这种情况做的事情。话虽如此，如果您创建的新分支恰好与您之前使用的分支具有相同的名称，通常是可以的。无论分支名称最后一次使用是一年前还是几分钟前，都是如此。如果您确实重复使用相同的命名分支，您可能希望将其重置为最新的，例如main 首先。有多种方法可以做到这一点：

# Get the latest code before any of these
git fetch

# Delete the branch and re-create it:
git switch any-other-branch-name
git branch -d my-fav-branch-name-i-want-to-reuse # delete it
git switch -c my-fav-branch-name-i-want-to-reuse origin/main --no-track # create it again from main

# OR faster

# Just force switch to the same branch name:
git switch -C my-fav-branch-name-i-want-to-reuse origin/main --no-track

# OR faster if already checked out

# Just reset if branch is already checked out
git reset origin/main

这里的要点是分支名称并不神圣，您可以根据需要重新使用分支，或者使用其他名称。如果我正在修复一个错误，我可能更倾向于将我的分支命名为 user/ttt/fix-blah-blah-blah。

因此，鉴于这些信息，现在让我们回答您的问题。您的设置方案是远程分支已被合并和删除，并且您已重命名本地分支，但它仍在跟踪旧的上游分支名称。

如果我按原样推进会发生什么？

如果你git push，它只会在远程重新创建旧的分支名称。如果您没有重命名您的分支，假设您打算重新使用相同的分支名称，这可能会很好，但是由于您重命名了您的分支，所以这是不可取的。将上游设置为新名称会更容易混淆。

我怎样才能从那个原点分离分支？

git branch --unset-upstream

也许创建一个新分支更简单？

请注意，在我上面使用的示例命令中，从switch 命令创建新分支时，我使用了--no-track 选项来阻止它跟踪origin/main。我不会说创建一个新分支“更简单”，但它可以让您删除旧分支，这很好，因为远程跟踪信息也消失了。在我每天工作的 repo 中，我通常在任何时间都有 5-50 个本地分支，所以我喜欢以这样一种方式命名我的分支，以便我可以很确定哪些未合并的提交位于它们之上分支名称。最终，是否再次使用相同的分支，真的取决于个人喜好。在我的一个使用 Git Flow 的常规存储库中，我总是创建一个名为 user/ttt/merge-master-into-develop 的分支，并在每次执行该合并时重复使用相同的名称。但对于常规工作，我的分支名称通常是唯一的，并且对我正在处理的任务具有描述性。

【讨论】：

在某些情况下，确实跟踪原始提交并在那里解决问题（通常您会为此创建一个分支）。然后，您可以将该修复合并到每个下游版本中。见devblogs.microsoft.com/oldnewthing/20180323-01/?p=98325
@torek 对，特别是如果您正在修补旧版本。

【解决方案2】：

如果你愿意，你可以继续使用旧分支，但根据我的经验，使用新分支会让事情变得更干净。

确保在本地更新远程目标分支（我猜可能是 master/main），然后将其合并到本地分支中。如果您压缩提交和/或取决于您的合并策略，事情可能会变得有点混乱。它看起来像这样：

你将一个分支推送到 gitlab
您在 GitLab 中创建一个 MR（带有删除源分支）并将其合并到 master
在您的本地分支中，git pull origin master 提取最新更改并将它们合并到您的分支中
git push -u <branch-name> 会将这个分支推送到 GitLab。（有关此语法的详细信息，请参阅https://stackoverflow.com/a/6232535/2264411）
- 这一步非常重要，因为您将无法再git push 这个分支到 GitLab。由于它已被删除，它实际上是一个新分支，您必须将其推送到 GitLab 上游。

【讨论】：