假设我有一个有10多个提交的开发分支，可以压缩到一个。我去GitHub做一个"压缩和合并"它给了我删除分支的选项。我想保持这种"发展"。但是现在这个分支被认为是先于master． 在这种情况下我该怎么做?如果我删除它，我如何创建一个具有相同名称的新分支而不弄乱事情?
正如Git常见问题解答所述，您不希望保留两个长时间运行的分支，并使用squash merge将其中一个合并到另一个，因为这只会导致合并冲突和悲伤。
如果您想继续为您的pr使用相同的分支(develop)，那么您可以使用git checkout -B develop master在master的本地侧重新创建分支。然而，如果您这样做，您将需要强制推送develop分支，除非您已经使用git push -d origin develop或通过接口从远程删除了它。
或者，你可以使用常规的合并提交，Git FAQ中列出的问题就会消失，你可以无限期地继续使用develop分支。
长时间运行的分支，其中一个分支多次合并到另一个分支中，在Git中构成了反模式。这就是为什么最初的Git流如此令人惊讶的原因之一;它使用那个模式。
如果你考虑一下合并是如何工作的，你就会知道问题出在哪里了。合并提交围绕合并基进行，粗略地说，这是两个分支最初分开的提交。当您压缩合并develop到master并保持develop存活时，合并基数不会移动。因此，在那之后的每一次合并都必须考虑到所有这些相同的提交加上双方的所有新提交，包括你在master上的squash提交。这就意味着你会越来越落后，而且合并冲突的可能性也会增加。
一个解决方案是:不要那样做。只是合并，然后删除develop分支。现在在master的新末端创建一个新的develop分支，然后开始。记住，分支是非常轻量级的;它只是单个提交的名称。销毁和创建名称一点也不麻烦。
如果你决定让develop存活，那么看在上帝的份上，不要使用压缩合并。它是而不是合并!它在master上创建了一个提交，与develop没有任何拓扑关系。这样，您就完全销毁了历史记录，对您自己和Git都是如此。
所以我的建议是，如果你必须保持develop存活，使用true合并。然后，下一次，就在将develop合并到master之前，进行反向合并，将master合并到develop。结果是您将合并基础向前移动，并且您有机会在执行前向合并之前处理任何合并冲突。