一方面，变基是将分支保留在master之上的一种很棒的方法，但是如果有1个以上的人员在使用它，则强制推送会很痛苦，而从该分支派生出更多的分支则变得不切实际。
另一方面，母版不断合并到分支中，使历史变得混乱，并最终进行了最终的交互式变基，甚至在根本不可能的情况下，也很难将其合并回母版。
我想知道在哪里可以找到保持协作分支实际的常用方法的列表？
答案 0 :(得分：1)
如果不想合并，可以使用rebase。
如果遇到麻烦，也许您想重新评估工作流程，例如：
但是正如拉瑟·沃格瑟·卡尔森（LasseVågsætherKarlsen）所说，这不仅仅是一个明确的答案，而是更多的想法和方向。
答案 1 :(得分：0)
我认为，您的主要问题是协调工作的方式：
一方面，变基是在分支机构上保持分支机构的一种很棒的方法，但是强制推动会给您带来痛苦，如果有1个以上的人在进行此操作，而在分支机构上却又变得不切实际分支是从该分支派生的。
强调我的。
强行推动是您在正常工作流程中永远不应该拥有的。与您的合并还是变基无关。 强行推送意味着您重写了已发布的历史记录，这是您要避免的事情。
因此，如果要重新设置基准，不要在重新设置基准之前先推送。将提交保密，可以随心所欲地处理它们。一旦提交看起来不错，就可以发布它们。一旦提交被提交（= public），就不再应该重写它们。请使用合并提交。
此外，我的经验是，许多人太担心保持“线性历史”。事实是，历史不是线性的，记录真相通常比线性谎言更好。 Git专为处理非线性历史记录而构建，绝对没有保留线性历史记录的技术原因。线性历史记录对于人类而言可能更容易解析，但是如果线性历史记录的代价是某些提交由于重新设置错误而变得不可测试（如果您在漫长的{之后不重新测试每个重写的提交，则很容易发生{1}}），那么您就丢掉了git rebase提供的最好的工具之一：git。如果您避免撒谎，那么该命令最有效。
不要误会我的意思：git bisect有其用途，git rebase也有充分的理由存在。我要说的是：这些工具不可避免地会带来负面影响，如果您不付出任何努力来减轻它们，那么您不应该一开始就使用它们。它们并不是为了无意识地使用而构建的。如果需要使用这些工具，则还需要付出努力：1）重新测试所有重写的提交。 2）与团队成员就任何必要的强制推送进行沟通。否则，您会遇到您描述的问题。