强制推送到公共远程分支是否安全？

Question

我在我的本地功能分支上做了一些提交，并决定将其推送到公共存储库，仅用于备份目的。对一些提交和强制（通过租赁？）推送到公共存储库是否安全？在这种情况下，我是唯一一个在这个分支机构工作的人，但是当这个分支上有更多的人工作时，仍然可以强行推动吗？

Answer 1

简而言之：

不要这样做。不是先说不出来。

如果Git告诉你它不接受你的推送，因为refs没有排队，Git正在通过尝试保护你的存储库的完整性来完成它的工作。

也就是说，如果你在Git不同意的当地分支机构有历史记录，Git就不会接受它。

一旦你强行推动那个分支，Git假设你知道你在做什么，并会让你推动分支。

这会对使用该分支的其他人产生不利影响：

• 历史已经被重写，所以当他们试图获得新的工作或尝试将他们的工作集成到上游时，他们必须重写他们自己的本地历史以匹配上游。
• 提交可能会以这种方式丢失。由于您使用rebase重写历史记录，因此这种情况很可能会发生。
• 如果没有任何事先沟通，你会在维护者之间引起混淆，这会导致开发速度减慢。

如果它真的只是你那么它很好，但是如果有其他人使用你的代码库的话，你必须采取预防措施。

Answer 2

  

将一些提交和强制（通过租约？）推送到公共存储库是否安全？

如果你确定你只在这个功能分支中工作，的话，你可以得到你想要的东西，实际上，rebase和强制推送同步可能是更好的解决方案！

  

在这种情况下，我是唯一一个在这个分支机构工作的人，但是当这个分支上有更多的人工作时，仍然可以强行推动吗？

在一些极少数情况下你仍然可以强制推动你和你的团队决定与保持历史相比有一些附加价值。但是期待这些非常具体的案例，每个人都同意最好永远不要重写共享分支的历史。因为它会惹恼所有其他开发人员，并且通常需要更多时间和更高级的知识（git rebase -i）来同步其工作与修改历史记录的远程（强制推送）。

就像git中的很多东西一样，这不是阻止你做某些事情的工具，而是一个团队惯例，因为你找到了更好的东西......

Ps：是的，如果你强行推动什么，总是用'--force-with-lease'来做，以防止丢失你没看到的其他历史记录！