所以我正在从 Github 找出最简单的分支/部署策略,它至少有一个 dev 和一个 release(master) 分支。看到这个答案后,我认为这非常接近我们所需要的。除了只能部署某些功能的一个大问题。不是一切。
此处提供的 2 个选项还不够好。这是一个常见的场景,每次恢复都是很讨厌的。另外,我读过樱桃采摘还有其他问题,特别是因为樱桃采摘的提交实际上是副本(这是真的吗?)
现在,我在想,如果对于我们开始处理的新功能,我们创建一个分支,并将它们合并到我们选择的 dev 分支,我们可以将这些分支合并到 release 分支(而不是从 dev 合并到 release 分支,我们从功能分支合并到开发和发布,这样我们就可以选择要发布的内容),这样我们就可以只准备发布所需的更改。我至少可以想到两个可能的问题:
所以,总而言之,我如何保留一个开发分支,在那里进行一些更改,然后只将一些内容移动到另一个分支?。
非常感谢。
你绝对可以做到这一点。这是我的建议:
master。这完成了两件事:
dev中没有尚未准备好发布的内容branch到mastermaster入dev以保持最新状态。否则人们dev会离生产中的东西越来越远。devdev准备好出去的时候
dev到master你会遇到的事情是你正在工作,cool_feature而你的同事已经分支fix_terrible_bug,你意识到cool_feature需要。在这种情况下,fix_terrible_bug直接合并cool_feature并继续。当fix_terrible_bug完成后,它可以合并到master或者dev即使你不进行cool_feature着呢,同样可以合并cool_feature成在任即使你的同事正在继续工作fix_terrible_bug。当另一个分支合并时,Git 会做得很好(虽然当你合并很多这样的时候,避免变基,他们最终会混淆事情)。
作为旁注,不要担心挑选“复制”的东西。Git 中的每个提交都是从其内容、其父提交、当前时间等构建的包。当你挑选时,你将相同的内容放到一个新的父提交上,因此提交哈希必然会发生变化并且它是有效的独立于原始提交的新提交。那很好 - Git 擅长它的工作。除非您提交数千兆字节的高清视频,否则您不会注意到任何额外的空间使用,并且当“原始”提交将路径与您的cherry-pick 连接时,它将有效地成为空操作并最终得到垃圾集。