Question

有一条规则是不要重新推送被推送到远程存储库的提交。只要我理解了一般原因，对我来说不清楚，它是否也适用于这种情况：

让我们说我正在开发一些功能，哪些开发需要几天时间。所以，我创建分支MyFeature，checkout to it，并提交一些东西。由于工作需要几天时间，我不想将其保存在本地计算机中，因此为了备份，我将此分支推送到远程。

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

我的问题：

假设没有其他人永远不会结账并拉出MyFeature分支，并将他的工作建立在这个分支的提交上（为什么有人想拉一些随机分支？），没关系改变这样的远程分支？（使用-force开关）
如果由于某种原因仍然不可取（虽然我想了解这个原因）有什么替代方案？简单合并？但如果是这样，之后，我仍然希望从本地和远程存储库中删除MyFeature分支。那么它与（1）的不同之处是什么？我仍然完全删除它来改变历史。
上述场景是罕见还是不典型？我的意思是，在搜索答案时，阅读有关git-rebase的教程和SO问题，总是强调这种重新定位远程分支的危险，但从未考虑过其他类似的用例。恕我直言，当天更长时间处理某些功能非常普遍，我认为没有谨慎的开发人员不应该只在他的计算机上进行更改......

Answer 1

假设没有其他人永远不会签出并拉出MyFeature分支，并将他的工作建立在这个分支的提交基础上，是否可以重新定义这样的远程分支？（使用-force开关）

rebase不仅可以在master上强制推送您的远程功能分支，而且这是通过在保持线性的同时引入更改来保持master之前的唯一方法。当您rebase在另一个分支上的本地功能分支（例如master）时，您必须强制推送到远程，因为您已经有效地重写了历史记录。没有任何伤害的风险，因为你将是唯一一个在这个分支上工作的人。我认为Git所创造的任何东西本质上都是邪恶的，每个Git功能都有它的时间和地点。这是一个可以接受强制推动的实例。

实际上，远程个人功能分支是唯一可以在已经被推送到远程分支的分支上使用rebase的实例。如上所述，你不会给其他任何人造成问题，因为只有你检查了这个分支。

话虽这么说，做一个由许多用户共享的公共分支的rebase是危险的，因为它可能会导致每个人在下次拉动时发生冲突（当然除了用户之外）做了转折）。

Answer 2

非常主观。 “可以吗？”给谁？给你？给你的雇主？问他们。

至于技术可行性：

是的，没问题。
您可以合并和删除分支。我更喜欢这种方法（参见？主观），我甚至使用git merge --no-ff，这样即使合并是快进，也会创建合并提交。删除分支不会修改历史记录;你只需删除分支指针，而不是提交。

另一个替代方法是git merge --squash，它会将分支压缩为合并为单个提交，该提交将应用于要合并到的分支。我不是那种粉丝，但有些人喜欢这样。
不，这既不罕见也不典型。

Answer 3

在我看来，仅使用一个开发人员来修改功能分支并不是一个问题。我的工作方式与修改自己的功能分支的方式完全相同。如果在合并之前所有功能分支都已重新定位，那么git历史变得更容易查看。但这当然是个人偏好。

它的共享分支在重新定位时会造成麻烦。请在此处查看有关原因的说明：https://superuser.com/a/667200

Answer 4

假设没有其他人永远不会签出并拉出MyFeature分支，并将他的工作基于此分支的提交（为什么有人想拉一些随机分支？），是否可以重新定义这样的远程分支？

当然，您并不需要 - 强制执行rebase步骤你只需要强制推动你的分支

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

只要您在上游回购中更新自己的分支，这应该不是问题。

重新定位远程功能/错误/主题（私有）分支

4 个答案: