将远程特性/错误/主题（私有）分支重新设置基础。

Question

有一个规则是不要对已经推送到远程仓库的提交进行变基。虽然我理解这个规则的一般原因，但对于以下情况是否适用并不清楚：

假设我正在开发某个功能，需要几天时间。因此，我创建了MyFeature分支，并检出它，然后提交了一些内容。由于工作需要几天时间，我不想将其保留在本地机器上，所以为了备份，我将此分支推送到远程。

完成工作后，我想以某种方式将其合并到主分支中。

我的问题是：

1.假设没有其他人会检出和拉取MyFeature分支，并基于该分支的提交进行工作（为什么有人想要拉取一些随意的分支？），使用--force选项重新设置此远程分支是否可以？

2.如果出于某些原因仍然不建议这样做（尽管我想了解那个原因），那么替代方案是什么？简单的合并？但是如果这样做，之后，我仍然希望从本地和远程存储库中删除MyFeature分支。那么它与（1）有何不同？我仍然通过完全删除它来更改历史记录。

3.上述场景是否罕见或不典型？我的意思是，在寻找答案时，阅读有关git-rebase的教程和SO问题时，总是强调不要对远程分支进行变基的危险，但从未考虑过其他用例。在我看来，长时间处理某些功能是相当常见的，我认为谨慎的开发人员不应该仅将更改保存在他的计算机上……

- anth

Answer 1

假设没有其他人会检出和拉取MyFeature分支，并基于此分支的提交进行工作，那么重新设置远程分支是可以的吗？（使用-force开关）

不仅可以在主分支上对远程特性分支进行rebase和强制推送，而且这是唯一的方法，可以保持线性并带来变化，同时保持线性。一旦你将本地特性分支rebase到另一个分支（如master），你必须强制推送到远程，因为你已经重写了历史记录。由于你是唯一在这个分支上工作的人，所以没有任何危害的风险。我认为Git创建的任何东西都不是本质上邪恶的，每个Git功能都有其时间和地点。这是一个可以接受强制推送的实例。

事实上，远程个人特性分支是唯一可以在已经推送到远程的分支上使用rebase的情况。正如前面提到的，你不会给任何人造成问题，因为只有你检出了这个分支。

话虽如此，在公共分支上进行rebase是危险的，因为这很可能会导致每个人在下次pull时发生冲突（当然，除了做rebase的用户）。

- Tim Biegeleisen

Answer 2

非常主观。“可以吗？”是对谁来说的？你？你的雇主？问问他们。

至于技术可行性：

1. 是的，没有问题。

2. 你可以合并和删除分支。我更喜欢这种方法（看到了吧？很主观），我甚至使用 `git merge --no-ff`，这样即使合并是快进的，合并提交也会被创建。删除分支不会修改历史记录；你只是删除了分支指针，而不是提交。

另一种选择是 `git merge --squash`，它将要合并的分支压缩为一个单独的提交，然后应用到你想要合并的分支中。我不喜欢这种方法，但有些人喜欢。

3. 不，这既不罕见也不不寻常。

- musiKk

---

（目前）这是唯一一个涵盖第二部分的答案。+1 :-) - siegi

Answer 3

在我看来，对于只有一个开发人员的功能分支来说，重新设置基础不是问题。我和你一样，在我的功能分支中重新设置基础。如果所有功能分支在合并之前都重新设置基础，Git历史记录就会变得更加容易查看。当然，这是个人偏好。

但是，共享分支在重新设置基础时会导致麻烦。请参见此处关于为什么会出现麻烦的解释：https://superuser.com/a/667200。

- crea1

Answer 4

假设没有其他人会检出并拉取MyFeature分支，并以该分支的提交为基础进行工作（为什么有人想要拉取某个随机分支？），那么重新设置这样的远程分支是否可以？当然可以，而且在rebase步骤中不需要--force。
你只需要强制推送你的分支时才需要。

 git checkout MyFeature
 git fetch
 git rebase origin/master
 git push --force

只要您在上游仓库上更新自己的分支，那就不会有问题。

- VonC