我非常喜欢Mercurial存储库的Hg Flow。我们目前正在使用Bitbucket，并且在每个产品中都有多个开发人员正在使用。基本上他们可以如下工作：
所以我在BitBucket或本地存储库中保留“develop”分支。如何将功能分支推送到中央存储库并在需要时删除。我认为我们应该这样做吗？
由于
答案 0 :(得分：2)
我个人既不使用git flow或hg flow作为工具，但我确实为自己的项目使用了一些方法（手动）。
在详细介绍之前，当多个人需要合并或分支时，您总是需要在main / bitbucket存储库中提供分支。 这肯定包括＆＃34; develop＆＃34;并且可能还有多个人需要处理的功能/修复（除非你有另一个存储库或方法来交换它们之间的分支/提交）
使用git和mercurial / hg之间的区别在这里是相关的，因为分支模型是完全不同的。 有关详细信息，请参阅A Guide to Branching in Mercurial。使用hg书签与git对分支的作用非常相似，但是对BitBucket上的书签分支模型没有完全支持（参见this ticket）。
hg flow（该工具）使用命名分支。与git分支相比，它们根本不是轻量级的，而是永久的和全局的（它们现在至少可以关闭）。
这意味着每当在任何（命名的）分支上创建任何提交而不是＆＃34;默认＆＃34;被推到bitbucket（即使在合并之后）这将在bitbucket存储库中创建分支。
因此，除了在主存储库中保留所有分支之外，您没有别的选择。
但是，您可以决定何时推送以及何时关闭这些。
我建议使用hg push -r只推动你想要推动的分支/头部，只有在其他人需要或完成并合并时才推动它们。
分支应该在不再需要时立即关闭。 （这可能由hg flow自动完成）
您应尽可能在本地关闭分支。这样他们甚至可能不会出现在bitbucket界面中。有些人可能只在处于关闭状态（将其隐藏在界面中）到达bitbucket存储库。
显然你应该经常推送多个人需要合并的分支。 在我对工作流程的理解中，＆＃34;开发＆＃34;每个项目的分支总是一个应该经常推送的分支（在本地测试之后）。
如果您不使用hg-flow或命名分支，则情况会有所不同。
使用分支/克隆或书签作为分支方法的两者都不会产生永久或必然的全局分支。
如上所述，当您还想使用bitbucket pull请求时，您不能（可靠地）使用书签。你必须单独推书签。正常推送只会更新（分支）分支，因此您可能会在稍后进行争用时错过其他团队成员的提交。 Hg会在创建新头时告诉你。在这种情况下，您可能希望在推送之前将分支与远程书签合并到您的分支中。
当使用分支作为分支时，它有点像书签，但bitbucket完全支持。你需要为每个分支在bitbucket上设置一个新的fork。 如果您需要不同的人来处理它并且您没有其他的交换方式，您自然只想创建额外的叉子。你至少需要一个单独的＆＃34; develop＆＃34;然后存储库。
我个人不会使用完整的＆＃34;流程＆＃34;用bitbucket上的hg。 对于我的项目，＆＃34; develop＆＃34; branch与master / default相同，因为我不会使用git推出版本（除了开发版本，不管怎样都不会使用版本分支）。我不需要单独的生产＆＃34;分支，因为标签大多可用于生产用途。 我也没有创建一个单独的发布准备＆＃34;科。只有一个时间点，我只在开发和停止合并功能时应用错误修正。当您需要同时处理在下一版本中不会发布的功能的功能时，这显然不会起作用。
始终使用完整的＆＃34; git flow＆＃34;很容易因为git分支容易且重量轻。 根据您使用的分支模型以及其他工具的支持程度， 使用完整的＆＃34; hg流程＆＃34;可能不是＆＃34;值得的＆＃34;。
hg指南实际上不鼓励对短命分支使用命名分支。
见Feature separation through named branches。
＆＃34; easy＆＃34;指南中提出的分支概念是分叉/克隆。如果工具/ bitbucket支持更好（并且书签更长的核心hg功能），书签将是翻译git flow的自然方式。
声明： 我可以选择时更喜欢git。我确实使用hg，但不是我个人的选择。
你也可能考虑了大部分内容，但由于你没有说明任何这些细节并接受与你所要求的完全不同的答案（在评论中），我想详细说明一下
修改
跟进评论：
我认为hg书签与git分支相当，因为它们只是提交的可移动指针。 主要的区别在于，当您在git中删除分支时，提交可能会丢失（当不是其他分支的一部分或在另一个分支被垃圾收集之前指向）。当您删除hg中的书签时，除非手动剥离，否则提交仍然是存储库的一部分（（命名或默认）分支的一部分）。
匿名头是相关的，但只是书签指向的东西。没有指向它们的书签，匿名头部不能用作分支（不仅仅是本地合并）和共享。当你在存储库中有匿名头时，除非你记得或有其他线索，否则你不知道它们应该是什么或它们来自哪里。在我看来，匿名负责人只是后期实施书签的一种解决方法，并没有很好地实现遥控器/遥控器头。
命名分支是相互无关的，因为它们与git分支的唯一共同点是具有名称。与克隆整个存储库（分叉模型分叉）相比，它们重量轻，但不能用于＆＃34;你不能摆脱它们＆＃34;。它们是永久性的。 大多数地方都告诉你不要使用命名分支，除非你有充分的理由或者它是一个长期运行的分支。