这可能是一个愚蠢的问题，但我无法弄清楚为什么我不能使用我的发布分支作为我的主人？我喜欢＆＃34;一个成功的Git分支模型＆＃34;（http://nvie.com/posts/a-successful-git-branching-model/）的想法，但我可以看到，当我将发布分支合并到master时，我可能需要解决很多冲突。那么为什么不直接使用发布分支作为我的主人？
谢谢！
修改 对不起，我没有说清楚我的问题。我想说的是，这个Git分支模型与从我的发布分支检出到新分支之间有什么区别，并将它用作我的新主分支。将我的发布分支合并到原始主服务器并检出新的主分支是否有区别？
答案 0 :(得分：0)
您如何“将您的发布分支用作master”？我不确定这是什么意思，真的。让我们看一下master是什么以及如何使用它，看看你是否可以通过发布分支来做这些事情......
首先，合并到master不应该创建一个新的代码状态（这似乎是你的反对意见）;所以也许你认为它什么都不做。但确实如此：它表明这个特定版本是实际版本。它被部署到生产，运送到客户，无论如何。任何碰巧是发布分支的旧版本可能都不是生产就绪的。当然你可以使用某种标记约定来解决这个问题，但我认为你会发现解决方案不那么优雅。
接下来，如果我结帐master - 一个不变的名字 - 我应该知道我有最新的产品发布版本。如果我只是依赖于发布分支，我必须知道我想要什么版本，或者检查哪些版本可以选择最新版本。这对于自动部署工具来说可能不太方便。我可以使用移动标签，但这是一种反模式。标签只是一个参考，如果我想要一个移动的参考，那么就有一个解决方案：一个分支。那就是master。
当我在master时，我可以做像
git log --first-parent
并查看发布历史记录，其中包含发布顺序（以及顺便提一下，还有热修复程序）。没有脚本扭曲，没有因某人违反惯例而出现故障（或不显示）的风险。
GitFlow模型的部分要点 - 它使用--no-ff并具有特殊命名的长期分支的原因 - 是提交拓扑具有超出当前代码版本的补丁集合之外的文档值