针对web应用程序的源代码管理策略-分支、标记、分叉等
这篇文章(How do you manage database revisions on a medium sized project with branches?)让我想知道如何最好地使用分支和部署到开发、暂存和生产(以及本地副本)来处理web项目。
我们没有“发布”本身:如果一个特性足够大，足以让人注意到，我们会(在必要的测试/等等之后)推动它的运行，否则我们会分批处理一些功能，当它感觉“舒服”时，推动这些功能的运行。这样做的目的是每个月部署一次或两次以上，因为一个不断变化的站点往往会让用户感到不安。
我们是这样做的，它感觉有点脆弱(目前使用svn，但考虑切换到git)：
- 2“分支”-- DEV和STAGE，该阶段的给定版本标记为主干
- Developer，检查每个更改的主干副本，并为其创建一个分支，
- Developer在本地工作，在开发人员满意时频繁地签入代码(就像投票:早期和经常)
- ，将分支与DEV合并并部署到开发站点。
< code >H 110重复3-4次，直到更改成为具有暂存的更改分支，部署到舞台站点。做好预期的最终testing.
- After一段时间，标记一个给定的阶段的修订为主干，并推动树干活
- 合并躯干改变回到DEV，以保持它在sync
中。
现在，这些步骤中有一些是非常复杂的，手挥挥手，在实践中很难做到(主干-> DEV总是中断)，所以我不得不想象有一个更好的方法。
有什么想法？
回答 4
Stack Overflow用户
发布于 2008-10-01 19:21:08
如果您期望工作不能按时完成，并且没有足够的测试来进行持续的集成工作，那么分支是很方便的。我倾向于在编程任务太大而无法预测地完成编程任务的商店中看到分支式的开发，因此管理层希望等到发布之前才确定应该发布哪些特性。如果您正在做这样的工作，那么您可以考虑使用分布式版本控制，其中每个工作目录自然是一个分支，您可以得到所有本地签入和本地历史记录，您可以在不伤害任何人的情况下食用。您甚至可以与主干之外的其他开发人员交叉合并。
我更喜欢在一个不稳定的树干中工作，分支用于发布候选的分支，这些分支随后被标记为发布，然后成为紧急补丁的流。在这种系统中，很少有超过三个分支(最后一个版本、当前发布候选版本、不稳定主干)。如果您正在执行TDD，并且在不稳定的主干上有CI，这是可行的。而且，如果您要求对所有任务进行分解，以便您可以按照自己的意愿频繁地交付代码(通常一项任务应该只需要一到两天，并且不需要所有其他任务组成它的特性，就可以发布)。因此，程序员进行工作，检查主干，完成工作，同步并随时签入所有测试通过。不稳定的主干始终可以作为发布候选分支(如果所有测试都通过)，因此发布成为一个非事件。
总的来说，更好的方法是:更少的分支，更短的任务，更短的发布时间，更多的测试。
Stack Overflow用户
发布于 2008-10-01 04:20:23
一个明显的想法是更“重新定位”(更多地将“父”环境阶段与“子”环境"DEV“合并到开发人员分支)，以尽量减少主干->DEV的最终影响，这将不再需要。
也就是说，任何在阶段所做的事情，必须在一段时间内投入生产(主干)，应该在DEV和私有devs分支中尽早合并，否则那些后期的改造合并总是很痛苦的。
但是，上面的合并工作流太不方便了，我建议在发布(新主干)之后，基于最新的DEV，重新建立一个分支。重基中继-> dev将变成主干->重基，解决了所有问题，然后进行最后的合并dev->重基，以检查任何当前dev是否与新更新的系统兼容。从REBASE到DEV (和私有dev分支)的最后一个简单的合并将完成这个过程。
分支的目的是将无法与其他当前开发工作一起进行的开发工作隔离开来。如果主干->DEV太复杂，无法与当前的DEVs一起运行，则需要隔离。因此提出了“重基”的分支命题。
Stack Overflow用户
发布于 2009-04-15 23:51:14
读这个：http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf
https://stackoverflow.com/questions/156120
复制相似问题
腾讯云开发者
