我们使用 Mercurial 作为源代码控制，主要使用命名分支来完成我们关闭并合并到开发分支的主要功能。
最近我对特定问题有两种不同的解决方案。我无法决定选择哪个，因为两者都有其优点和缺点，所以我实现了它们两者但必须选择一个合并到主分支。
第二个实现并不打算合并到主分支中。但我仍然希望保留它以防万一它可能在某一天有用。
一个明显的解决方案是只为每个分支打开一个命名分支。关闭两者并将1合并到主体中。
但这会在源树中留下某种“混乱”。
还有其他替代方案或最佳做法吗？
答案 0 :(得分：1)
我们RhodeCode使用完全基于书签的解决方案，并提取请求功能。
我们使用rebase作为合并策略，这使得提交图更好，更干净。如果我们需要跟踪更改，您可以随时返回到原始拉取请求，并查看开发过程包括CI测试/代码注释。
书签在我们看来是更好的选择，因为它是一个轻量级指针，这允许你做简单的rebase / commit squash，然后简单地推送新的书签指针并用这个信息更新pull请求。这与Mercurial的阶段支持相结合，提供了一种处理新代码提交的非常好的方法。 （在主要回购中公开，在提交来源的叉子中草稿）
到目前为止，我们在内部开发了数以千计的拉取请求，并且我们都同意团队这是最灵活，也是最简单的流程。